1. Data Communication and Networks Lecture 7 Congestion in Data Networks October 17, 2002 Joseph Conron Computer Science Department New York University conron@cs.nyu.edu

2. Principles of Congestion Control Congestion: zinformally: “too many sources sending too much data too fast for network to handle” zdifferent from flow control! zmanifestations: ylost packets (buffer overflow at routers) ylong delays (queueing in router buffers) za top-10 problem!

3. What Is Congestion? zCongestion occurs when the number of packets being transmitted through the network approaches the packet handling capacity of the network zCongestion control aims to keep number of packets below level at which performance falls off dramatically zData network is a network of queues zGenerally 80% utilization is critical zFinite queues mean data may be lost

4. Queues at a Node

5. Effects of Congestion zPackets arriving are stored at input buffers zRouting decision made zPacket moves to output buffer zPackets queued for output transmitted as fast as possible yStatistical time division multiplexing zIf packets arrive to fast to be routed, or to be output, buffers will fill zCan discard packets zCan use flow control yCan propagate congestion through network

6. Interaction of Queues

7. Causes/costs of congestion: scenario 1 ztwo senders, two receivers zone router, infinite buffers zno retransmission z large delays when congested z maximum achievable throughput

8. Practical Performance zIdeal assumes infinite buffers and no overhead zBuffers are finite zOverheads occur in exchanging congestion control messages

9. Effects of Congestion - No Control

10. Causes/costs of congestion: scenario 2 zone router, finite buffers zsender retransmission of lost packet

11. Causes/costs of congestion: scenario 2 zalways: (goodput) z“perfect” retransmission only when loss: zretransmission of delayed (not lost) packet makes larger (than perfect case) for same in out = in out > in out “ costs” of congestion: zmore work (retrans) for given “goodput” zunneeded retransmissions: link carries multiple copies of pkt

12. Causes/costs of congestion: scenario 3 zfour senders zmultihop paths ztimeout/retransmit in Q: what happens as and increase ? in

13. Causes/costs of congestion: scenario 3 Another “cost” of congestion: zwhen packet dropped, any “upstream transmission capacity used for that packet was wasted!

14. Mechanisms for Congestion Control

15. Backpressure zIf node becomes congested it can slow down or halt flow of packets from other nodes zMay mean that other nodes have to apply control on incoming packet rates zPropagates back to source zCan restrict to logical connections generating most traffic zUsed in connection oriented that allow hop by hop congestion control (e.g. X.25) zNot used in ATM

16. Choke Packet zControl packet yGenerated at congested node ySent to source node ye.g. ICMP source quench xFrom router or destination xSource cuts back until no more source quench message xSent for every discarded packet, or anticipated zRather crude mechanism

17. Implicit Congestion Signaling zTransmission delay may increase with congestion zPacket may be discarded zSource can detect these as implicit indications of congestion zUseful on connectionless (datagram) networks ye.g. IP based x(TCP includes congestion and flow control - see chapter 17) zUsed in frame relay LAPF

18. Explicit Congestion Signaling zNetwork alerts end systems of increasing congestion zEnd systems take steps to reduce offered load zBackwards yCongestion avoidance in opposite direction to packet required zForwards yCongestion avoidance in same direction as packet required zUsed in ATM by ABR Service

19. Approaches towards congestion control End-end congestion control: zno explicit feedback from network zcongestion inferred from end- system observed loss, delay zapproach taken by TCP Network-assisted congestion control: z routers provide feedback to end systems ysingle bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) yexplicit rate sender should send at Two broad approaches towards congestion control:

20. Case study: ATM ABR congestion control ABR: available bit rate: z“elastic service” zif sender’s path “underloaded”: ysender should use available bandwidth zif sender’s path congested: ysender throttled to minimum guaranteed rate RM (resource management) cells: z sent by sender, interspersed with data cells z bits in RM cell set by switches (“network-assisted”) yNI bit: no increase in rate (mild congestion) yCI bit: congestion indication z RM cells returned to sender by receiver, with bits intact

21. Case study: ATM ABR congestion control ztwo-byte ER (explicit rate) field in RM cell ycongested switch may lower ER value in cell ysender’ send rate thus minimum supportable rate on path zEFCI bit in data cells: set to 1 in congested switch yif data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell

22. ABR Cell Rate Feedback Rules zIF CI == 1 yReduce ACR to a value >= MCR zELSE IF NI == 0 yIncrease ACR to a value <= PCR zIF ACR > ER ySet ACR = max(ER, MCR)

23. TCP Congestion Control zend-end control (no network assistance)  transmission rate limited by congestion window size, Congwin, over segments: zw segments, each with MSS bytes sent in one RTT: throughput = w * MSS RTT Bytes/sec Congwin

24. TCP congestion control: z two “phases” yslow start ycongestion avoidance z important variables:  Congwin  threshold: defines threshold between two slow start phase, congestion control phase z“probing” for usable bandwidth:  ideally: transmit as fast as possible ( Congwin as large as possible) without loss  increase Congwin until loss (congestion)  loss: decrease Congwin, then begin probing (increasing) again

25. TCP Slowstart zexponential increase (per RTT) in window size (not so slow!) zloss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) Slowstart algorithm Host A one segment RTT Host B time two segments four segments

26. TCP Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart Congestion avoidance 1 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs

27. TCP congestion avoidance (AIMD) : z Additive Increase, Multiplicative Decrease yincrease window by 1 per RTT ydecrease window by factor of 2 on loss event AIMD

28. TCP Fairness Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 bottleneck router capacity R TCP connection 2

29. Why is TCP fair? Two competing sessions: zAdditive increase gives slope of 1, as throughout increases zmultiplicative decrease decreases throughput proportionally R R equal bandwidth share Connection 1 throughput Connection 2 throughput congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2