1 / 23

CSS432 Congestion Control Textbook Ch6.1 – 6.4

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

anjolie-tate
Download Presentation

CSS432 Congestion Control Textbook Ch6.1 – 6.4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

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

  17. 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

  18. Summary of TCP Versions CSS432: Congestion Control

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

More Related