1. 15-441 Computer Networking TCP (cont.)

2. Lecture 16: 10-30-012 Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

3. Lecture 16: 10-30-013 TCP Congestion Control Packet loss is seen as sign of congestion and results in a multiplicative rate decrease Factor of 2 TCP periodically probes for available bandwidth by increasing its rate Time Rate

4. Lecture 16: 10-30-014 Congestion Avoidance If loss occurs when cwnd = W Network can handle 0.5W ~ W segments Set cwnd to 0.5W (multiplicative decrease) Upon receiving ACK Increase cwnd by 1/cwnd Implements AIMD

5. Lecture 16: 10-30-015 Congestion Avoidance Sequence Plot Time Sequence No

6. Lecture 16: 10-30-016 Congestion Avoidance Behavior Time Congestion Window Packet loss + Timeout Grabbing back Bandwidth Cut Congestion Window and Rate

7. Lecture 16: 10-30-017 Slow Start Packet Pacing How do we get this clocking behavior to start? Initialize cwnd = 1 Upon receipt of every ack, cwnd = cwnd + 1 Implications Window actually increases to W in RTT * log 2 (W) Can overshoot window and cause packet loss

8. Lecture 16: 10-30-018 Slow Start Example 1 One RTT One pkt time 0R 2 1R 3 4 2R 5 6 7 8 3R 9 10 11 12 13 14 15 1 23 4567

9. Lecture 16: 10-30-019 Slow Start Sequence Plot Time Sequence No......

10. Lecture 16: 10-30-0110 Return to Slow Start If packet is lost we lose our self clocking as well Need to implement slow-start and congestion avoidance together When timeout occurs set ssthresh to 0.5w If cwnd < ssthresh, use slow start Else use congestion avoidance

11. Lecture 16: 10-30-0111 TCP Saw Tooth Behavior Time Congestion Window Initial Slowstart Fast Retransmit and Recovery Slowstart to pace packets Timeouts may still occur

12. Lecture 16: 10-30-0112 Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

13. Lecture 16: 10-30-0113 TCP Flavors Tahoe, Reno, Vegas TCP Tahoe (distributed with 4.3BSD Unix) Original implementation of Van Jacobson’s mechanisms (VJ paper) Includes: Slow start Congestion avoidance Fast retransmit

14. Lecture 16: 10-30-0114 Fast Retransmit What are duplicate acks (dupacks)? Repeated acks for the same sequence When can duplicate acks occur? Loss Packet re-ordering Window update – advertisement of new flow control window Assume re-ordering is infrequent and not of large magnitude Use receipt of 3 or more duplicate acks as indication of loss Don’t wait for timeout to retransmit packet

15. Lecture 16: 10-30-0115 Fast Retransmit Time Sequence No Duplicate Acks Retransmission X

16. Lecture 16: 10-30-0116 Multiple Losses Time Sequence No Duplicate Acks Retransmission X X X X Now what?

17. Lecture 16: 10-30-0117 Time Sequence No X X X X Tahoe

18. Lecture 16: 10-30-0118 TCP Reno (1990) All mechanisms in Tahoe Addition of fast-recovery Opening up congestion window after fast retransmit Delayed acks Header prediction Implementation designed to improve performance Has common case code inlined With multiple losses, Reno typically timeouts because it does not see duplicate acknowledgements

19. Lecture 16: 10-30-0119 Reno Time Sequence No X X X X Now what? - timeout

20. Lecture 16: 10-30-0120 NewReno The ack that arrives after retransmission (partial ack) could indicate that a second loss occurred When does NewReno timeout? When there are fewer than three dupacks for first loss When partial ack is lost How fast does it recover losses? One per RTT

21. Lecture 16: 10-30-0121 NewReno Time Sequence No X X X X Now what? – partial ack recovery

22. Lecture 16: 10-30-0122 SACK Basic problem is that cumulative acks only provide little information Ack for just the packet received What if acks are lost?  carry cumulative also Not used Bitmask of packets received Selective acknowledgement (SACK) How to deal with reordering

23. Lecture 16: 10-30-0123 SACK Time Sequence No X X X X Now what? – send retransmissions as soon as detected

24. Lecture 16: 10-30-0124 Performance Issues Timeout >> fast rexmit Need 3 dupacks/sacks Not great for small transfers Don’t have 3 packets outstanding What are real loss patterns like? Right edge recovery Allow packets to be sent on arrival of first and second duplicate ack Helps recovery for small windows How to deal with reordering?

25. Lecture 16: 10-30-0125 Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

26. Lecture 16: 10-30-0126 How to Change Window When a loss occurs have W packets outstanding New cwnd = 0.5 * cwnd How to get to new state?

27. Lecture 16: 10-30-0127 Fast Recovery Each duplicate ack notifies sender that single packet has cleared network When < cwnd packets are outstanding Allow new packets out with each new duplicate acknowledgement Behavior Sender is idle for some time – waiting for ½ cwnd worth of dupacks Transmits at original rate after wait Ack clocking rate is same as before loss

28. Lecture 16: 10-30-0128 Fast Recovery Time Sequence No Sent for each dupack after W/2 dupacks arrive X

29. Lecture 16: 10-30-0129 NewReno Changes Send a new packet out for each pair of dupacks Adapt more gradually to new window Will not halve congestion window again until recovery is completed Identifies congestion events vs. congestion signals

30. Lecture 16: 10-30-0130 Rate Halving Recovery Time Sequence No Sent after every other dupack X

31. Lecture 16: 10-30-0131 Delayed Ack Impact TCP congestion control triggered by acks If receive half as many acks  window grows half as fast Slow start with window = 1 Will trigger delayed ack timer First exchange will take at least 200ms Start with > 1 initial window Bug in BSD, now a “feature”/standard

32. Lecture 16: 10-30-0132 Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

33. Lecture 16: 10-30-0133 TCP Extensions Implemented using TCP options Timestamp Protection from sequence number wraparound Large windows

34. Lecture 16: 10-30-0134 Protection From Wraparound Wraparound time vs. Link speed 1.5Mbps: 6.4 hours 10Mbps: 57 minutes 45Mbps: 13 minutes 100Mbps: 6 minutes 622Mbps: 55 seconds  < MSL! 1.2Gbps: 28 seconds Use timestamp to distinguish sequence number wraparound

35. Lecture 16: 10-30-0135 Window Size vs Throughput Sender Time Throughput = Window Size Roundtrip Time RTT Receiver

36. Lecture 16: 10-30-0136 Window Scaling: Example Use of Options “Large window” option (RFC 1323) Negotiated by the hosts during connection establishment Option 3 specifies the number of bits by which to shift the value in the 16 bit window field Independently set for the two transmit directions The scaling factor specifies bit shift of the window field in the TCP header Scaling value of 2 translates into a factor of 4 Old TCP implementations will simply ignore the option Definition of an option Scaling results in a loss of accuracy Not a big deal Alternatives? TCP syn SW?3 TCP syn,ack SW yes 3 SW?2 TCP ack SW yes 2

37. Lecture 16: 10-30-0137 Large Windows Delay-bandwidth product for 100ms delay 1.5Mbps: 18KB 10Mbps: 122KB > max 16bit window 45Mbps: 549KB 100Mbps: 1.2MB 622Mbps: 7.4MB 1.2Gbps: 14.8MB Scaling factor on advertised window Specifies how many bits window must be shifted to the left Scaling factor exchanged during connection setup

38. Lecture 16: 10-30-0138 Maximum Segment Size (MSS) Exchanged at connection setup Typically pick MTU of local link What all does this effect? Efficiency Congestion control Retransmission Path MTU discovery Why should MTU match MSS?

39. Lecture 16: 10-30-0139 Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

40. Lecture 16: 10-30-0140 TCP Modeling Given the congestion behavior of TCP can we predict what type of performance we should get? What are the important factors Loss rate Affects how often window is reduced RTT Affects increase rate and relates BW to window RTO Affects performance during loss recovery MSS Affects increase rate

41. Lecture 16: 10-30-0141 Overall TCP Behavior Time Window Let’s concentrate on steady state behavior with no timeouts and perfect loss recovery

42. Lecture 16: 10-30-0142 Simple TCP Model Some additional assumptions Fixed RTT No delayed ACKs In steady state, TCP losses packet each time window reaches W packets Window drops to W/2 packets Each RTT window increases by 1 packet  W/2 * RTT before next loss BW = MSS * avg window/RTT = MSS * (W + W/2)/(2 * RTT) =.75 * MSS * W / RTT

43. Lecture 16: 10-30-0143 Simple Loss Model What was the loss rate? Packets transferred = (.75 W/RTT) * (W/2 * RTT) = 3W 2 /8 1 packet lost  loss rate = p = 8/3W 2 W = sqrt( 8 / (3 * loss rate)) BW =.75 * MSS * W / RTT BW = MSS / (RTT * sqrt (2/3p))

44. Lecture 16: 10-30-0144 TCP Friendliness What does it mean to be TCP friendly? TCP is not going away Any new congestion control must compete with TCP flows Should not clobber TCP flows and grab bulk of link Should also be able to hold its own, i.e. grab its fair share, or it will never become popular How is this quantified/shown? Has evolved into evaluating loss/throughput behavior If it shows 1/sqrt(p) behavior it is ok But is this really true?

45. Lecture 16: 10-30-0145 Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

46. Lecture 16: 10-30-0146 Changing Workloads New applications are changing the way TCP is used 1980’s Internet Telnet & FTP  long lived flows Well behaved end hosts Homogenous end host capabilities Simple symmetric routing 2000’s Internet Web & more Web  large number of short xfers Wild west – everyone is playing games to get bandwidth Cell phones and toasters on the Internet Policy routing

47. Lecture 16: 10-30-0147 Problems with Short Concurrent Flows Compete for resources N “slow starts” = aggressive No shared learning = inefficient Entire life is in slow start Fast retransmission is rare f(n) f2 f1 Server Client Internet

48. Lecture 16: 10-30-0148 Sharing Information Congestion control Share a single congestion window across all connections to a destination Advantages Applications can’t defeat congestion control by opening multiple connections simultaneously Overall loss rate of the network drops Possibly better performance for applications like Web Disadvantages? What if you’re the only one doing this?  you get lousy throughput What about hosts like proxies?

49. Lecture 16: 10-30-0149 Short Transfers Fast retransmission needs at least a window of 4 packets To detect reordering Should not be necessary if small outstanding number of packets Adjust threshold to min(3, cwnd/outstanding) Some paths have much more reordering than others Adapt threshold to past reordering Allow new packets to be transmitted for first few dupacks Will create new dupacks and force retransmission Will not reduce goodput in situations of reordering Follows packet conservation

50. Lecture 16: 10-30-0150 Enhanced TCP Loss Recovery Router Data Packets Acknowledgments 4 65 87 33 ClientServer Client

51. Lecture 16: 10-30-0151 Enhanced TCP Loss Recovery Router 4 33 Data Packets Acknowledgments Server Client

52. Lecture 16: 10-30-0152 Short Transfers Short transfer performance is limited by slow start  RTT Start with a larger initial window What is a safe value? TCP already burst 3 packets into network during slow start Large initial window = min (4*MSS, max (2*MSS, 4380 bytes)) [rfc2414] Enables fast retransmission Only used in initial slow start not in any subsequent slow start

53. Lecture 16: 10-30-0153 Well Behaved vs. Wild West How to ensure hosts/applications do proper congestion control? Who can we trust? Only routers that we control Can we ask routers to keep track of each flow No, we must avoid introducing per flow state into routers Active router mechanisms for control in next lecture

54. Lecture 16: 10-30-0154 TCP Fairness Issues Multiple TCP flows sharing the same bottleneck link do not necessarily get the same bandwidth. Factors such as roundtrip time, small differences in timeouts, and start time, … affect how bandwidth is shared The bandwidth ratio typically does stabilize Modifying the congestion control implementation changes the aggressiveness of TCP and will change how much bandwidth a source gets. Affects “fairness” relative to other flows Changing timeouts, dropping or adding features,.. Users can grab more bandwidth by using parallel flows. Each flow gets a share of the bandwidth to the user gets more bandwidth than users who use only a single flow

55. Lecture 16: 10-30-0155 Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

56. Lecture 16: 10-30-0156 Low Bandwidth Links Efficiency for interactive 40byte headers vs payload size – 1 byte payload for telnet Header compression What fields change between packets? 3 types – fixed, random, differential

57. Lecture 16: 10-30-0157 TCP Header Source portDestination port Sequence number Acknowledgement Advertised windowHdrLen Flags 0 ChecksumUrgent pointer Options (variable) Data Flags: SYN FIN RESET PUSH URG ACK

58. Lecture 16: 10-30-0158 Header Compression What happens if packets are lost or corrupted? Packets created with incorrect fields Checksum makes it possible to identify How is this state recovered from? TCP retransmissions are sent with complete headers Large performance penalty – must take a timeout, no data-driven loss recovery How do you handle other protocols?

59. Lecture 16: 10-30-0159 Non-reliable Protocols IPv6 and other protocols are adding large headers However, these protocols don’t have loss recovery How to recovery compression state Decaying refresh of compression state Suppose compression state is installed by packet X Send full state with X+2, X+4, X+8 until next state Prevents large number of packets being corrupted Heuristics to correct packet Apply differencing fields multiple times