15 441 Computer Networking TCP cont Overview TCP

15 -441 Computer Networking TCP (cont. )

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

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 Rate Lecture 16: 10 -30 -01 Time 3

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

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

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

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: 10 -30 -01 7

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

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

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. 5 w • • If cwnd < ssthresh, use slow start Else use congestion avoidance Lecture 16: 10 -30 -01 10

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

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

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

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: 10 -30 -01 14

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

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

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

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: 10 -30 -01 18

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

New. Reno • The ack that arrives after retransmission (partial ack) could indicate that a second loss occurred • When does New. Reno 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: 10 -30 -01 20

New. Reno X X Now what? – partial ack recovery Sequence No Time Lecture 16: 10 -30 -01 21

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: 10 -30 -01 22

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

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: 10 -30 -01 24

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

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: 10 -30 -01 26

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: 10 -30 -01 27

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

New. Reno 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: 10 -30 -01 29

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

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 200 ms Start with > 1 initial window • Bug in BSD, now a “feature”/standard Lecture 16: 10 -30 -01 31

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

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

Protection From Wraparound • Wraparound time vs. Link speed • • • 1. 5 Mbps: 6. 4 hours 10 Mbps: 57 minutes 45 Mbps: 13 minutes 100 Mbps: 6 minutes 622 Mbps: 55 seconds < MSL! 1. 2 Gbps: 28 seconds • Use timestamp to distinguish sequence number wraparound Lecture 16: 10 -30 -01 34

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

Window Scaling: Example Use of Options • “Large window” option (RFC 1323) • • The scaling factor specifies bit shift of the window field in the TCP header • • TCP syn SW? 3 TCP syn, ack SW yes SW? Definition of an option 3 2 TCP ack Scaling results in a loss of accuracy • • Scaling value of 2 translates into a factor of 4 Old TCP implementations will simply ignore the option • • 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 SW yes Not a big deal Alternatives? Lecture 16: 10 -30 -01 2 36

Large Windows • Delay-bandwidth product for 100 ms delay • • • 1. 5 Mbps: 18 KB 10 Mbps: 122 KB > max 16 bit window 45 Mbps: 549 KB 100 Mbps: 1. 2 MB 622 Mbps: 7. 4 MB 1. 2 Gbps: 14. 8 MB • Scaling factor on advertised window • • Specifies how many bits window must be shifted to the left Scaling factor exchanged during connection setup Lecture 16: 10 -30 -01 37

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: 10 -30 -01 38

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

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 • • RTT • • Affects increase rate and relates BW to window RTO • • Affects how often window is reduced Affects performance during loss recovery MSS • Affects increase rate Lecture 16: 10 -30 -01 40

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

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: 10 -30 -01 42

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

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: 10 -30 -01 44

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

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: 10 -30 -01 46

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

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: 10 -30 -01 48

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: 10 -30 -01 49

Enhanced TCP Loss Recovery 4 Server 6 5 Router 3 8 Router Client 3 Client 7 Server Client Data Packets Acknowledgments Lecture 16: 10 -30 -01 50

Enhanced TCP Loss Recovery Server 3 Router 4 3 Client Router Server Client Data Packets Acknowledgments Lecture 16: 10 -30 -01 51

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)) [rfc 2414] Enables fast retransmission Only used in initial slow start not in any subsequent slow start Lecture 16: 10 -30 -01 52

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: 10 -30 -01 53

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: 10 -30 -01 54

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

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

TCP Header Source port Destination port Sequence number Flags: SYN FIN RESET PUSH URG ACK Acknowledgement Hdr. Len 0 Flags Advertised window Checksum Urgent pointer Options (variable) Data Lecture 16: 10 -30 -01 57

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: 10 -30 -01 58

Non-reliable Protocols • IPv 6 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 Lecture 16: 10 -30 -01 59