1 / 12

Internet Networking recitation #11

Internet Networking recitation #11. TCP Eiffel (RFC 3522). Motivation. Allows a TCP sender to detect if it had entered loss recovery unnecessarily. Detects whether a fast retransmit or a timeout was spurious upon the first acceptable ACK that arrives during loss recovery.

lcassidy
Télécharger la présentation

Internet Networking recitation #11

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet Networkingrecitation #11 TCP Eiffel (RFC 3522) Spring Semester 2007, Dept. of Computer Science, Technion

  2. Motivation • Allows a TCP sender to detect if it had 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 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 • Decides whether loss recovery was entered unnecessarily. • Performs 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. Internet Networking

  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 Eiffel 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. Internet Networking

  4. Falsely Trigger TCP Loss Recovery • Spurious timeout • May be caused by increased delay that suddenly occurs in the data and/or the ACK path. • Then 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 Ack(2) 2 Ack(3) 2 Time out Internet Networking

  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. Ack(1) 1 2 Ack(1) 3 Ack(1) 4 Ack(1) Ack(4) Internet Networking

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

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

  8. TCP Timestamps Option (RFC 1323) • 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. Internet Networking

  9. The Detection Algorithm • A TCP sender always stores the timestamp of the retransmit sent in the beginning of loss recovery. • Retransmit as a result of timeout or dup acks. Ack(1) 1 2 Ack(1) 3 Ack(1) 4 Ack(1) Ack(4) Resend packet 1, record time stamp Internet Networking

  10. The Detection Algorithm (Cont.) • 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 • that ACK must have been sent in response to an original transmit. • ‘Acceptable ACK’ - an ACK that acknowledges previously unacknowledged data. • Hence, the TCP sender must have entered loss recovery unnecessarily. Ack(1) 1 2 Ack(1) 3 Ack(1) 4 Ack(1) Ack(4) Resend packet 1, record time stamp Smaller time-stamp here Internet Networking

  11. The Detection Algorithm Example Without Eiffel Detection With Eiffel Detection Detect a spurious timeout 1 1 Ack(2) Ack(2) 2 2 Ack(3) Ack(3) 3 3 Ack(4) Ack(4) 4 4 Time out event Time out event 2 2 3 5 4 6 Internet Networking

  12. Conclusions • The Eiffel 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. Internet Networking

More Related