doc: Add RFC documents

1 files changed, 672 insertions, 0 deletions

diff --git a/doc/rfc/rfc8961.txt b/doc/rfc/rfc8961.txt
new file mode 100644
index 0000000..85471c7
--- /dev/null
+++ b/doc/rfc/rfc8961.txt
@@ -0,0 +1,672 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         M. Allman
+Request for Comments: 8961                                          ICSI
+BCP: 233                                                   November 2020
+Category: Best Current Practice                                         
+ISSN: 2070-1721
+
+
+               Requirements for Time-Based Loss Detection
+
+Abstract
+
+   Many protocols must detect packet loss for various reasons (e.g., to
+   ensure reliability using retransmissions or to understand the level
+   of congestion along a network path).  While many mechanisms have been
+   designed to detect loss, ultimately, protocols can only count on the
+   passage of time without delivery confirmation to declare a packet
+   "lost".  Each implementation of a time-based loss detection mechanism
+   represents a balance between correctness and timeliness; therefore,
+   no implementation suits all situations.  This document provides high-
+   level requirements for time-based loss detectors appropriate for
+   general use in unicast communication across the Internet.  Within the
+   requirements, implementations have latitude to define particulars
+   that best address each situation.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8961.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Terminology
+   2.  Context
+   3.  Scope
+   4.  Requirements
+   5.  Discussion
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgments
+   Author's Address
+
+1.  Introduction
+
+   As a network of networks, the Internet consists of a large variety of
+   links and systems that support a wide variety of tasks and workloads.
+   The service provided by the network varies from best-effort delivery
+   among loosely connected components to highly predictable delivery
+   within controlled environments (e.g., between physically connected
+   nodes, within a tightly controlled data center).  Each path through
+   the network has a set of path properties, e.g., available capacity,
+   delay, and packet loss.  Given the range of networks that make up the
+   Internet, these properties range from largely static to highly
+   dynamic.
+
+   This document provides guidelines for developing an understanding of
+   one path property: packet loss.  In particular, we offer guidelines
+   for developing and implementing time-based loss detectors that have
+   been gradually learned over the last several decades.  We focus on
+   the general case where the loss properties of a path are (a) unknown
+   a priori and (b) dynamically varying over time.  Further, while there
+   are numerous root causes of packet loss, we leverage the conservative
+   notion that loss is an implicit indication of congestion [RFC5681].
+   While this stance is not always correct, as a general assumption it
+   has historically served us well [Jac88].  As we discuss further in
+   Section 2, the guidelines in this document should be viewed as a
+   general default for unicast communication across best-effort networks
+   and not as optimal -- or even applicable -- for all situations.
+
+   Given that packet loss is routine in best-effort networks, loss
+   detection is a crucial activity for many protocols and applications
+   and is generally undertaken for two major reasons:
+
+   (1)  Ensuring reliable data delivery
+
+        This requires a data sender to develop an understanding of which
+        transmitted packets have not arrived at the receiver.  This
+        knowledge allows the sender to retransmit missing data.
+
+   (2)  Congestion control
+
+        As we mention above, packet loss is often taken as an implicit
+        indication that the sender is transmitting too fast and is
+        overwhelming some portion of the network path.  Data senders can
+        therefore use loss to trigger transmission rate reductions.
+
+   Various mechanisms are used to detect losses in a packet stream.
+   Often, we use continuous or periodic acknowledgments from the
+   recipient to inform the sender's notion of which pieces of data are
+   missing.  However, despite our best intentions and most robust
+   mechanisms, we cannot place ultimate faith in receiving such
+   acknowledgments but can only truly depend on the passage of time.
+   Therefore, our ultimate backstop to ensuring that we detect all loss
+   is a timeout.  That is, the sender sets some expectation for how long
+   to wait for confirmation of delivery for a given piece of data.  When
+   this time period passes without delivery confirmation, the sender
+   concludes the data was lost in transit.
+
+   The specifics of time-based loss detection schemes represent a
+   tradeoff between correctness and responsiveness.  In other words, we
+   wish to simultaneously:
+
+   *  wait long enough to ensure the detection of loss is correct, and
+
+   *  minimize the amount of delay we impose on applications (before
+      repairing loss) and the network (before we reduce the congestion).
+
+   Serving both of these goals is difficult, as they pull in opposite
+   directions [AP99].  By not waiting long enough to accurately
+   determine a packet has been lost, we may provide a needed
+   retransmission in a timely manner but risk both sending unnecessary
+   ("spurious") retransmissions and needlessly lowering the transmission
+   rate.  By waiting long enough that we are unambiguously certain a
+   packet has been lost, we cannot repair losses in a timely manner and
+   we risk prolonging network congestion.
+
+   Many protocols and applications -- such as TCP [RFC6298], SCTP
+   [RFC4960], and SIP [RFC3261] -- use their own time-based loss
+   detection mechanisms.  At this point, our experience leads to a
+   recognition that often specific tweaks that deviate from standardized
+   time-based loss detectors do not materially impact network safety
+   with respect to congestion control [AP99].  Therefore, in this
+   document we outline a set of high-level, protocol-agnostic
+   requirements for time-based loss detection.  The intent is to provide
+   a safe foundation on which implementations have the flexibility to
+   instantiate mechanisms that best realize their specific goals.
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Context
+
+   This document is different from the way we ideally like to engineer
+   systems.  Usually, we strive to understand high-level requirements as
+   a starting point.  We then methodically engineer specific protocols,
+   algorithms, and systems that meet these requirements.  Within the
+   IETF standards process, we have derived many time-based loss
+   detection schemes without the benefit of some over-arching
+   requirements document -- because we had no idea how to write such a
+   document!  Therefore, we made the best specific decisions we could in
+   response to specific needs.
+
+   At this point, however, the community's experience has matured to the
+   point where we can define a set of general, high-level requirements
+   for time-based loss detection schemes.  We now understand how to
+   separate the strategies these mechanisms use that are crucial for
+   network safety from those small details that do not materially impact
+   network safety.  The requirements in this document may not be
+   appropriate in all cases.  In particular, the guidelines in Section 4
+   are concerned with the general case, but specific situations may
+   allow for more flexibility in terms of loss detection because
+   specific facets of the environment are known (e.g., when operating
+   over a single physical link or within a tightly controlled data
+   center).  Therefore, variants, deviations, or wholly different time-
+   based loss detectors may be necessary or useful in some cases.  The
+   correct way to view this document is as the default case and not as
+   one-size-fits-all guidance that is optimal in all cases.
+
+   Adding a requirements umbrella to a body of existing specifications
+   is inherently messy and we run the risk of creating inconsistencies
+   with both past and future mechanisms.  Therefore, we make the
+   following statements about the relationship of this document to past
+   and future specifications:
+
+   *  This document does not update or obsolete any existing RFC.  These
+      previous specifications -- while generally consistent with the
+      requirements in this document -- reflect community consensus, and
+      this document does not change that consensus.
+
+   *  The requirements in this document are meant to provide for network
+      safety and, as such, SHOULD be used by all future time-based loss
+      detection mechanisms.
+
+   *  The requirements in this document may not be appropriate in all
+      cases; therefore, deviations and variants may be necessary in the
+      future (hence the "SHOULD" in the last bullet).  However,
+      inconsistencies MUST be (a) explained and (b) gather consensus.
+
+3.  Scope
+
+   The principles we outline in this document are protocol-agnostic and
+   widely applicable.  We make the following scope statements about the
+   application of the requirements discussed in Section 4:
+
+   (S.1) While there are a bevy of uses for timers in protocols -- from
+         rate-based pacing to connection failure detection and beyond --
+         this document is focused only on loss detection.
+
+   (S.2) The requirements for time-based loss detection mechanisms in
+         this document are for the primary or "last resort" loss
+         detection mechanism, whether the mechanism is the sole loss
+         repair strategy or works in concert with other mechanisms.
+
+         While a straightforward time-based loss detector is sufficient
+         for simple protocols like DNS [RFC1034] [RFC1035], more complex
+         protocols often use more advanced loss detectors to aid
+         performance.  For instance, TCP and SCTP have methods to detect
+         (and repair) loss based on explicit endpoint state sharing
+         [RFC2018] [RFC4960] [RFC6675].  Such mechanisms often provide
+         more timely and precise loss detection than time-based loss
+         detectors.  However, these mechanisms do not obviate the need
+         for a "retransmission timeout" or "RTO" because, as we discuss
+         in Section 1, only the passage of time can ultimately be relied
+         upon to detect loss.  In other words, we ultimately cannot
+         count on acknowledgments to arrive at the data sender to
+         indicate which packets never arrived at the receiver.  In cases
+         such as these, we need a time-based loss detector to function
+         as a "last resort".
+
+         Also, note that some recent proposals have incorporated time as
+         a component of advanced loss detection methods either as an
+         aggressive first loss detector in certain situations or in
+         conjunction with endpoint state sharing [DCCM13] [CCDJ20]
+         [IS20].  While these mechanisms can aid timely loss recovery,
+         the protocol ultimately leans on another more conservative
+         timer to ensure reliability when these mechanisms break down.
+         The requirements in this document are only directly applicable
+         to last-resort loss detection.  However, we expect that many of
+         the requirements can serve as useful guidelines for more
+         aggressive non-last-resort timers as well.
+
+   (S.3) The requirements in this document apply only to endpoint-to-
+         endpoint unicast communication.  Reliable multicast (e.g.,
+         [RFC5740]) protocols are explicitly outside the scope of this
+         document.
+
+         Protocols such as SCTP [RFC4960] and Multipath TCP (MP-TCP)
+         [RFC6182] that communicate in a unicast fashion with multiple
+         specific endpoints can leverage the requirements in this
+         document provided they track state and follow the requirements
+         for each endpoint independently.  That is, if host A
+         communicates with addresses B and C, A needs to use independent
+         time-based loss detector instances for traffic sent to B and C.
+
+   (S.4) There are cases where state is shared across connections or
+         flows (e.g., [RFC2140] and [RFC3124]).  State pertaining to
+         time-based loss detection is often discussed as sharable.
+         These situations raise issues that the simple flow-oriented
+         time-based loss detection mechanism discussed in this document
+         does not consider (e.g., how long to preserve state between
+         connections).  Therefore, while the general principles given in
+         Section 4 are likely applicable, sharing time-based loss
+         detection information across flows is outside the scope of this
+         document.
+
+4.  Requirements
+
+   We now list the requirements that apply when designing primary or
+   last-resort time-based loss detection mechanisms.  For historical
+   reasons and ease of exposition, we refer to the time between sending
+   a packet and determining the packet has been lost due to lack of
+   delivery confirmation as the "retransmission timeout" or "RTO".
+   After the RTO passes without delivery confirmation, the sender may
+   safely assume the packet is lost.  However, as discussed above, the
+   detected loss need not be repaired (i.e., the loss could be detected
+   only for congestion control and not reliability purposes).
+
+   (1)  As we note above, loss detection happens when a sender does not
+        receive delivery confirmation within some expected period of
+        time.  In the absence of any knowledge about the latency of a
+        path, the initial RTO MUST be conservatively set to no less than
+        1 second.
+
+        Correctness is of the utmost importance when transmitting into a
+        network with unknown properties because:
+
+        *  Premature loss detection can trigger spurious retransmits
+           that could cause issues when a network is already congested.
+
+        *  Premature loss detection can needlessly cause congestion
+           control to dramatically lower the sender's allowed
+           transmission rate, especially since the rate is already
+           likely low at this stage of the communication.  Recovering
+           from such a rate change can take a relatively long time.
+
+        *  Finally, as discussed below, sometimes using time-based loss
+           detection and retransmissions can cause ambiguities in
+           assessing the latency of a network path.  Therefore, it is
+           especially important for the first latency sample to be free
+           of ambiguities such that there is a baseline for the
+           remainder of the communication.
+
+        The specific constant (1 second) comes from the analysis of
+        Internet round-trip times (RTTs) found in Appendix A of
+        [RFC6298].
+
+   (2)  We now specify four requirements that pertain to setting an
+        expected time interval for delivery confirmation.
+
+        Often, measuring the time required for delivery confirmation is
+        framed as assessing the RTT of the network path.  The RTT is the
+        minimum amount of time required to receive delivery confirmation
+        and also often follows protocol behavior whereby acknowledgments
+        are generated quickly after data arrives.  For instance, this is
+        the case for the RTO used by TCP [RFC6298] and SCTP [RFC4960].
+        However, this is somewhat misleading, and the expected latency
+        is better framed as the "feedback time" (FT).  In other words,
+        the expectation is not always simply a network property; it can
+        include additional time before a sender should reasonably expect
+        a response.
+
+        For instance, consider a UDP-based DNS request from a client to
+        a recursive resolver [RFC1035].  When the request can be served
+        from the resolver's cache, the feedback time (FT) likely well
+        approximates the network RTT between the client and resolver.
+        However, on a cache miss, the resolver will request the needed
+        information from one or more authoritative DNS servers, which
+        will non-trivially increase the FT compared to the network RTT
+        between the client and resolver.
+
+        Therefore, we express the requirements in terms of FT.  Again,
+        for ease of exposition, we use "RTO" to indicate the interval
+        between a packet transmission and the decision that the packet
+        has been lost, regardless of whether the packet will be
+        retransmitted.
+
+        (a)  The RTO SHOULD be set based on multiple observations of the
+             FT when available.
+
+             In other words, the RTO should represent an empirically
+             derived reasonable amount of time that the sender should
+             wait for delivery confirmation before deciding the given
+             data is lost.  Network paths are inherently dynamic;
+             therefore, it is crucial to incorporate multiple recent FT
+             samples in the RTO to take into account the delay variation
+             across time.
+
+             For example, TCP's RTO [RFC6298] would satisfy this
+             requirement due to its use of an exponentially weighted
+             moving average (EWMA) to combine multiple FT samples into a
+             "smoothed RTT".  In the name of conservativeness, TCP goes
+             further to also include an explicit variance term when
+             computing the RTO.
+
+             While multiple FT samples are crucial for capturing the
+             delay dynamics of a path, we explicitly do not tightly
+             specify the process -- including the number of FT samples
+             to use and how/when to age samples out of the RTO
+             calculation -- as the particulars could depend on the
+             situation and/or goals of each specific loss detector.
+
+             Finally, FT samples come from packet exchanges between
+             peers.  We encourage protocol designers -- especially for
+             new protocols -- to strive to ensure the feedback is not
+             easily spoofable by on- or off-path attackers such that
+             they can perturb a host's notion of the FT.  Ideally, all
+             messages would be cryptographically secure, but given that
+             this is not always possible -- especially in legacy
+             protocols -- using a healthy amount of randomness in the
+             packets is encouraged.
+
+        (b)  FT observations SHOULD be taken and incorporated into the
+             RTO at least once per RTT or as frequently as data is
+             exchanged in cases where that happens less frequently than
+             once per RTT.
+
+             Internet measurements show that taking only a single FT
+             sample per TCP connection results in a relatively poorly
+             performing RTO mechanism [AP99], hence this requirement
+             that the FT be sampled continuously throughout the lifetime
+             of communication.
+
+             As an example, TCP takes an FT sample roughly once per RTT,
+             or, if using the timestamp option [RFC7323], on each
+             acknowledgment arrival.  [AP99] shows that both these
+             approaches result in roughly equivalent performance for the
+             RTO estimator.
+
+        (c)  FT observations MAY be taken from non-data exchanges.
+
+             Some protocols use non-data exchanges for various reasons,
+             e.g., keepalives, heartbeats, and control messages.  To the
+             extent that the latency of these exchanges mirrors data
+             exchange, they can be leveraged to take FT samples within
+             the RTO mechanism.  Such samples can help protocols keep
+             their RTO accurate during lulls in data transmission.
+             However, given that these messages may not be subject to
+             the same delays as data transmission, we do not take a
+             general view on whether this is useful or not.
+
+        (d)  An RTO mechanism MUST NOT use ambiguous FT samples.
+
+             Assume two copies of some packet X are transmitted at times
+             t0 and t1.  Then, at time t2, the sender receives
+             confirmation that X in fact arrived.  In some cases, it is
+             not clear which copy of X triggered the confirmation;
+             hence, the actual FT is either t2-t1 or t2-t0, but which is
+             a mystery.  Therefore, in this situation, an implementation
+             MUST NOT use either version of the FT sample and hence not
+             update the RTO (as discussed in [KP87] and [RFC6298]).
+
+             There are cases where two copies of some data are
+             transmitted in a way whereby the sender can tell which is
+             being acknowledged by an incoming ACK.  For example, TCP's
+             timestamp option [RFC7323] allows for packets to be
+             uniquely identified and hence avoid the ambiguity.  In such
+             cases, there is no ambiguity and the resulting samples can
+             update the RTO.
+
+   (3)  Loss detected by the RTO mechanism MUST be taken as an
+        indication of network congestion and the sending rate adapted
+        using a standard mechanism (e.g., TCP collapses the congestion
+        window to one packet [RFC5681]).
+
+        This ensures network safety.
+
+        An exception to this rule is if an IETF standardized mechanism
+        determines that a particular loss is due to a non-congestion
+        event (e.g., packet corruption).  In such a case, a congestion
+        control action is not required.  Additionally, congestion
+        control actions taken based on time-based loss detection could
+        be reversed when a standard mechanism post facto determines that
+        the cause of the loss was not congestion (e.g., [RFC5682]).
+
+   (4)  Each time the RTO is used to detect a loss, the value of the RTO
+        MUST be exponentially backed off such that the next firing
+        requires a longer interval.  The backoff SHOULD be removed after
+        either (a) the subsequent successful transmission of non-
+        retransmitted data, or (b) an RTO passes without detecting
+        additional losses.  The former will generally be quicker.  The
+        latter covers cases where loss is detected but not repaired.
+
+        A maximum value MAY be placed on the RTO.  The maximum RTO MUST
+        NOT be less than 60 seconds (as specified in [RFC6298]).
+
+        This ensures network safety.
+
+        As with guideline (3), an exception to this rule exists if an
+        IETF standardized mechanism determines that a particular loss is
+        not due to congestion.
+
+5.  Discussion
+
+   We note that research has shown the tension between the
+   responsiveness and correctness of time-based loss detection seems to
+   be a fundamental tradeoff in the context of TCP [AP99].  That is,
+   making the RTO more aggressive (e.g., via changing TCP's
+   exponentially weighted moving average (EWMA) gains, lowering the
+   minimum RTO, etc.) can reduce the time required to detect actual
+   loss.  However, at the same time, such aggressiveness leads to more
+   cases of mistakenly declaring packets lost that ultimately arrived at
+   the receiver.  Therefore, being as aggressive as the requirements
+   given in the previous section allow in any particular situation may
+   not be the best course of action because detecting loss, even if
+   falsely, carries a requirement to invoke a congestion response that
+   will ultimately reduce the transmission rate.
+
+   While the tradeoff between responsiveness and correctness seems
+   fundamental, the tradeoff can be made less relevant if the sender can
+   detect and recover from mistaken loss detection.  Several mechanisms
+   have been proposed for this purpose, such as Eifel [RFC3522], Forward
+   RTO-Recovery (F-RTO) [RFC5682], and Duplicate Selective
+   Acknowledgement (DSACK) [RFC2883] [RFC3708].  Using such mechanisms
+   may allow a data originator to tip towards being more responsive
+   without incurring (as much of) the attendant costs of mistakenly
+   declaring packets to be lost.
+
+   Also, note that, in addition to the experiments discussed in [AP99],
+   the Linux TCP implementation has been using various non-standard RTO
+   mechanisms for many years seemingly without large-scale problems
+   (e.g., using different EWMA gains than specified in [RFC6298]).
+   Further, a number of TCP implementations use a steady-state minimum
+   RTO that is less than the 1 second specified in [RFC6298].  While the
+   implication of these deviations from the standard may be more
+   spurious retransmits (per [AP99]), we are aware of no large-scale
+   network safety issues caused by this change to the minimum RTO.  This
+   informs the guidelines in the last section (e.g., there is no minimum
+   RTO specified).
+
+   Finally, we note that while allowing implementations to be more
+   aggressive could in fact increase the number of needless
+   retransmissions, the above requirements fail safely in that they
+   insist on exponential backoff and a transmission rate reduction.
+   Therefore, providing implementers more latitude than they have
+   traditionally been given in IETF specifications of RTO mechanisms
+   does not somehow open the flood gates to aggressive behavior.  Since
+   there is a downside to being aggressive, the incentives for proper
+   behavior are retained in the mechanism.
+
+6.  Security Considerations
+
+   This document does not alter the security properties of time-based
+   loss detection mechanisms.  See [RFC6298] for a discussion of these
+   within the context of TCP.
+
+7.  IANA Considerations
+
+   This document has no IANA actions.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2.  Informative References
+
+   [AP99]     Allman, M. and V. Paxson, "On Estimating End-to-End
+              Network Path Properties", Proceedings of the ACM SIGCOMM
+              Technical Symposium, September 1999.
+
+   [CCDJ20]   Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
+              RACK-TLP loss detection algorithm for TCP", Work in
+              Progress, Internet-Draft, draft-ietf-tcpm-rack-13, 2
+              November 2020,
+              <https://tools.ietf.org/html/draft-ietf-tcpm-rack-13>.
+
+   [DCCM13]   Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis,
+              "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of
+              Tail Losses", Work in Progress, Internet-Draft, draft-
+              dukkipati-tcpm-tcp-loss-probe-01, 25 February 2013,
+              <https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-
+              loss-probe-01>.
+
+   [IS20]     Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
+              and Congestion Control", Work in Progress, Internet-Draft,
+              draft-ietf-quic-recovery-32, 20 October 2020,
+              <https://tools.ietf.org/html/draft-ietf-quic-recovery-32>.
+
+   [Jac88]    Jacobson, V., "Congestion avoidance and control", ACM
+              SIGCOMM, DOI 10.1145/52325.52356, August 1988,
+              <https://doi.org/10.1145/52325.52356>.
+
+   [KP87]     Karn, P. and C. Partridge, "Improving Round-Trip Time
+              Estimates in Reliable Transport Protocols", SIGCOMM 87.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <https://www.rfc-editor.org/info/rfc1034>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
+              Selective Acknowledgment Options", RFC 2018,
+              DOI 10.17487/RFC2018, October 1996,
+              <https://www.rfc-editor.org/info/rfc2018>.
+
+   [RFC2140]  Touch, J., "TCP Control Block Interdependence", RFC 2140,
+              DOI 10.17487/RFC2140, April 1997,
+              <https://www.rfc-editor.org/info/rfc2140>.
+
+   [RFC2883]  Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
+              Extension to the Selective Acknowledgement (SACK) Option
+              for TCP", RFC 2883, DOI 10.17487/RFC2883, July 2000,
+              <https://www.rfc-editor.org/info/rfc2883>.
+
+   [RFC3124]  Balakrishnan, H. and S. Seshan, "The Congestion Manager",
+              RFC 3124, DOI 10.17487/RFC3124, June 2001,
+              <https://www.rfc-editor.org/info/rfc3124>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3522]  Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
+              for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003,
+              <https://www.rfc-editor.org/info/rfc3522>.
+
+   [RFC3708]  Blanton, E. and M. Allman, "Using TCP Duplicate Selective
+              Acknowledgement (DSACKs) and Stream Control Transmission
+              Protocol (SCTP) Duplicate Transmission Sequence Numbers
+              (TSNs) to Detect Spurious Retransmissions", RFC 3708,
+              DOI 10.17487/RFC3708, February 2004,
+              <https://www.rfc-editor.org/info/rfc3708>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, DOI 10.17487/RFC4960, September 2007,
+              <https://www.rfc-editor.org/info/rfc4960>.
+
+   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
+              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
+              <https://www.rfc-editor.org/info/rfc5681>.
+
+   [RFC5682]  Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,
+              "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
+              Spurious Retransmission Timeouts with TCP", RFC 5682,
+              DOI 10.17487/RFC5682, September 2009,
+              <https://www.rfc-editor.org/info/rfc5682>.
+
+   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,
+              "NACK-Oriented Reliable Multicast (NORM) Transport
+              Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
+              <https://www.rfc-editor.org/info/rfc5740>.
+
+   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
+              Iyengar, "Architectural Guidelines for Multipath TCP
+              Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
+              <https://www.rfc-editor.org/info/rfc6182>.
+
+   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
+              "Computing TCP's Retransmission Timer", RFC 6298,
+              DOI 10.17487/RFC6298, June 2011,
+              <https://www.rfc-editor.org/info/rfc6298>.
+
+   [RFC6675]  Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
+              and Y. Nishida, "A Conservative Loss Recovery Algorithm
+              Based on Selective Acknowledgment (SACK) for TCP",
+              RFC 6675, DOI 10.17487/RFC6675, August 2012,
+              <https://www.rfc-editor.org/info/rfc6675>.
+
+   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
+              Scheffenegger, Ed., "TCP Extensions for High Performance",
+              RFC 7323, DOI 10.17487/RFC7323, September 2014,
+              <https://www.rfc-editor.org/info/rfc7323>.
+
+Acknowledgments
+
+   This document benefits from years of discussions with Ethan Blanton,
+   Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the
+   members of the TCPM and TCPIMPL Working Groups.  Ran Atkinson,
+   Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley Eddy,
+   Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja
+   Kühlewind, Nicolas Kuhn, Jonathan Looney, and Michael Scharf provided
+   useful comments on previous draft versions of this document.
+
+Author's Address
+
+   Mark Allman
+   International Computer Science Institute
+   2150 Shattuck Ave., Suite 1100
+   Berkeley, CA 94704
+   United States of America
+
+   Email: mallman@icir.org
+   URI:   https://www.icir.org/mallman