1. CSCE 515: Computer Network Programming Chin-Tser Huang huangct@cse.sc.edu University of South Carolina

2. 3/22/20052 TCP Variants TCP Tahoe: Fast Retransmit and slow start TCP Reno: adding Fast Recover Suffer from multiple packet losses in a window

3. 3/22/20053 TCP Vegas Both Tahoe and Reno have to experience packet loss in order to control throughput Contrast to the reactive strategy of Tahoe and Reno, Vegas employs a proactive strategy Vegas tries to predict when congestion is about to happen and adapts its window to compensate Thus can reduce its sending rate before packets start getting discarded by network

4. 3/22/20054 Vegas Algorithm Use the fact that number of bytes in transit is directly proportional to expected throughput Vegas measures and controls amount of extra data in transit Try not to send too much extra data – will cause congestion Try not to send too little extra data – implies not making use of available bandwidth

5. 3/22/20055 Vegas Algorithm ExpectedRate = CongestionWindow / BaseRTT ActualRate = (BytesOut between T1 and T2) / (T2-T1) Diff = ExpectedRate – ActualRate If Diff < α, increase CongestionWindow linearly Else if Diff > β, decrease CongestionWindow linearly Else if α < Diff < β, leave CongestionWindow the same

6. 3/22/20056 Additive increase and multiplicative decrease (AIMD) Increase cwnd by 1 MSS every RTT in the absence of loss events Cut cwnd in half after a message loss, and apply additive increase again Congestion avoidance in Tahoe and Reno follows AIMD Vegas increases/decreases linearly before packet loss, and follows AIMD after a packet is lost

7. 3/22/20057 TCP Persist Timer When window size goes to 0, sender cannot transmit more data If the ACK that opens window is lost, can end up in a deadlock in which receiver waiting for data and sender waiting for window update Sender uses a persist timer to send window probes to receiver every 60 seconds Until window opens up or either of applications using this connection is terminated

8. 3/22/20058 TCP Keepalive Timer An idle connection may occupy some resources on server side Server sends a probe packet after connection has been idle for 2 hours Controversial because it may cause a good connection to be terminated due to temporary loss of network connectivity

9. 3/22/20059 TCP Keepalive Timer Four scenarios Other end is still up: receive response from other end and reset keepalive timer back to 2 hours Other end has crashed: no response from other end; send 10 more probes every 75 seconds and terminate connection if no response Other end has crashed and rebooted: receive reset from other end and terminate connection Other end is currently unreachable: receive ICMP host unreachable error; send 10 more probes every 75 seconds and terminate connection if unreachable

10. 3/22/200510 TCP Window Scale Option Apply a scaling to 16-bit window size field Shift count is between 0 and 14 Can specify a window of up to 65536*2 14 bytes kind=3len=3 shift count 111

11. 3/22/200511 TCP Timestamp Option Let more segments be accurately timed Sender places a 32-bit value in timestamp value field Receiver echoes it in reply field Timestamp is monotonically increasing kind=8len=10timestamp value 11 4 timestamp echo reply 4

12. 3/22/200512 Wrapped Sequence Numbers TCP Sequence and ACK fields contain 32-bit values If using high-speed connection and a 1GB window, could conceivably wrap the sequence number space to a point where old packets containing a valid sequence number could reappear A monotonically increasing timestamp can extend sequence number to resolve this condition

13. 3/22/200513 T/TCP: Extension for Transaction A transaction usually contains only one client request and one server reply In transaction service, it is desirable to avoid overhead of connection establishment and termination, and to reduce latency to RTT+SPT TCP is too much and UDP is too little T/TCP is an alternative solution

14. 3/22/200514 T/TCP: Extension for Transaction Use 32-bit connection count (CC) option to identify connections opened to a certain host Client packs SYN, request, FIN, CC in first segment If received CC is larger than cached CC, server passes data to application without three-way handshake Reduce transaction sequence to three segments Client to server: client-SYN, client-data, client-FIN, client-CC Server to client: server-SYN, server-data, server-FIN, ACK of client-FIN, server-CC, CCECHO of client-CC Client to server: ACK of server-FIN

15. 3/22/200515 Next Class HyperText Transfer Protocol (HTTP) Read JNP Ch. 14, 17