User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
public:wan_optimization [2020/05/04 12:00]
public:wan_optimization [2020/05/04 12:36] (current)
Line 9: Line 9:
    Sequences).  Selective acknowledgments are not included in this memo.    Sequences).  Selective acknowledgments are not included in this memo.
-RFC 2018 Selective ACK +{{public:rfc2018.pdf | RFC 2018 Selective ACK}} 
-RFC 2001/2851 TCP Reno (Slow Start, Cong. Avoidance, Fast Retransmit & Recovery) +   TCP may experience poor performance when multiple packets are lost 
-RFC 2414/3390 Increase initial window size +   from one window of data.   With the limited information available 
-RFC 2873 Accept TOS/Precedence changes +   from cumulative acknowledgments, a TCP sender can only learn about a 
-RFC 2988 RTO calculation +   single lost packet per round trip time.  An aggressive sender could 
-RFC 3042 Limited transmit +   choose to retransmit packets early, but such retransmitted segments 
-RFC 3465 ABC +   may have already been successfully received. 
-RFC 3517 SACK sender behavior +   A Selective Acknowledgment (SACK) mechanism, combined with a 
-RFC 3649 High Speed TCP+   selective repeat retransmission policy, can help to overcome these 
 +   limitations.  The receiving TCP sends back SACK packets to the sender 
 +   informing the sender of data that has been received. The sender can 
 +   then retransmit only the missing data segments. 
 +{{public:rfc2001.pdf| RFC 2001/2851 TCP Reno (Slow Start, Cong. Avoidance, Fast Retransmit & Recovery)}} 
 +   Modern implementations of TCP contain four intertwined algorithms 
 +   that have never been fully documented as Internet standards:  slow 
 +   start, congestion avoidance, fast retransmit, and fast recovery.  [2] 
 +   and [3] provide some details on these algorithms, [4] provides 
 +   examples of the algorithms in action, and [5] provides the source 
 +   code for the 4.4BSD implementation.  RFC 1122 requires that a TCP 
 +   must implement slow start and congestion avoidance (Section 
 +   of [1]), citing [2] as the reference, but fast retransmit and fast 
 +   recovery were implemented after RFC 1122.  The purpose of this 
 +   document is to document these four algorithms for the Internet. 
 +{{public:rfc3390.pdf | RFC 2414/3390 Increase initial window size}} 
 +   This document specifies an optional standard for TCP to increase the 
 +   permitted initial window from one or two segment(s) to roughly 4K 
 +   bytes, replacing RFC 2414.  It discusses the advantages and 
 +   disadvantages of the higher initial window, and includes discussion 
 +   of experiments and simulations showing that the higher initial window 
 +   does not lead to congestion collapse.  Finally, this document 
 +   provides guidance on implementation issues. 
 +{{public:rfc2873.pdf | RFC 2873 Accept TOS/Precedence changes}} 
 +   This memo describes a conflict between TCP [RFC793] and DiffServ 
 +   [RFC2475] on the use of the three leftmost bits in the TOS octet of 
 +   an IPv4 header [RFC791]. In a network that contains DiffServ-capable 
 +   nodes, such a conflict can cause failures in establishing TCP 
 +   connections or can cause some established TCP connections to be reset 
 +   undesirably. This memo proposes a modification to TCP for resolving 
 +   the conflict.  
 +   Because the IPv6 [RFC2460] traffic class octet does not have any 
 +   defined meaning except what is defined in RFC 2474, and in particular 
 +   does not define precedence or security parameter bits, there is no 
 +   conflict between TCP and DiffServ on the use of any bits in the IPv6 
 +   traffic class octet. 
 +{{public:rfc2988.pdf | RFC 2988 RTO calculation}} 
 +   This document defines the standard algorithm that Transmission 
 +   Control Protocol (TCP) senders are required to use to compute and 
 +   manage their retransmission timer.  It expands on the discussion in 
 +   section of RFC 1122 and upgrades the requirement of 
 +   supporting the algorithm from a SHOULD to a MUST. 
 +{{public:rfc3042.pdf | RFC 3042 Limited transmit}} 
 +   This document proposes a new Transmission Control Protocol (TCP) 
 +   mechanism that can be used to more effectively recover lost segments 
 +   when a connection’s congestion window is small, or when a large 
 +   number of segments are lost in a single transmission window.  The 
 +   "Limited Transmit" algorithm calls for sending a new data segment in 
 +   response to each of the first two duplicate acknowledgments that 
 +   arrive at the sender.  Transmitting these segments increases the 
 +   probability that TCP can recover from a single lost segment using the 
 +   fast retransmit algorithm, rather than using a costly retransmission 
 +   timeout.  Limited Transmit can be used both in conjunction with, and 
 +   in the absence of, the TCP selective acknowledgment (SACK) mechanism. 
 +{{public:rfc3465.pdf | RFC 3465 ABC}} 
 +   This document proposes a small modification to the way TCP increases 
 +   its congestion window.  Rather than the traditional method of 
 +   increasing the congestion window by a constant amount for each 
 +   arriving acknowledgment, the document suggests basing the increase on 
 +   the number of previously unacknowledged bytes each ACK covers.  This 
 +   change improves the performance of TCP, as well as closes a security 
 +   hole TCP receivers can use to induce the sender into increasing the 
 +   sending rate too rapidly. 
 +{{public:rfc3517.pdf | RFC 3517 SACK sender behavior}} 
 +   This document presents a conservative loss recovery algorithm for TCP 
 +   that is based on the use of the selective acknowledgment (SACK) TCP 
 +   option.  The algorithm presented in this document conforms to the 
 +   spirit of the current congestion control specification (RFC 2581), 
 +   but allows TCP senders to recover more effectively when multiple 
 +   segments are lost from a single flight of data. 
 +{{public:rfc3649.pdf | RFC 3649 High Speed TCP}} 
 +   The proposals in this document are experimental.  While they may be 
 +   deployed in the current Internet, they do not represent a consensus 
 +   that this is the best method for high-speed congestion control.  In 
 +   particular, we note that alternative experimental proposals are 
 +   likely to be forthcoming, and it is not well understood how the 
 +   proposals in this document will interact with such alternative 
 +   proposals. 
 +   This document proposes HighSpeed TCP, a modification to TCP’s 
 +   congestion control mechanism for use with TCP connections with large 
 +   congestion windows.  The congestion control mechanisms of the current 
 +   Standard TCP constrains the congestion windows that can be achieved 
 +   by TCP in realistic environments.  For example, for a Standard TCP 
 +   connection with 1500-byte packets and a 100 ms round-trip time, 
 +   achieving a steady-state throughput of 10 Gbps would require an 
 +   average congestion window of 83,333 segments, and a packet drop rate 
 +   of at most one congestion event every 5,000,000,000 packets (or 
 +   equivalently, at most one congestion event every 1 2/3 hours).  This 
 +   is widely acknowledged as an unrealistic constraint.  To address this 
 +   limitation of TCP, this document proposes HighSpeed TCP, and solicits 
 +   experimentation and feedback from the wider community.
public/wan_optimization.txt · Last modified: 2020/05/04 12:36 by lstolp