1. 1 Internet Networking Spring 2006 Tutorial 10 The Eifel Detection Algorithm for TCP RFC 3522

2. 2 Motivation Allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. Detects whether a fast retransmit or a timeout was spurious upon the first acceptable ACK that arrives during loss recovery. Robust against the loss of ACKs. Requires that the TCP Timestamps option be enabled for a connection (RFC 1323). Eliminates the retransmission ambiguity in TCP Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. May be used to perform a response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. Restoring the TCP sender's congestion control state. Avoiding unnecessary go-back-N retransmits.

3. 3 Retransmission Ambiguity A TCP sender unable to distinguish whether the first acceptable ACK that arrives after a retransmit was sent in response to the original transmit or the retransmit. This problem occurs after a timeout-based retransmit and after a fast retransmit. The Eifel detection algorithm uses the TCP Timestamps option to eliminate the retransmission ambiguity. Useful in environments where TCP's loss recovery and congestion control algorithms may often get falsely triggered. This can be caused by packet reordering, packet duplication, or a sudden delay increase in the data or the ACK path that results in a spurious timeout.

4. 4 Falsely Trigger TCP Loss Recovery Spurious timeout A timeout that would not have occurred had the sender "waited longer". This may be caused by increased delay that suddenly occurs in the data and/or the ACK path. May cause an acceptable ACK to arrive too late, i.e., only after a TCP sender's retransmission timer has expired. Unnecessarily forces a TCP sender into slow start and causes a go-back-N retransmissions. 1 2 Ack(2) Ack(3) 2 Time out

5. 5 Falsely Trigger TCP Loss Recovery (cont.) Packet reordering IP does not guarantee in-order delivery of packets. May cause a single spurious retransmit (the fast retransmit), and the unnecessary halving of a TCP sender's congestion window as a result of the subsequent fast recovery phase. 1 2 Ack(1) 3 Ack(4)

6. 6 Falsely Trigger TCP Loss Recovery (cont.) Packet duplication May cause a single spurious retransmit (the fast retransmit), and the unnecessary halving of a TCP sender's congestion window as a result of the subsequent fast recovery phase.

7. 7 The Idea Allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. TCP sender should be able to make this decision upon the first acceptable ACK that arrives after the timeout-based retransmit or the fast retransmit has been sent. Requires extra information in ACKs by which the TCP sender can unambiguously distinguish whether that first acceptable ACK was sent in response to the original transmit or the retransmit. Such extra information is provided by the TCP Timestamps option.

8. 8 TCP Timestamps Option The sender places a timestamp in each data segment. The receiver reflects these timestamps back in ACK segments. Can be used to measure the RTT. Can be used to correlate between data segments and their ACK’s.

9. 9 The Detection Algorithm A TCP sender always stores the timestamp of the retransmit sent in the beginning of loss recovery. The timestamp of the timeout-based retransmit The fast retransmit. If the echo timestamp of the first acceptable ACK, that arrives after the retransmit was sent, is smaller then the stored timestamp of that retransmit, then that ACK must have been sent in response to an original transmit. The term ‘acceptable ACK’ refer to an ACK that acknowledges previously unacknowledged data. Hence, the TCP sender must have entered loss recovery unnecessarily.

10. 10 The Detection Algorithm Example 1 2 Ack(2) Ack(4) 2 Time out event 3 Ack(3) 3 Without Eifel DetectionWith Eifel Detection 4 1 2 Ack(2) Ack(4) 2 3 Ack(3) 5 6 Time out event Detect a spurious timeout 44

11. 11 Conclusions The Eifel algorithm eliminates the retransmission ambiguity. Allows to recognize whether a retransmit was triggered by congestion in the network. Detects unnecessary congestion control algorithm activation caused by: packet reordering, packet duplication, spurious timeout. Alleviates the consequences of a falsely triggered loss recovery.