CSS432 Congestion Control Textbook Ch6.1 – 6.4 Professor: Munehiro Fukuda (Augmented by Rob Nash) CSS432: Congestion Control

CSS432: Congestion Control 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 Centric QoS-based service Reservation-based Rate-based Host Centric Best-effort service Feedback-based Window-based CSS432: Congestion Control

CSS432: Congestion Control 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 Destination CSS432: Congestion Control

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 drops off overflowed packets. CSS432: Congestion Control

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 CSS432: Congestion Control

Additive Increase/Multiplicative Decrease (AIMD) New state variable per connection: CongestionWindow Limits how much data source can send: Previously: EffectiveWindow = AdvertisedWindow – (LastbyteSent - LastByteAcked) Now: = 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 CSS432: Congestion Control

CSS432: Congestion Control 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 CSS432: Congestion Control

CSS432: Congestion Control AIMD (cont) Algorithm Increment CongestionWindow by one packet per CW (linear increase) Divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease) 60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 KB T ime (seconds) 70 30 40 50 10 10.0 In practice: increment a little for each ACK Increment = MSS * (MSS/CongestionWindow) CongestionWindow += Increment CSS432: Congestion Control

CSS432: Congestion Control AI in AIMD too Slow? Connections just starting up ramp up too slowly and waste resources Not doing effective probing, either We need something faster, that sounds faster: Quick Ramp Up? Fast Start? CSS432: Congestion Control

Slow Start Overview (p481) Avoids “out of the gate” bursts of windowSize Quicker than a linear increase Begin with CongestionWindow = 1 On timeout, set a threshold == CW/2 This is the multiplicative decrease Set CongestionWindow to 1 and slow start Then switch to linear once CW >= threshold CSS432: Congestion Control

CSS432: Congestion Control Slow Start Source Destination … 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. CSS432: Congestion Control

CSS432: Congestion Control 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 } CSS432: Congestion Control

CSS432: Congestion Control Slow Start (cont) Trace: Problem: lose up to half a CongestionWindow’s worth of data 60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 KB 70 30 40 50 10 Timeout Packets lost The actual congestion threshold Congestion window CSS432: Congestion Control

CSS432: Congestion Control Slow Start Notes Only used at the beginning of a connection or whenever a timeout occurs Slow Start augments the AI in AIMD Less time to use more bandwidth after a course-grained timeout So, our ramp up is steeper Fast Retransmit deals with cumulative ACKS Avoid waiting for long timeouts Fast Recovery skips Slow Start avoids “resetting to 1” (the slow start approach) and just uses CW/2 CSS432: Congestion Control

CSS432: Congestion Control 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 Sender Receiver Duplicate ACK 1 Duplicate ACK 2 Duplicate ACK 3 CSS432: Congestion Control

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

CSS432: Congestion Control Implications Congestion Threshold is divided in a half upon retransmits and timeouts CW = 1 We use ACKS and DUP ACKS as our timers Since these move faster than our internal clocks A retransmission indicates congestion and we don’t need to wait forever (course timeout) to notice this CSS432: Congestion Control

CSS432: Congestion Control Fast Recovery Fast recovery skip the slow start phase go directly to half the last successful CongestionWindow (ssthresh) Below lacks the initial slow start & cg timeouts 60 20 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 KB T ime (seconds) 70 30 40 50 10 10.0 CSS432: Congestion Control

CSS432: Congestion Control Chapter 6, Problem 27 Consider the TCP traces… CSS432: Congestion Control

CSS432: Congestion Control Congestion Avoidance TCP’s strategy is Congestion Control, not Avoidance control congestion once it happens repeatedly increase load in an effort to find the point at which congestion occurs, and then back off TCP needs to observe losses to find the sweet spot in the bandwidth 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 (guess who?) Compare measured and expected throughput rate, and shrink congestion window if the measured rate is smaller. CSS432: Congestion Control

Summary of TCP Versions RFC 1122 TCP Tahoe TCP Reno TCP Vegas RTT Estimation X Karn’s Algorithm Slow Start AIMD Fast Retransmit Fast Recovery Throughput-rate congestion control CSS432: Congestion Control

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 CSS432: Congestion Control

CSS432: Congestion Control 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 MaxThreshold MinThreshold A vgLen CSS432: Congestion Control

CSS432: Congestion Control 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 CSS432: Congestion Control

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

CSS432: Congestion Control Chapter 6, Problem 33 DECbit V.S. RED Explicit Congestion Avoidance V.S. Implicit Congestion Avoidance CSS432: Congestion Control

CSS432: Congestion Control 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) CSS432: Congestion Control