1. TCP Variants

2. 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

3. 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

4. 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

5. 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

6. Fast Retransmit & Fast Recovery (TCP Reno)
After receiving 3 dupACKS:
Retransmit the lost segment.
Set ssthresh = flight size/2.
Set cwnd = ssthresh, and ndupacks = 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 )

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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) 2) 3)

13. TCP Reno vs. TCP Westwood

14. TCP Reno vs. TCP Westwood

15. 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

16. 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

17. CUBIC cwnd curves comparison with TCP

18. Questions?