TCP Variants

TCP Algorithms: Four intertwined algorithms used commonly in TCP implementations Slow Start - Every ack increases the sender’s window (cwnd) size by 1 Congestion Avoidance - Reducing sender’s window size by half at experience of loss, and increase the sender’s window at the rate of about one packet per RTT (NOTE: not per ack) Fast Retransmit - Don’t wait for retransmit timer to go off, retransmit packet if 3 duplicate acks received Fast Recovery - Since duplicate ack came through, one packet has left the wire. Perform congestion avoidance, don’t jump down to slow start

TCP Variants : TCP-Tahoe: implements the slow start, congestion avoidance, and fast retransmit algorithms TCP-Reno: implements the slow start, congestion avoidance, fast retransmit, and fast recovery algorithms

TCP Tahoe’s Fast Retransmit Sender receives 3 dupACKS. Sender infers that the segment is lost. Sender re-sends the segment immediately! Sender returns to slow-start. segment 1 cwnd = 1 ACK 1 cwnd = 2 segment 2 segment 3 ACK 2 ACK 3 cwnd = 4 segment 4 segment 5 segment 6 ACK 3 segment 7 3 duplicate ACKs ACK 3 ACK 3 Recall: a duplicate ACK means that an out-of sequence segment was received Notes: duplicate ACKs due packet reordering! if window is small don’t get duplicate ACKs! segment 4 fast-retransmit of segment 4

Fast Recovery Concept: After fast retransmit, reduce cwnd by half, and continue sending segments at this reduced level. Problems: Sender has too many outstanding segments. How does sender transmit packets on a dupACK? Inflate cwnd. cwnd (initial) ssthresh fast-retransmit fast-retransmit timeout new ACK new ACK Time Slow Start Congestion Avoidance “inflating” cwnd with dupACKs “deflating” cwnd with a new ACK

Fast Retransmit & Fast Recovery (TCP Reno) After receiving 3 dupACKS: Retransmit the lost segment. Set ssthresh = flight size/2. Set cwnd = ssthresh, and ndupacks = 3. N.B. In Reno: send_win = min ( rwnd, cwnd + ndupacks ). If dupACK arrives: ++ ndupacks Transmit new segment, if allowed. If new ACK arrives: ndupacks = 0 Exit fast recovery. If RTO expires: Perform slow-start - ( ssthresh = flight size/2, cwnd = 1 )

TCP Vegas Developed by Brakmo, O'Malley & Peterson [SIGCOMM,1994] Sender-side protocol Inter-operates with other TCP variants Relies on accurate timing to estimate congestion In contrast to Reno – use only packet losses

Vegas Congestion Avoidance Adjust window size even before packet loss Use fine-grained timers for accurate RTTs Use timing information to compute Expected throughput (best case throughput with minimum RTT, or baseRTT) Actual throughput (using current RTT) Adjust window based on difference between actual and expected throughput

TCP Vegas Summary Anywhere between 40%-70% better throughput than Reno Only if router buffers are not heavily utilized Under heavy congestion, Vegas behaves like Reno Vegas is less aggressive than Reno in using up router buffers Vegas throughput suffers when competing with other Reno- based data flows Path rerouting changes the baseRTT, which can result in throughput loss Fairness issues of Vegas still unresolved

TCP SACK Basic problem in TCP is that cumulative ACKS provide little information Selective acknowledgement (SACK) essentially adds a bitmask of packets received Implemented as a TCP option Use is negotiated during handshake Encoded as a set of received byte ranges in TCP header (max of 4 ranges/often max of 3) Note that ACK sequence numbers are still cumulative! 10

Selective ACKnowledgements (SACK) TCP SACK options specify the blocks of data received in terms of blocks Block = contiguous range of data received Left edge specified first sequence number Right edge specifies last sequence number + 1 Header has 40 bytes for TCP option 2 bytes for TCP options Kind and Length 38 bytes remaining – specify 4 block ranges at most 11

TCP Westwood (TCPW) Sender side only modification to TCP Reno End to end bandwidth estimation to set congestion windows (cwnd) and slow start threshold (ssthresh) Additive Increase Adaptive Decrease paradigm Instead of blindly halving the congestion window after 3 DUP ACKs, adaptively set a slow start threshold and congestion window Takes into account that duplicate ACKs arriving means a packet passed through network successfully Increase throughput significantly for wireless networks and fairness for both wired and wireless networks. Source and further readings 1) http://www-ictserv.poliba.it/mascolo/tcp%20westwood/homeW.htm 2) http://www.cs.ucla.edu/NRL/hpi/tcpw/ 3) http://c3lab.poliba.it/index.php/Westwood

TCP Reno vs. TCP Westwood

TCP Reno vs. TCP Westwood

TCP Cubic cwnd growth function : cubic function in terms of the elapsed time since the last loss event Window growth rate independent of RTT: keeps the protocol TCP friendly guarantees RTT fairness Behaves like TCP under high loss rate regions Tackles the under utililization problem in low loss rate region Ideal for high bandwidth-delay product networks

Cwnd growth pattern Steady state: Probing state: window grows very fast upon a window reduction As it gets closer to Wmax, it slows down its growth Wmax is the window size just before the last window reduction Probing state: slow growth around Wmax enhances the stability fast growth away from Wmax ensures the scalability

CUBIC cwnd curves comparison with TCP

Questions?