240 likes | 449 Views
CSS432 Congestion Control Textbook Ch6.1 – 6.4. Professor: Munehiro Fukuda. 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
E N D
CSS432 Congestion ControlTextbook Ch6.1 – 6.4 Professor: Munehiro Fukuda 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 CSS432: Congestion Control
Source 1 Router Destination 1 Router Source 2 Router Destination 2 Source 3 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? CSS432: Congestion Control
Flow 1 Flow 2 Round-robin service Flow 3 Flow 4 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/nth bandwidth is at most given • Variation: weighted fair queuing (WFQ) • Problem? CSS432: Congestion Control
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. Queue A Queue B Queue C max( ) Real arrival FQ BRFQ Fqi=Sqi + Pqi Sqi = max[Fqi-1, R(tqi)] R(t) = R(t + 1) + 1/#rounds CSS432: Congestion Control
Source 1 10-Mbps Ethernet Router Destination 1.5-Mbps T1 link 100-Mbps FDDI Source 2 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. FQ or BRFQ 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
Sending application TCP LastByteWritten y LastByteSent LastByteAcked LastByteSent – LastByteAcked ≤ AdvertisedWindow EffectiveWindow = AdvertisedWindow – (LastByteSent – LastByteAcked) 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 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
70 60 50 40 KB 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 T ime (seconds) AIMD (cont) • Algorithm • Increment CongestionWindow by one packet per RTT (linear increase) • Divide CongestionWindow by two whenever a timeout occurs (multiplicative decrease) • In practice: increment a little for each ACK Increment = MSS * (MSS/CongestionWindow) CongestionWindow += Increment CSS432: Congestion Control
Source Destination … 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. 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
70 60 50 KB 40 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 Slow Start (cont) • Trace: • Problem: lose up to half a CongestionWindow’s worth of data Timeout Packets lost The actual congestion threshold Congestion window CSS432: Congestion Control
Sender Receiver Packet 1 Packet 2 ACK 1 Packet 3 ACK 2 Packet 4 ACK 2 Packet 5 Packet 6 ACK 2 ACK 2 Retransmit packet 3 ACK 6 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. Duplicate ACK 1 Duplicate ACK 2 Duplicate ACK 3 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
Fast Recovery • Fast recovery • skip the slow start phase • go directly to half the last successful CongestionWindow (ssthresh) CSS432: Congestion Control
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. CSS432: Congestion Control
Summary of TCP Versions 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
MaxThreshold MinThreshold A vgLen 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 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
P(drop) 1.0 MaxP A vgLen MinThresh MaxThresh RED Details (cont) Typically 0.02 • Computing probability P TempP = MaxP * (AvgLen - MinThreshold)/ (MaxThreshold - MinThreshold) P = TempP/(1 - count * TempP) • Drop Probability Curve Keep track of how many newly arriving packets have been queued while AveLen has been between the two thresholds 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