CSCE 515 : Computer Network Programming

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

TCP Variants • TCP Tahoe: Fast Retransmit and slow start • TCP Reno: adding Fast Recover • Suffer from multiple packet losses in a window

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

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

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

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

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

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

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

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*214 bytes kind=3 len=3 shift count 1 1 1

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=8 len=10 timestamp value timestamp echo reply 4 4 1 1

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

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

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

Next Class • HyperText Transfer Protocol (HTTP) • Read JNP Ch. 14, 17

CSCE 515 : Computer Network Programming