1 / 10

9.6 TCP Congestion Control

9.6 TCP Congestion Control. Idea assumes best-effort network (FIFO or FQ routers)each source determines network capacity for itself uses implicit feedback ACKs pace transmission ( self-clocking ) Challenge determining the available capacity in the first place

mayda
Download Presentation

9.6 TCP Congestion Control

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. 9.6 TCP Congestion Control • Idea • assumes best-effort network (FIFO or FQ routers)each source determines network capacity for itself • uses implicit feedback • ACKs pace transmission (self-clocking) • Challenge • determining the available capacity in the first place • adjusting to changes in the available capacity

  2. Additive Increase/Multiplicative Decrease • Objective: adjust to changes in the available capacity • New state variable per connection: CongestionWindow • limits how much data source has in transit MaxWin = MIN(CongestionWindow, AdvertisedWindow) EffWin = MaxWin - (LastByteSent - LastByteAcked) • Idea: • increase CongestionWindow when congestion goes down • decrease CongestionWindow when congestion goes up

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

  4. Source Destination … 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

  5. 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) • Trace: sawtooth behavior

  6. Source Destination … Slow Start • Objective: determine the available capacity in the first • Idea: • begin with CongestionWindow = 1 packet • double CongestionWindow each RTT (increment by 1 packet for each ACK)

  7. 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) • Exponential growth, but slower than all at once • Used… • when first starting connection • when connection goes dead waiting for timeout • Trace • Problem: lose up to half a CongestionWindow’s worth of data

  8. 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 and Fast Recovery • Problem: coarse-grain TCP timeouts lead to idle periods • Fast retransmit: use duplicate ACKs to trigger retransmission ( After see 3 acks)

  9. 70 60 50 40 KB 30 20 10 1.0 2.0 3.0 4.0 5.0 6.0 7.0 Results • Fast recovery • skip the slow start phase • go directly to half the last successful CongestionWindow (ssthresh), • Inflate the CongestionWindow by adding MSS for each additional duplicate ACK received • Set cwnd to ssthresh value and begin congestion avoidance

  10. Put Together • cwnd, ssthresh, MSS (maximum segment size) • cwnd (ssthresh): slow start, exponential growth • Timeout: ssthresh = ssthresh / 2, cwnd = 1, slow start • After cwnd >ssthresh, additive increase of both cwnd and ssthresh (congestion avoidance) • 4 duplicates, fast retransmit and then fast recovery, after receiving an ACK for new data, begin congestion avoidance

More Related