RFC 3708:Using TCP Duplicate Selective Acknowledge...
RFC-Ref

TCP


Click on the red underlined text to get to the source

... TCP [RFC793] and SCTP [RFC2960 ...
... TSN notifications, respectively. Using this information, a TCP or SCTP sender can generally determine when a retransmission ...
... alternate algorithms. Additionally, this document does not outline what a TCP or SCTP sender may do after a spurious retransmission is ...
... Finally, we note that to simplify the text much of the following discussion is in terms of TCP DSACKs, while applying to both TCP and SCTP ...
... discussion is in terms of TCP DSACKs, while applying to both TCP and SCTP. ...


... More speculatively, duplicate notification has been proposed as an integral part of estimating TCP's total loss rate [AEO03] for the purposes of mitigating the impact of corruption-based losses on ...


... protection against both of these cases. We assume the TCP sender has a data structure to hold selective acknowledgment ...
... (A.1) If the SACK scoreboard is empty (i.e., the TCP sender has received no SACK ...
... network. In such a case, the reverse path seems to be in a congested state and so reducing TCP's sending rate is the conservative approach. ...
... network duplication from unnecessary retransmission (e.g., the TCP timestamp option [RFC1323 ...
... In addition to keeping the state mentioned in [RFC3517] (for TCP) and [RFC2960] (for SCTP ...


... algorithm outlined in this document as the basis for investigating several methods to make TCP more robust to reordered packets. ...
... Eifel detection algorithm [RFC3522] uses the TCP timestamp option [RFC1323 ...
... The F-RTO scheme [SK03] slightly alters TCP's sending pattern immediately following a retransmission timeout and then observes the ...
... algorithm only needs to be implemented on the sender side of the TCP connection and that nothing extra needs to cross the network (e.g., DSACKs, timestamps ...


... receiver to falsely indicate spurious retransmissions in the case of actual loss, potentially causing a TCP or SCTP sender to inaccurately conclude that no loss took place (and ...


... Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883prop, July 2000. ...
... Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton, "Early Retransmit for TCP", Work in Progress, June 2003. ...
... Allman, M., Eddy, E. and S. Ostermann, "Estimating Loss Rates With TCP", Work in Progress, August 2003. ...
... Blanton, E. and M. Allman. On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002. ...
... Blanton, E., Dimond, R. and M. Allman, "Practices for TCP Senders in the Face of Segment Reordering", Work in Progress ...
... R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. ACM Computer Communication Review, 30(1), January 2000. ...
... Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323prop, May 1992. ...
... SACK)-based Loss Recovery Algorithm for TCP", RFC 3517prop, April 2003. ...
... Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP," RFC 3522exp, April 2003. ...
... RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP", Work in Progress, June 2003. ...



Google
Web
RFC-Ref