{{public:rfc1323.pdf |RFC 1323 Window Scaling & Timestamps}}
   This memo presents a set of TCP extensions to improve performance
   over large bandwidth*delay product paths and to provide reliable
   operation over very high-speed paths.  It defines new TCP options for
   scaled windows and timestamps, which are designed to provide
   compatible interworking with TCP’s that do not implement the
   extensions.  The timestamps are used for two distinct mechanisms:
   RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
   Sequences).  Selective acknowledgments are not included in this memo.

{{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.