Congestion Control S o u r c e 1 10-Mbps Ethernet Router - PowerPoint PPT Presentation

Issues • Two sides of the same coin – pre-allocate resources so at to avoid congestion – control congestion if (and when) is occurs Congestion Control S o u r c e 1 10-Mbps Ethernet Router Destination 1.5-Mbps T1 link I D D Outline F s p b M 0 - Source 0 1 2 Queuing Discipline • Two points of implementation Reacting to Congestion – hosts at the edges of the network (transport protocol) Avoiding Congestion – routers inside the network (queuing discipline) • Underlying service model – best-effort (assume for now) – multiple qualities of service (later) Spring 2005 CS 461 1 Spring 2005 CS 461 2 Framework Evaluation • Connectionless flows – sequence of packets sent between source/destination pair – maintain soft state at the routers • Fairness • Power (ratio of throughput to delay) Source 1 Router Destination 1 Throughput/delay Router Source 2 Router Destination 2 Source 3 • Taxonomy – router-centric versus host-centric Optimal Load load – reservation-based versus feedback-based – window-based versus rate-based Spring 2005 CS 461 3 Spring 2005 CS 461 4

Queuing Discipline FQ Algorithm • First-In-First-Out (FIFO) – does not discriminate between traffic sources • Suppose clock ticks each time a bit is transmitted • Fair Queuing (FQ) • Let P i denote the length of packet i – explicitly segregates traffic based on flows • Let S i denote the time when start to transmit packet i – ensures no flow captures more than its share of capacity – variation: weighted fair queuing (WFQ) • Let F i denote the time when finish transmitting packet i • Problem? • F i = S i + P i Flow 1 • When does router start transmitting packet i ? – if before router finished packet i - 1 from this flow, then Flow 2 immediately after last bit of i - 1 ( F i-1 ) Round-robin service – if no current packets for this flow, then start Flow 3 transmitting when arrives (call this A i ) • Thus: F i = MAX ( F i - 1 , A i ) + P i Flow 4 Spring 2005 CS 461 5 Spring 2005 CS 461 6 FQ Algorithm (cont) TCP Congestion Control • For multiple flows – calculate F i for each packet that arrives on each flow • Idea – treat all F i ’s as timestamps – assumes best-effort network (FIFO or FQ routers) each – next packet to transmit is one with lowest timestamp source determines network capacity for itself • Not perfect: can’t preempt current packet – uses implicit feedback • Example – ACKs pace transmission ( self-clocking ) • Challenge Flow 1 Flow 2 Flow 1 Flow 2 Output (arriving) (transmitting) Output – determining the available capacity in the first place F = 10 F = 10 – adjusting to changes in the available capacity F = 8 F = 5 F = 2 (a) (b) Spring 2005 CS 461 7 Spring 2005 CS 461 8

Additive Increase/Multiplicative AIMD (cont) Decrease • Objective: adjust to changes in the available capacity • Question: how does the source determine whether • New state variable per connection: CongestionWindow or not the network is congested? – limits how much data source has in transit MaxWin = MIN(CongestionWindow, • Answer: a timeout occurs AdvertisedWindow) – timeout signals that a packet was lost EffWin = MaxWin - (LastByteSent - LastByteAcked) – packets are seldom lost due to transmission error • Idea: – lost packet implies congestion – increase CongestionWindow when congestion goes down – decrease CongestionWindow when congestion goes up Spring 2005 CS 461 9 Spring 2005 CS 461 10 AIMD (cont) AIMD (cont) Source Destination • Algorithm • Trace: sawtooth behavior – increment CongestionWindow by one packet per RTT ( linear increase ) – divide CongestionWindow by two 70 whenever a timeout occurs 60 50 ( multiplicative decrease ) 40 KB 30 … 20 10 • In practice: increment a little for each ACK 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 Increment = (MSS * MSS)/CongestionWindow Time (seconds) CongestionWindow += Increment Spring 2005 CS 461 11 Spring 2005 CS 461 12

Slow Start Slow Start (cont) • Exponential growth, but slower than all at once Source Destination • Objective: determine the available • Used… capacity in the first – when first starting connection • Idea: – when connection goes dead waiting for timeout • Trace – begin with CongestionWindow = 1 packet 70 – double CongestionWindow each RTT 60 50 (increment by 1 packet for each ACK) KB 40 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 … • Problem: lose up to half a CongestionWindow ’s worth of data Spring 2005 CS 461 13 Spring 2005 CS 461 14 Fast Retransmit and Fast Recovery Results Sender Receiver 70 • Problem: coarse-grain 60 Packet 1 TCP timeouts lead to idle 50 Packet 2 40 ACK 1 KB Packet 3 periods 30 ACK 2 Packet 4 20 10 • Fast retransmit: use ACK 2 Packet 5 1.0 2.0 3.0 4.0 5.0 6.0 7.0 Packet 6 duplicate ACKs to trigger ACK 2 retransmission ACK 2 • Fast recovery Retransmit packet 3 – skip the slow start phase ACK 6 – go directly to half the last successful CongestionWindow ( ssthresh ) Spring 2005 CS 461 15 Spring 2005 CS 461 16

DECbit Congestion Avoidance • Add binary congestion bit to each packet header • TCP’s strategy • Router – control congestion once it happens – monitors average queue length over last busy+idle cycle – repeatedly increase load in an effort to find the point at which congestion occurs, and then back off Queue length • Alternative strategy – predict when congestion is about to happen Current time – reduce rate before packets start being discarded – call this congestion avoidance , instead of congestion control Time • Two possibilities Previous Current cycle cycle Averaging – router-centric: DECbit and RED Gateways interval – host-centric: TCP Vegas – set congestion bit if average queue length > 1 – attempts to balance throughout against delay Spring 2005 CS 461 17 Spring 2005 CS 461 18 End Hosts Random Early Detection (RED) • Destination echoes bit back to source • Notification is implicit • Source records how many packets resulted in set bit – just drop the packet (TCP will timeout) • If less than 50% of last window’s worth had bit set – could make explicit by marking the packet – increase CongestionWindow by 1 packet • Early random drop • If 50% or more of last window’s worth had bit set – rather than wait for queue to become full, drop each arriving packet with some drop probability whenever – decrease CongestionWindow by 0.875 times the queue length exceeds some drop level Spring 2005 CS 461 19 Spring 2005 CS 461 20

RED Details (cont) RED Details • Compute average queue length • Two queue length thresholds AvgLen = (1 - Weight) * AvgLen + Weight * SampleLen 0 < Weight < 1 (usually 0.002) if AvgLen <= MinThreshold then SampleLen is queue length each time a packet arrives enqueue the packet if MinThreshold < AvgLen < MaxThreshold then MaxThreshold MinThreshold calculate probability P drop arriving packet with probability P if MaxThreshold <= AvgLen then drop arriving packet AvgLen Spring 2005 CS 461 21 Spring 2005 CS 461 22 RED Details (cont) Tuning RED • Computing probability P • Probability of dropping a particular flow’s packet(s) is roughly proportional to the share of the bandwidth that flow TempP = MaxP * (AvgLen - MinThreshold)/ is currently getting (MaxThreshold - MinThreshold) • MaxP is typically set to 0.02, meaning that when the average P = TempP/(1 - count * TempP) queue size is halfway between the two thresholds, the • Drop Probability Curve gateway drops roughly one out of 50 packets. • If traffic id bursty, then MinThreshold should be P(drop) sufficiently large to allow link utilization to be maintained at an acceptably high level • Difference between two thresholds should be larger than the 1.0 typical increase in the calculated average queue length in one RTT; setting MaxThreshold to twice MinThreshold is MaxP reasonable for traffic on today’s Internet AvgLen • Penalty Box for Offenders MinThresh MaxThresh Spring 2005 CS 461 23 Spring 2005 CS 461 24