1 / 33

CSS432 Congestion Control Textbook Ch6.1 – 6.4

CSS432 Congestion Control Textbook Ch6.1 – 6.4. Instructor: Joe McCarthy (based on Prof. Fukuda’s slides). Taxonomy. Limited resources in network systems Link bandwidth Buffer size in routers or switches Resource allocation & congestion control: 2 sides of same coin

prue
Télécharger la présentation

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 Instructor: Joe McCarthy(based on Prof. Fukuda’s slides) CSS432: Congestion Control

  2. Taxonomy • Limited resources in network systems • Link bandwidth • Buffer size in routers or switches • Resource allocation & congestion control: 2 sides of same coin • Pre-allocate resources so as to avoid congestion • Control congestion only when it occurs • Flow control vs. 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. Connectionless Flow • Datagrams • Switched independently • Typically flow through same set of routers if transmitted from the same source to the same destination • Connectionless Flows • Routers & states: • No state: purely connectionless service • Hard state: purely connection-oriented service • Soft state: allocate resources on a per-flow basis CSS432: Congestion Control

  4. Flow 1 Flow 2 Round-robin service Flow 3 Flow 4 Queuing Discipline • First-In-First-Out (FIFO) w/ Tail Drop • Does not discriminate between traffic sources (flows) • Fair Queuing (FQ) • Work conserving: link is never left idle (if data to be sent) • Explicitly segregates traffic based on flows • Ensures no flow captures more than its share of capacity • If there are n flows sending data, each is allocated 1/n bandwidth • Variation: weighted fair queuing (WFQ) • Problem: • Variable packet length [Section 3.2] CSS432: Congestion Control

  5. Bit-Round Fair Queuing (BRFQ) • Algorithm • For each queue, compute the virtual finish time (F) upon arrival of a new packet. • Choose a packet with the lowest virtual finish time. • No preemption • Pros and Cons • Emulates bit-by-bit fair queuing • Not perfect: can’t preempt a large packet currently being transmitted Example of fair queuing in action: (a) packets with earlier finishing times are sent first; (b) sending of a packet already in progress is completed CSS432: Congestion Control

  6. TCP Congestion Control • Created by Van Jacobson, 1980s, • ~8 years after TCP/IP protocol stack became operational • Immediately preceding this time, the Internet was suffering from congestion collapse • hosts would send their packets into the Internet as fast as the advertised window would allow, • congestion would occur at some router (causing packets to be dropped), and the hosts would time out • hosts retransmit their packets, resulting in even more congestion CSS432: Congestion Control

  7. TCP Congestion Control • Concept: • 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 # of 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 deceases • Decrease CongestionWindow when congestion increases CSS432: Congestion Control

  9. AIMD (cont) • Question: how does the source determine whether or not the network is congested? CSS432: Congestion Control

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

  11. 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 1 packet per RTT (additive increase) • Divide CongestionWindow by 2 whenever a timeout occurs (multiplicative decrease) • In practice: increment a little for each ACK Increment = MSS * (MSS/CongestionWindow) CongestionWindow += Increment CongestionWindow Size CSS432: Congestion Control

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

  13. Slow Start • 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 increase, linear growth) if timeout occurs, CongestionThreshold = CongestionWindow / 2 Continue } CSS432: Congestion Control

  14. 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 • Trace: • Where: • Colored line = value of CongestionWindow • Solid bullets at top = timeouts • Hash marks = time when each packet is transmitted • Vertical bars = time when a packet that was eventually retransmitted (i.e., was lost) was first transmitted CSS432: Congestion Control

  15. Slow Start http://www.6test.edu.cn/~lujx/linux_networking/0131777203_ch24lev1sec4.html CSS432: Congestion Control

  16. 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 • Trace: • Problem: lose up to half a CongestionWindow’s worth of data Timeout Packets lost The actual congestion threshold Congestion window CSS432: Congestion Control

  17. 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 (TCP Tahoe) • Problem: coarse-grained 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 3 ACKs. Duplicate ACK 1 Duplicate ACK 2 Duplicate ACK 3 CSS432: Congestion Control

  18. 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 Effect of Fast Retransmit 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

  19. Effect of Fast Retransmit Too many packets sent A half of them dropped off No ACKs returned CongestionWindow stays flat (no increase) Coarse-grained timeouts A packet lost Duplicate ACKs allow transmission of more packets 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

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

  21. Congestion CSS432: Congestion Control

  22. Congestion Avoidance • TCP’s strategy: congestion control • control congestion after it happens • repeatedly increase load in an effort to find the point at which congestion occurs, and then back off • Alternative strategy: congestion avoidance • predict when congestion is about to happen • reduce rate before packets start being discarded • 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

  23. Summary of TCP Versions CSS432: Congestion Control

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

  25. RED Details • Detect / respond to long-lived congestion (vs. short bursts) • Low-pass filter • 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

  26. RED Details (cont) • Two queue length thresholds if AvgLen <= MinThreshold then enqueue the packet else if AvgLen >= MaxThreshold then drop arriving packet else // MinThreshold < AvgLen < MaxThreshold calculate probability P drop arriving pack with probability P CSS432: Congestion Control

  27. 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 AvgLen has remained between the 2 thresholds • Typically: • MaxThreshold = MinThreshold * 2 • MaxThreshold < MaxBuffer CSS432: Congestion Control

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

  29. Exercise 2 • TCP uses a host-centric, feedback-based, window-based resource allocation model. How might TCP have been designed to use instead the following models: • (a) Host-centric, feedback-based and rate-based. • (b) Router-centric and feedback-based. CSS432: Congestion Control

  30. Exercise 6 Consider the arrangement of hosts H and routers R and R1 in Figure 6.27. All links are full-duplex, and all routers are faster than their links. Show that R1 cannot become congested and for any other router R, we can find a traffic pattern that congests that router alone. CSS432: Congestion Control

  31. Exercise 25 • You are an Internet Service Provider; your client hosts connect directly to your routers. You know some hosts are using experimental TCPs and suspect some may be using a “greedy” TCP with no congestion control. • What measurements might you make at your router to establish that a client was not using a slow start at all? • If a client used slow start on startup but not after a timeout, could you detect that? CSS432: Congestion Control

  32. 27. Consider the TCP trace in Figure 6.28. Identify time intervals representing slow start on startup, slow start after timeout, and linear-increase congestion avoidance. Explain what is going on from T=0.5 to T=1.9. The TCP version that generated this trace includes a feature absent from the TCP that generated Figure 6.11. What is this feature? This trace and the one in Figure 6.13 both lack a feature. What is it? Figure 6.28 Figure 6.11 Figure 6.13 CSS432: Congestion Control

  33. Exercise 34 • Consider a RED gateway with MaxP = 0.01 and with an average queue length halfway between the two thresholds • Find the drop probability Pcount for count = 1 and count = 100 • Calculate the probability that none of the first 50 packets is dropped. Note that this is (1 – P1) * … * (1 – P50) CSS432: Congestion Control

More Related