1. CSS432: Congestion Control1 CSS432 Congestion Control Textbook Ch6.1 – 6.4 Professor: Munehiro Fukuda

2. CSS432: Congestion Control2 Taxonomy Resource in network systems  Link bandwidth  Buffer size in routers or switches Two sides of the same coin  Pre-allocate resources so as to avoid congestion  Control congestion that leads to resource restrictions Flow control versus congestion control  Flow control: to keep a fast sender from overrunning a slow receiver  Congestion control: to keep a set of senders from sending two much data into the network. Two points of implementation Router CentricQoS-based serviceReservation-basedRate-based Host CentricBest-effort serviceFeedback-basedWindow-based

3. CSS432: Congestion Control3 Connectionless Flow Datagrams  Switched independently  Flowing through a particular set of routers if transmitted from the same source/destination pair Connectionless Flows Routers  No state if they follow purely connectionless service  Hard state if they follow purely connection-oriented service  Soft state used to make resource allocation decision for each flow – How? Router Source 2 1 3 Router Destination 2 1

4. CSS432: Congestion Control4 Queuing Discipline First-In-First-Out (FIFO)  Does not discriminate between traffic sources Fair Queuing (FQ)  Work conserving: link is never left idle  Explicitly segregates traffic based on flows  Ensures no flow captures more than its share of capacity If there are n flows sending data, 1/n th bandwidth is at most given  Variation: weighted fair queuing (WFQ) Problem? Flow 1 Flow 2 Flow 3 Flow 4 Round-robin service

5. CSS432: Congestion Control5 Bit-Round Fair Queuing (BRFQ) Algorithm  For each queue, compute the virtual finish time upon the arrival of a new packet.  Choose a packet with the lowest virtual finish time. Pros and Cons  Emulate bit-by-bit fair queuing  Not perfect: can’t preempt the current large packet. Packet 1Packet 2Packet 1Packet 2Packet 1 Real arrival time t i 02123 Transmission time P i 31142 Virtual start time S i 03123 Virtual finish time F i 34265 Queue AQueue BQueue C TimeQueue AQueue BQueue C 0 1 2 3 4 5 6 7 8 9 10 11 12 Real arrival FQ BRFQ F q i =S q i + P q i S q i = max[F q i -1, R(t q i )] R(t) = R(t + 1) + 1/#rounds max( )

6. CSS432: Congestion Control6 Congestion in Packet-Switched Network Source cannot directly observe the traffic on the slow network A congested link could be assigned a large edge weight by the route propagation protocol All packets may have to flow through the same (bottleneck) router to the destination. Destination 1.5-Mbps T1 link Router Source 2 1 100-Mbps FDDI 10-Mbps Ethernet FQ or BRFQ drops off overflowed packets.

7. CSS432: Congestion Control7 TCP Congestion Control Idea  Assumes best-effort network (FIFO or FQ routers)  Determines network capacity at each source host  Uses implicit feedback  Uses ACKs to pace packet transmission (self-clocking) Challenge  Determining the available capacity in the first place  Adjusting # in-transit packets in response to dynamic changes in the available capacity

8. CSS432: Congestion Control8 Additive Increase/Multiplicative Decrease (AIMD) New state variable per connection: CongestionWindow  Limits how much data source can send:  Previously: EffectiveWindow = AdvertisedWindow – (LastbyteSent - LastByteAcked)  Now: EffectiveWindow = Min( CongestionWindow, AdvertisedWindow) – (LastByteSent – LastByteAcked) Idea:  Increase CongestionWindow when congestion goes down  Decrease CongestionWindow when congestion goes up Sending application LastByteWritten TCP LastByteSent LastByteAcked LastByteSent – LastByteAcked ≤ AdvertisedWindow EffectiveWindow = AdvertisedWindow – (LastByteSent – LastByteAcked) y

9. CSS432: Congestion Control9 AIMD (cont) Question: how does the source determine whether or not the network is congested? Answer: a timeout occurs  Timeout signals that a packet was lost  Packets are seldom lost due to transmission error  Lost packet implies congestion

10. CSS432: Congestion Control10 AIMD (cont) In practice: increment a little for each ACK Increment = MSS * (MSS/CongestionWindow) CongestionWindow += Increment Algorithm  Increment CongestionWindow by one packet per RTT (linear increase)  Divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease) 60 20 1.02.03.04.05.06.07.08.09.0 KB Time (seconds) 70 30 40 50 10 10.0

11. CSS432: Congestion Control11 Slow Start Objective: reach the available capacity as fast as possible Idea:  Begin with CongestionWindow = 1 packet  Double CongestionWindow each RTT (increment by 1 packet for each ACK)  When timeout occurs: Set congestionThreashold to CongestionWindow / 2 Begin with CongestionWindow = 1 packet again  Observe slow start with tcpdump in assignment 3. SourceDestination …

12. CSS432: Congestion Control12 Slow Start (cont) Exponential growth, but slower than all at once Used…  when first starting connection  When Nagle’s algorithm is used and packets are lost, (timeout occurs and the congestion window is already 0) Final Algorithm:  CongestionThreshold = INF  While (true) { CongestionWindow = 1 While ( congestionWindow < congestionThreshold )  CongestionWindow *= 2 (based on slow start, exponential growth) While ( ACK returned )  CongestionWindow++ (based on additive lincrease, linear growth) If timeout occurs,  CongestionThreshold = CongestionWindow / 2  Continue  }

13. CSS432: Congestion Control13 Slow Start (cont) Trace: Problem: lose up to half a CongestionWindow ’s worth of data The actual congestion thresholdCongestion window Packets lost Timeout

14. CSS432: Congestion Control14 Fast Retransmit Problem: coarse-grain TCP timeouts lead to idle periods Fast retransmit: use duplicate ACKs to trigger retransmission  The receiver sends back the same ACK as the last packet received in the correct sequential order.  The sender retransmits the packet whose ID is one larger than this duplicate ACK, upon receiving three ACKs. Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 6 Retransmit packet 3 ACK 1 ACK 2 ACK 6 ACK 2 SenderReceiver Duplicate ACK 1 Duplicate ACK 2 Duplicate ACK 3

15. CSS432: Congestion Control15 Results 60 20 1.02.03.04.05.06.07.0 KB 70 30 40 50 10 A packet lost Duplicate Acks allowing to keep transmitting more packet CongestionWindow is divided in a half upon retransmits rather than timeouts Too many packets sent A half of them dropped off No ACKs returned CongestionWindow stays in flat Coarse-grained timeouts

16. CSS432: Congestion Control16 Fast Recovery Fast recovery  skip the slow start phase  go directly to half the last successful CongestionWindow ( ssthresh )

17. CSS432: Congestion Control17 Congestion Avoidance TCP’s strategy  control congestion once it happens  repeatedly increase load in an effort to find the point at which congestion occurs, and then back off Alternative strategy  predict when congestion is about to happen  reduce rate before packets start being discarded  call this congestion avoidance, instead of congestion control Two possibilities  router-centric: RED Gateways Explanation in the following slides  host-centric: TCP Vegas Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller.

18. CSS432: Congestion Control18 Summary of TCP Versions RFC 1122TCP TahoeTCP RenoTCP Vegas RTT EstimationXXXX Karn’s AlgorithmXXXX Slow StartXXXX AIMDXXXX Fast RetransmitXXX Fast RecoveryXX Throughput-rate congestion control X

19. CSS432: Congestion Control19 Random Early Detection (RED) Notification is implicit  just drop the packet (TCP will timeout)  could make explicit by marking the packet Early random drop  rather than wait for queue to become full, drop each arriving packet with some drop probability whenever the queue length exceeds some drop level Congestion avoidance Global synchronization avoidance

20. CSS432: Congestion Control20 RED Details Compute average queue length AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0 < Weight < 1 (usually 0.002) SampleLen is queue length each time a packet arrives MaxThresholdMinThreshold AvgLen

21. CSS432: Congestion Control21 RED Details (cont) Two queue length thresholds if AvgLen <= MinThreshold then enqueue the packet if MinThreshold < AvgLen < MaxThreshold then calculate probability P drop arriving packet with probability P if MaxThreshold <= AvgLen then drop arriving packet

22. CSS432: Congestion Control22 RED Details (cont) Computing probability P TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) Drop Probability Curve P(drop) 1.0 MaxP MinThreshMaxThresh AvgLen Keep track of how many newly arriving packets have been queued while AveLen has been between the two thresholds Typically 0.02

23. CSS432: Congestion Control23 Reviews  Queuing disciplines: FIFO FQ  TCP congestion control: AIMD, cold/slow start, and fast retransmit/fast recovery  Congestion avoidance: RED and TCP vegas Exercises in Chapter 6  Ex. 2 (Avoidance)  Ex. 6 (Router congestions)  Ex. 25(Slow start)  Ex. 27 (AIMD, slow start)  Ex. 34 (RED)