2. 1 Flow Control

3. 2 TCP Flow Control receiver: explicitly informs sender of (dynamically changing) amount of free buffer space  RcvWindow field in TCP segment sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow sender won’t overrun receiver’s buffers by transmitting too much, too fast flow control receiver buffering RcvBuffer = size or TCP Receive Buffer RcvWindow = amount of spare room in Buffer

4. 3 3 TCP Flow Control: How it Works  spare room in buffer = RcvWindow source port # dest port # application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F SR PAU head len not used Options (variable length)

5. 4 TCP: setting timeouts

6. 5 TCP Round Trip Time and Timeout Q: how to set TCP timeout value? r longer than RTT m note: RTT will vary r too short: premature timeout m unnecessary retransmissions r too long: slow reaction to segment loss Q: how to estimate RTT?  SampleRTT : measured time from segment transmission until ACK receipt m ignore retransmissions, cumulatively ACKed segments  SampleRTT will vary, want estimated RTT “smoother”  use several recent measurements, not just current SampleRTT

7. 6 High-level Idea Set timeout = average + safe margin

8. 7 Estimating Round Trip Time EstimatedRTT = (1-  )*EstimatedRTT +  *SampleRTT r Exponential weighted moving average r influence of past sample decreases exponentially fast  typical value:  = 0.125  SampleRTT : measured time from segment transmission until ACK receipt  SampleRTT will vary, want a “smoother” estimated RTT use several recent measurements, not just current SampleRTT

9. 8 Setting Timeout Problem:  using the average of SampleRTT will generate many timeouts due to network variations Solution:  EstimtedRTT plus “safety margin”  large variation in EstimatedRTT -> larger safety margin TimeoutInterval = EstimatedRTT + 4*DevRTT DevRTT = (1-  )*DevRTT +  *|SampleRTT-EstimatedRTT| (typically,  = 0.25) Then set timeout interval: RTT freq.

10. 9 An Example TCP Session

11. 10 TCP Round Trip Time and Timeout EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT r Exponential weighted moving average r influence of given sample decreases exponentially fast r typical value of x: 0.1 Setting the timeout  EstimtedRTT plus “safety margin”  large variation in EstimatedRTT -> larger safety margin Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|

12. 11 Fast retransmit

13. 12 Fast Retransmit r Timeout period often relatively long: m long delay before resending lost packet r Detect lost segments via duplicate ACKs m sender often sends many segments back-to- back m if segment is lost, there will likely be many duplicate ACKs r If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: m resend segment before timer expires

14. 13 Triple Duplicate Ack 1 23456 23 4 Packets Acknowledgements (waiting seq#) 4 4 7 4

15. 14 event: ACK received, with ACK field value of y if (y > SendBase) { … SendBase = y if (there are currently not-yet-acknowledged segments) start timer … } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y … Fast Retransmit: a duplicate ACK for already ACKed segment fast retransmit

16. 15 Congestion Control

17. 16 Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle” r manifestations: m lost packets (buffer overflow at routers) m long delays (queuing in router buffers) r a highly important problem!

18. 17 Causes/costs of congestion: scenario 1 r two senders, two receivers r one router, r infinite buffers r no retransmission

19. 18 Causes/costs of congestion: scenario 1 r Throughput increases with load r Maximum total load C (Each session C/2) r Large delays when congested m The load is stochastic

20. 19 Causes/costs of congestion: scenario 2 r one router, finite buffers r sender retransmission of lost packet

21. 20 Causes/costs of congestion: scenario 2 r always: (goodput) m Like to maximize goodput! r “perfect” retransmission: m retransmit only when loss: r Actual retransmission of delayed (not lost) packet r makes larger (than perfect case) for same in out = out in out > in

22. 21 Causes/costs of congestion: scenario 2 “costs” of congestion: r more work (retrans) for given “goodput” r unneeded retransmissions: link carries (and delivers) multiple copies of pkt out ’ in out ’ in

23. 22 Causes/costs of congestion: scenario 3 r four senders r multihop paths r timeout/retransmit in Q: what happens as and increase ? in

24. 23 Causes/costs of congestion: scenario 3 Another “cost” of congestion: r when packet dropped, any “upstream” transmission capacity used for that packet was wasted!

25. 24 Approaches towards congestion control End-end congestion control: r no explicit feedback from network r congestion inferred from end-system observed loss, delay r approach taken by TCP Network-assisted congestion control: r routers provide feedback to end systems m single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) m explicit rate sender should send at Two broad approaches towards congestion control:

26. 25 Goals of congestion control r Throughput: m Maximize goodput m the total number of bits end-end r Fairness: m Give different sessions “equal” share. m Max-min fairness Maximize the minimum rate session. m Single link: Capacity R sessions m Each sessions: R/m

27. 26 Max-min fairness r Model: Graph G(V,e) and sessions s 1 … s m r For each session s i a rate r i is selected. r The rates are a Max-Min fair allocation: m The allocation is maximal No r i can be simply increased m Increasing allocation r i requires reducing Some session j r j ≤ r i r Maximize minimum rate session.

28. 27 Max-min fairness: Algorithm r Model: Graph G(V,e) and sessions s 1 … s m r Algorithmic view: m For each link compute its fair share f(e). Capacity / # session m select minimal fair share link. m Each session passing on it, allocate f(e). m Subtract the capacities and delete sessions m continue recessively. r Fluid view.

29. 28 Max-min fairness r Example r Throughput versus fairness.

30. 29 Case study: ATM ABR congestion control ABR: available bit rate: r “elastic service” r if sender’s path “underloaded”: m sender can use available bandwidth r if sender’s path congested: m sender lowers rate m a minimum guaranteed rate r Aim: m coordinate increase/decrease rate m avoid loss!

31. 30 Case study: ATM ABR congestion control RM (resource management) cells: r sent by sender, in between data cells m one out of every 32 cells. r RM cells returned to sender by receiver r Each router modifies the RM cell r Info in RM cell set by switches m “network-assisted” r 2 bit info. m NI bit: no increase in rate (mild congestion) m CI bit: congestion indication (lower rate)

32. 31 Case study: ATM ABR congestion control r two-byte ER (explicit rate) field in RM cell m congested switch may lower ER value in cell m sender’ send rate thus minimum supportable rate on path r EFCI bit in data cells: set to 1 in congested switch m if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell

33. 32 Case study: ATM ABR congestion control r How does the router selects its action: m selects a rate m Set congestion bits m Vendor dependent functionality r Advantages: m fast response m accurate response r Disadvantages: m network level design m Increase router tasks (load). m Interoperability issues.

34. 33 End to end control

35. 34 End to end feedback r Abstraction: m Alarm flag. m observable at the end stations

36. 35 Simple Abstraction

37. 36 Simple Abstraction

38. 37 Simple feedback model r Every RTT receive feedback m High Congestion Decrease rate m Low congestion Increase rate r Variable rate controls the sending rate.

39. 38 Multiplicative Update r Congestion: m Rate = Rate/2 r No Congestion: m Rate= Rate *2 r Performance m Fast response m Un-fair: Ratios unchanged

40. 39 Additive Update r Congestion: m Rate = Rate -1 r No Congestion: m Rate= Rate +1 r Performance m Slow response r Fairness: m Divides spare BW equally m Difference remains unchanged

41. 40 AIMD Scheme r Additive Increase m Fairness: ratios improves r Multiplicative Decrease m Fairness: ratio unchanged m Fast response r Performance: m Congestion - Fast response m Fairness overflow

42. 41 AIMD: Two users, One link BW limit Fairness Rate of User 1 Rate of User 2

43. 42 TCP Congestion Control r Closed-loop, end-to-end, window-based congestion control r Designed by Van Jacobson in late 1980s, based on the AIMD alg. of Dah-Ming Chu and Raj Jain r Works well so far: the bandwidth of the Internet has increased by more than 200,000 times r Many versions m TCP/Tahoe: this is a less optimized version m TCP/Reno: many OSs today implement Reno type congestion control m TCP/Vegas: not currently used For more details: see TCP/IP illustrated; or read http://lxr.linux.no/source/net/ipv4/tcp_input.c for linux implementation

44. 43 TCP/Reno Congestion Detection 3 dup ACKs indicates network capable of delivering some segments timeout is “more alarming” Philosophy: r Detect congestion in two cases and react differently: m 3 dup ACKs m timeout event

45. 44 Basic Structure r Two “phases” m slow-start: MI m congestion avoidance: AIMD r Important variables:  cwnd: congestion window size  ssthresh: threshold between the slow- start phase and the congestion avoidance phase

46. 45 Visualization of the Two Phases

47. 46 Slow Start: MI r What is the goal? m getting to equilibrium gradually but quickly r Implements the MI algorithm m double cwnd every RTT until network congested  get a rough estimate of the optimal of cwnd

48. 47 Slow-start ACK for segment 1 segment 1 cwnd = 1 cwnd = 2 segment 2 segment 3 ACK for segments 2 + 3 cwnd = 4 segment 4 segment 5 segment 6 segment 7 cwnd = 6 Initially: cwnd = 1; ssthresh = infinite (e.g., 64K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; cwnd = 8

49. 48 Startup Behavior with Slow-start See [Jac89]

50. 49 TCP/Reno Congestion Avoidance r Maintains equilibrium and reacts around equilibrium r Implements the AIMD algorithm m increases window by 1 per round-trip time (how?) m cuts window size to half when detecting congestion by 3DUP to 1 if timeout if already timeout, doubles timeout

51. 50 TCP/Reno Congestion Avoidance Initially: cwnd = 1; ssthresh = infinite (e.g., 64K); For each newly ACKed segment: if (cwnd < ssthresh) /* slow start*/ cwnd = cwnd + 1; else /* congestion avoidance; cwnd increases (approx.) by 1 per RTT */ cwnd += 1/cwnd; Triple-duplicate ACKs: /* multiplicative decrease */ cwnd = ssthresh = cwnd/2; Timeout: ssthresh = cwnd/2; cwnd = 1; (if already timed out, double timeout value; this is called exponential backoff)

52. 51 TCP/Reno: Big Picture Time cwnd slow start congestion avoidance TD TD: Triple duplicate acknowledgements TO: Timeout TO ssthresh congestion avoidance TD congestion avoidance slow start congestion avoidance TD

53. 52 A Session Question: when cwnd is cut to half, why sending rate is not?

54. 53 TCP/Reno Queueing Dynamics r Consider congestion avoidance only Time cwnd congestion avoidance TD ssthresh bottleneck bandwidth filling buffer draining buffer There is a filling and draining of buffer process for each TCP flow.

55. 54 TCP & AIMD: congestion r Dynamic window size [Van Jacobson] m Initialization: Slow start m Steady state: AIMD r Congestion = timeout m TCP Tahoe r Congestion = timeout || 3 duplicate ACK m TCP Reno & TCP new Reno r Congestion = higher latency m TCP Vegas

56. 55 TCP Congestion Control r end-end control (no network assistance)  transmission rate limited by congestion window size, Congwin, over segments: r w segments, each with MSS bytes sent in one RTT: throughput = w * MSS RTT Bytes/sec Congwin

57. 56 TCP congestion control: r two “phases” m slow start m congestion avoidance r important variables:  Congwin  threshold: defines threshold between two slow start phase, congestion control phase r “probing” for usable bandwidth:  ideally: transmit as fast as possible ( Congwin as large as possible) without loss  increase Congwin until loss (congestion)  loss: decrease Congwin, then begin probing (increasing) again

58. 57 TCP Slowstart r exponential increase (per RTT) in window size (not so slow!) r In case of timeout: m Threshold=CongWin/2 initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (congestion event OR CongWin > threshold) Slowstart algorithm Host A one segment RTT Host B time two segments four segments

59. 58 TCP Tahoe Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (timeout) { /* loss event */ every ACK: Congwin += 1/Congwin } threshold = Congwin/2 Congwin = 1 perform slowstart Congestion avoidance TCP Taheo

60. 59 TCP Reno r Fast retransmit: m After receiving 3 duplicate ACK m Resend first packet in window. Try to avoid waiting for timeout r Fast recovery: m After retransmission do not enter slowstart. m Threshold = Congwin/2 m Congwin = 3 + Congwin/2 m Each duplicate ACK received Congwin++ m After new ACK Congwin = Threshold return to congestion avoidance r Single packet drop: great!

61. 60 TCP Congestion Window Trace

62. 61 TCP Vegas: r Idea: track the RTT m Try to avoid packet loss m latency increases: lower rate m latency very low: increase rate r Implementation: m sample_RTT: current RTT m Base_RTT: min. over sample_RTT m Expected = Congwin / Base_RTT m Actual = number of packets sent / sample_RTT m  =Expected - Actual

63. 62 TCP Vegas r  = Expected - Actual r Congestion Avoidance: m two parameters:  and ,  <  m If (  <  ) Congwin = Congwin +1 m If (  >  ) Congwin = Congwin -1 m Otherwise no change m Note: Once per RTT r Slowstart m parameter  m If (  >  ) then move to congestion avoidance r Timeout: same as TCP Taheo

64. 63 TCP Dynamics: Rate r TCP Reno with NO Fast Retransmit or Recovery r Sending rate: Congwin*MSS / RTT r Assume fixed RTT W W/2 r Actual Sending rate: m between W*MSS / RTT and (1/2) W*MSS / RTT m Average (3/4) W*MSS / RTT

65. 64 TCP Dynamics: Loss r Loss rate (TCP Reno) m No Fast Retransmit or Recovery r Consider a cycle r Total packet sent: m about (3/8) W 2 MSS/RTT = O(W 2 ) m One packet loss r Loss Probability: p=O(1/W 2 ) or W=O(1/  p) W W/2

66. 65 TCP latency modeling Q: How long does it take to receive an object from a Web server after sending a request? r TCP connection establishment r data transfer delay Notation, assumptions: r Assume one link between client and server of rate R r Assume: fixed congestion window, W segments r S: MSS (bits) r O: object size (bits) r no retransmissions m no loss, no corruption

67. 66 TCP latency modeling Optimal Setting: Time = O/R Two cases to consider: r WS/R > RTT + S/R: m ACK for first segment in window returns before window’s worth of data sent r WS/R < RTT + S/R: m wait for ACK after sending window’s worth of data sent

68. 67 TCP latency Modeling Case 1: latency = 2RTT + O/R Case 2: latency = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] K:= O/WS

69. 68 TCP Latency Modeling: Slow Start r Now suppose window grows according to slow start. r Will show that the latency of one object of size O is: where P is the number of times TCP stalls at server: - where Q is the number of times the server would stall if the object were of infinite size. - and K is the number of windows that cover the object.

70. 69 TCP Latency Modeling: Slow Start (cont.) Example: O/S = 15 segments K = 4 windows Q = 2 P = min{K-1,Q} = 2 Server stalls P=2 times.

71. 70 TCP Latency Modeling: Slow Start (cont.)