Computer Networking TCP (cont.)

Lecture 16: Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

Lecture 16: 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

Lecture 16: 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

Lecture 16: Congestion Avoidance Sequence Plot Time Sequence No

Lecture 16: Congestion Avoidance Behavior Time Congestion Window Packet loss + Timeout Grabbing back Bandwidth Cut Congestion Window and Rate

Lecture 16: 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

Lecture 16: Slow Start Example 1 One RTT One pkt time 0R 2 1R 3 4 2R R

Lecture 16: Slow Start Sequence Plot Time Sequence No......

Lecture 16: 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

Lecture 16: TCP Saw Tooth Behavior Time Congestion Window Initial Slowstart Fast Retransmit and Recovery Slowstart to pace packets Timeouts may still occur

Lecture 16: Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

Lecture 16: 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

Lecture 16: 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

Lecture 16: Fast Retransmit Time Sequence No Duplicate Acks Retransmission X

Lecture 16: Multiple Losses Time Sequence No Duplicate Acks Retransmission X X X X Now what?

Lecture 16: Time Sequence No X X X X Tahoe

Lecture 16: 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

Lecture 16: Reno Time Sequence No X X X X Now what? - timeout

Lecture 16: 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

Lecture 16: NewReno Time Sequence No X X X X Now what? – partial ack recovery

Lecture 16: 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

Lecture 16: SACK Time Sequence No X X X X Now what? – send retransmissions as soon as detected

Lecture 16: 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?

Lecture 16: Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

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

Lecture 16: 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

Lecture 16: Fast Recovery Time Sequence No Sent for each dupack after W/2 dupacks arrive X

Lecture 16: 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

Lecture 16: Rate Halving Recovery Time Sequence No Sent after every other dupack X

Lecture 16: 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

Lecture 16: Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

Lecture 16: TCP Extensions Implemented using TCP options Timestamp Protection from sequence number wraparound Large windows

Lecture 16: 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

Lecture 16: Window Size vs Throughput Sender Time Throughput = Window Size Roundtrip Time RTT Receiver

Lecture 16: 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

Lecture 16: 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

Lecture 16: 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?

Lecture 16: Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

Lecture 16: 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

Lecture 16: Overall TCP Behavior Time Window Let’s concentrate on steady state behavior with no timeouts and perfect loss recovery

Lecture 16: 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

Lecture 16: 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))

Lecture 16: 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?

Lecture 16: Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

Lecture 16: 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

Lecture 16: 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

Lecture 16: 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?

Lecture 16: 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

Lecture 16: Enhanced TCP Loss Recovery Router Data Packets Acknowledgments ClientServer Client

Lecture 16: Enhanced TCP Loss Recovery Router 4 33 Data Packets Acknowledgments Server Client

Lecture 16: 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

Lecture 16: 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

Lecture 16: 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

Lecture 16: Overview TCP congestion control TCP modern loss recovery TCP interactions TCP options TCP modeling Workload changes Header compression

Lecture 16: 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

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

Lecture 16: 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?

Lecture 16: 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