TCP Tutorial - Part II -

1. TCP Tutorial- Part II- Laboratory of Intelligent Network @ KUT (http://link.kut.ac.kr) Youn-Hee Han It is licensed under a Creative Commons Attribution 2.5 License

2. TCP Flow Control KUT

3. TCP Flow Control • Send buffer size: SendBuffer • Sending side • LastByteSent - LastByteAcked ≤ AdvertisedWindow • LastByteWritten - LastByteAcked ≤ SendBuffer • LastByteAcked ≤ LastByteSent • LastByteSent ≤ LastByteWritten • buffer bytes between LastByteAcked and LastByteWritten • block sender if tries to write y bytes but (LastByteWritten - LastByteAcked) + y > SenderBuffer Sending application TCP LastByteWritten LastByteAcked LastByteSent (a) KUT

4. TCP Flow Control • Receive buffer size: RcvBuffer • Receiving side • LastByteRead < NextByteExpected • NextByteExpected ≤ LastByteRcvd + 1 • LastByteRcvd - LastByteRead ≤ RcvBuffer • buffer bytes between LastByteRead and LastByteRcvd • AdvertisedWindow = RcvBuffer - (LastByteRcvd - LastByteRead) Receiving application TCP LastByteRead NextByteExpected LastByteRcvd (b) KUT

5. TCP Flow Control • TCP sender has a ‘SendBuffer’ • LastByteSent - LastByteAcked ≤ AdvertisedWindow • block sender if tries to send the next segment but (LastByteSent - LastByteAcked) + thee next sgement size > AdvertisedWindow • LastByteWritten – LastByteAcked ≤ SendBuffer • block sender if tries to write y bytes but (LastByteWritten - LastByteAcked) + y > SenderBuffer EffectiveWindow LastByteWritten AdvertisedWindow (from receiver) Sent but not acked Not yet sent Sequence numbers SendBuffer LastByteSent LastByteAcked KUT

6. TCP receiver has a “RcvBuffer”: flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast TCP Flow Control LastByteRead RcvBuffer (possible window) ACKed but not delivered to app. recv’d but not ACKed Sequence numbers missing data AdvertisedWindow NextByteExpected LastByteRcvd speed-matching service: matching the send rate to the receiving app’s drain rate Receiver advertises spare room by including value of “window sizes” in segments KUT

7. Sender Receiver t wndbytes rtt Window Advertisement Issues • Persist when AdvertisedWindow = 0 • send a segment with 1 byte of data every so often which triggers a response that contains the current advertised window (eventually nonzero) • Flow Control can limit Throughput • Let rtt be the round-trip time, i.e., the time from sending a segmentuntil an acknowledgement (ACK) is received • Let t = wnd/b be the time to transmit a full “window” of data, where b is link bandwidth • Throughput is wnd/rtt KUT

8. TCP Congestion Control KUT

9. TCP Congestion Control • Congestion: • informally: “too many sources sending too much data too fast for network to handle” • different from flow control! • Resultants: • long delays (queueing in router buffers) • lost packets (buffer overflow at routers) KUT

10. TCP Congestion Control • Flow Control vs. Congestion Control Src Dest Limits amount ofdata that destinationmust buffer Src Dest Attempts to reducebuffer overflow insidethe network KUT

11. 10 Mbps 1.5 Mbps 10 Mbps Congestion Collapse • If both sources send full speed, the router is completely overwhelmed • congestion collapse: senders lose data from congestion and they retransmit the data, causing more congestion (can be self-reinforcing) KUT

12. Basic Rule • Basic Rule • End-to-end congestion control • IP layer provides no explicit feedback regarding network congestion • There is no (or little) congestion  TCP sender increases its send rate • There is congestion along the path  TCP sender reduces its send rate KUT

13. Basic Rule • Window Size Determination • What does flow control do? • avoids overrunning the receiver • What does congestion control do? • avoid overrunning router buffers; avoid saturating the network • Congestion Window (=cwin) • It imposes a constraint on the rate at which a TCP sender can send traffic into the network • cwnd (congestion control window) • It is what the sender can handle • wnd (flow control window) • It is what the receiver can handle KUT

14. Basic Rule • Window Size Determination • What mechanism do weuse? • use both windows • [flow control] wnd (=AdvertisedWindow) • [congestion control] cwnd • actual window used is the MIN of wnd and cwnd Dynamic Window Size (version 1.0): Windows Size = min{cwin, wnd} KUT

15. TCP Congestion Principals • Underlying principle: packet conservation • at equilibrium, inject packet into network only when one is removed • basis for stability of physical systems • TCP components: • how to get there (equilibrium): slow start • how to stay there (equilibrium): congestion avoidance KUT

16. Slow Start • Initialize cwnd = 1 (MSS) • Upon receipt of every ACK, cwnd++ • TCP sender maintains three new variables: • cwnd – congestion window • It is determined by inferred information about the level of congestion in the network. • ssthresh – slow-start threshold • It can be thought of as an estimate of the level below which congestion is not expected • ssthresh is typically set to very large value on connection setup • Flight Size • No. of unacknowledgedsegments • Implications • Will overshoot window and cause packet loss • but remember, packet loss is part of the plan KUT

17. Slow Start algorithm time Slow Start • Slow Start • When connection begins, cwin = 1 MSS • Example: MSS = 500 bytes & RTT = 200 msec • initial rate(thrughput) = 20 kbps • available bandwidth may be >> MSS/RTT • desirable to quickly ramp up to respectable rate Host A Host B one segment RTT two segments Delayed & Cumulative Ack initialize: cwin = 1 for (each segment ACKed) cwin++ until (loss event || cwin >ssthresh) four segments Summary: initial rate is slow but ramps up exponentially fast Exponential increase (per RTT) in window size KUT

18. Slow Start Example [Jacobson88a] Van Jacobson. Congestion avoidance and control.In Proceedings of the SIGCOMM '88, pages 314-329, Stanford, California, August 1988. ACM. (redrawn from [Jacobson88a] Fig 2) one RTT 0R 1 one pkt time 1R 1 2 3 2R 2 3 4 6 5 7 4 5 6 7 3R 8 10 12 14 (This gives exponential growth of cwnd) 9 11 13 15 KUT

19. Slow Start Time-Sequence Plot Data (KB) Actually, the slow-start window increase isn’t that slow: time KUT

20. SSTHRESH SSTHRESH When “Slow Start” ends? Q: When should the exponential increase switch to linear? A: do end when cwnd > ssthreshand move to “Congestion Avoidance phase” KUT

21. SSTHRESH SSTHRESH At Loss Event (Timeout), what happen? Q: at Loss event, what happen? A:ssthresh is set to 1/2 of Flight Size • ssthresh = max {Flight Size/2, 2*MSS} • and cwin=1 KUT

22. Slow Start and Congestion Avoidance • State Transition • cwin instead set to 1 MSS; • window then grows exponentially • to ssthresh, then grows linearly • Congestion Avoidance • upon receiving a bunch of ACKs • Increase cwnd by 1/cwnd for each segment ACKed • This is additive increase • why not multiplicative increase? • growing too fast in equilibrium => oscillations Slow Start Congestion Avoidance SSTHRESH SSTHRESH KUT

23. Slow Start and Congestion Avoidance Slow Start: aggressively grow congestion window until congestion is detected Congestion Avoidance • Initially: • cwnd = 1*MSS (Maximum Segment Size) • ssthresh is very large. • If no loss: • cwnd++ (after each segment ACKed) (This gives exponential growth of cwnd) • If loss (timeout): • ssthresh = max{flight size/2, 2*MSS} (multiplicative decrease) • cwnd = 1*MSS • Timeout Interval = 2 * Timeout Interval • If no loss: • increase cwnd at most 1*MSS per RTT (a bunch of ACKs) (additive increase) • If loss (timeout): • ssthresh = max{flight size/2, 2*MSS} (multiplicative decrease) • cwnd = 1*MSS. • Timeout Interval = 2 * Timeout Interval KUT

24. Slow Start and Congestion Avoidance • Initally: • - cwnd = 1*MSS • - ssthresh = very high • If a new ACK comes: • - if cwnd < ssthresh update cwnd according to slow start • if cwnd  ssthresh  update cwnd according to congestion avoidance • If timeout (i.e. loss) : • - ssthresh = max{flight size/2, 2*MSS} ; • - cwnd = 1*MSS • - Timeout Interval = 2 * Timeout Interval (initial) ssthresh cwnd Loss, e.g. timeout ssthresh time slow start – in green congestion avoidance – in blue KUT

25. Slow Start and Congestion Avoidance KUT

26. Problems So Far • have way to fill pipe (slow start) • have way to run at equilibrium (congestion avoidance) • but at packet loss (timeout) • cwin becomes one  Too crude • ssthresh causes ultimately packet loss, every time Need to quickly recover from packet loss KUT

27. Fallback Mechanism: Timeout • Retransmission TimeOut (RTO) • if no ACK after RTO fires,reset cwnd=1 and resend lowest unACK’ed segmentand Timeout Interval = 2 * Timeout Interval • but they’re very crude • force slow-start again • Long TCP timeouts lead to idle periods • Retransmission is possible after such a LONG timeout. • are very slow—a long time with no traffic • …but is there more information? KUT

28. Could We Do Better? • Receipt of dupACKs tells the sender that the receiver is still getting new segments, i.e. there is still data flowing between sender and receiver • Why does sender go back to slow start always? KUT

29. Fast Retransmit & Fast Recovery • Fast Retransmit • allows and uses duplicate ACKs to trigger retransmission • sender doesn't wait for timeout, but retransmits the missing packet instantly • Reaction to 3 dup ACKs (before timeout) for Segment N • i.e. 4 identical ACKs without the arrival of any other intervening packets, • Retransmits the segment N without waiting for timeout • And move to Fast Recovery phase Fast Retransmit Philosophy: • 3 dup ACKs indicates network capable of delivering some segments • timeout indicates a “more alarming” congestion scenario KUT

30. Fast Retransmit & Fast Recovery • Fast Retransmit • a duplicate ACK implies the receiver gota packet out of order • an earlier packet might have been lost (or delayed) • TCP sender waits until it sees three duplicateACKs before retransmitting a packet KUT

31. Fast Retransmit & Fast Recovery • Fast Recovery • SSTHRESH is cut in half of cwnd • ssthresh = max {flight size/2, 2*MSS} • Set cwnd as follows: • cwnd = ssthresh + 3 • window then grows linearly • cwnd++ for each dup ack arrival • Additive increase for every subsequent dup ACK • Transmit a segment if permitted by cwnd • When a new ACK received • Exit Fast Recovery phase • Reset cwnd to ssthresh (resume congestion avoidance) • When Timeout occurs  perform Slow-Start This artificially "inflates" the congestion window by the numberof dup segments (three) that have been sent and acked It will acknowledge receiving all segments sent till moving to Fast Recovery phase (assuming that no more segments were lost). in orderto reflect the additional segment that has been sent and which the receiver has buffered KUT

32. Fast Retransmit & Fast Recovery cwnd (initial) ssthresh fast-retransmit fast-retransmit new ACK timeout new ACK cwnd oscillates around the optimal window size ssthresh = flight size/2 Time Slow Start Congestion Avoidance roughly a 20% improvement in the throughput “inflating” cwnd with dupACKs “deflating” cwnd with a new ACK KUT

33. TCP Congestion Control - Summary • Congestion Control Summary • When cwin is below SSTHRESH, • sender in slow-start phase, window grows exponentially. • When cwin is above SSTHRESH, • sender is in congestion-avoidance phase, window grows linearly. • When a triple duplicate ACK occurs, • Immediately retransmit the packet  named Fast Retransmit • ssthresh set to max {0.5 * flight size, 2*MSS} and cwin set to ssthresh+3.  named Fast Recovery • When timeout occurs, • ssthresh set to cwin/2 and cwin is set to 1 MSS. “Fast” – because it doesn’t wait for time outwhen not getting an ACK for a segment KUT

34. TCP Congestion Control - Summary • Slow-Start • Additive-Increase, Multiplicative-Decrease (AIMD) • Approach: increase transmission rate until loss occurs • additive increase ( congestion avoidance phase) • increase cwin by 1 MSS every RTT until loss detected • continuously probing for usable bandwidth • multiplicative decrease ( Fast Retransmit + Recovery or Timeout) • cut cwin in half after loss (4020105) • Minimum cwin size = 1 MSS Saw tooth behavior: probing for bandwidth KUT