Differences

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

--- public:wan_optimization [2020/05/04 11:44] – created lstolp
+++ public:wan_optimization [2024/01/25 03:31] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-RFC 1323 Window Scaling & Timestamps
+{{public:rfc1323.pdf |RFC 1323 Window Scaling & Timestamps}}
-RFC 2018 Selective ACK
+   This memo presents a set of TCP extensions to improve performance
-RFC 2001/2851 TCP Reno (Slow Start, Cong. Avoidance, Fast Retransmit & Recovery)
+   over large bandwidth*delay product paths and to provide reliable
-RFC 2414/3390 Increase initial window size
+   operation over very high-speed paths.  It defines new TCP options for
-RFC 2873 Accept TOS/Precedence changes
+   scaled windows and timestamps, which are designed to provide
-RFC 2988 RTO calculation
+   compatible interworking with TCP’s that do not implement the
-RFC 3042 Limited transmit
+   extensions.  The timestamps are used for two distinct mechanisms:
-RFC 3465 ABC
+   RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
-RFC 3517 SACK sender behavior
+   Sequences).  Selective acknowledgments are not included in this memo.
-RFC 3649 High Speed TCP
+{{public:rfc2018.pdf | RFC 2018 Selective ACK}}
+   TCP may experience poor performance when multiple packets are lost
+   from one window of data.   With the limited information available
+   from cumulative acknowledgments, a TCP sender can only learn about a
+   single lost packet per round trip time.  An aggressive sender could
+   choose to retransmit packets early, but such retransmitted segments
+   may have already been successfully received.
+   A Selective Acknowledgment (SACK) mechanism, combined with a
+   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 4.2.2.15
+   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 4.2.3.1 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.