RFC 8961

Requirements for Time-Based Loss Detection

📅 published November 2020, from ietf

RFC 8961 📜🎀 Requirements for Time-Based Loss Detection

okay bestie, settle in, we are getting into the loss detection lore 🦋

Here's the title block tea ☕: this is RFC 8961, written by M. Allman from ICSI 🌸. It's a Best Current Practice (BCP 233), published in November 2020. It does not obsolete or update any existing RFC (we'll hear more about that in Section 2 🙈). It's also an ISSN 2070-1721 document, so it's official official 💅.

Abstract ✨

Okay so, lots of protocols need to figure out when a packet has gone missing 📦💨. Maybe they want to retransmit it so the data actually arrives, or maybe they want to know how congested the path is 🚦. The thing is, no matter how many clever mechanisms we design, the only thing you can truly count on is time passing without anyone confirming delivery ⏳. So a protocol eventually declares a packet "lost" just because the clock ran out 🕰️.

Every time-based loss detector is basically a balancing act between being correct (not jumping the gun) and being timely (not being slow to react) ⚖️. That means there's no single perfect version that fits every situation 💀. This document lays out high-level requirements for time-based loss detectors that are fine for general use in unicast communication across the Internet 🌐. Inside those requirements, implementations get to decide the details that work best for their own situation 💖.

Status of This Memo 📋

This is an Internet Best Current Practice 🎀. It came out of the IETF and reflects the consensus of the IETF community, got public review, and was approved for publication by the IESG 👑. More info on BCPs lives in Section 2 of RFC 7841 🔗.

For the current status, any errata, and how to send feedback, check out 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 covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Read them carefully, because they spell out your rights and restrictions 📜. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 🌍

Okay so the Internet is a network of networks 🕸️, and it's literally full of every kind of link and system doing every kind of job 💅. The service you get ranges from best-effort delivery between loosely connected parts all the way to super predictable delivery in controlled spaces, like nodes that are physically wired together or a tightly controlled data center 🏢. Every path has its own set of properties, like available capacity, delay, and packet loss 📉. Given how wildly different networks are, those properties can be anything from basically frozen in place to constantly shifting 🌪️.

This doc is all about one path property: packet loss 💔. We're giving guidance for understanding it, and for building and implementing time-based loss detectors, which the community has been slowly learning about for several decades 🧠. We focus on the general case, where the loss properties of a path are (a) not known ahead of time and (b) changing over time 🔄. Also, even though packet loss has tons of root causes, we go with the conservative idea that loss is an implicit sign of congestion [RFC5681] 🚨. That isn't always accurate, but as a general assumption it has worked out pretty well for us historically [Jac88] 💯. As we'll get into in Section 2, the guidance here should be seen as a general default for unicast communication across best-effort networks, not as the optimal choice (or even an applicable one) for every situation 🙈.

Since packet loss is totally routine on best-effort networks, loss detection matters a lot for many protocols and apps, and it usually happens for two big reasons 🎯:

(1) Ensuring reliable data delivery

This means a data sender needs to figure out which transmitted packets never reached the receiver 📭. With that info, the sender can retransmit the missing data 🔁.

(2) Congestion control

Like we said above, packet loss is often treated as an implicit sign that the sender is going too fast and swamping some part of the network path 🌊. So senders can use loss to trigger a cut in their transmission rate 📉.

Loss detection can happen in a bunch of ways 🧩. Often, the recipient sends continuous or periodic acknowledgments, and the sender uses those to work out which pieces of data are missing ✅. But even with our best intentions and the sturdiest mechanisms, we can't put our full faith in acknowledgments showing up 😭. The only thing we can truly depend on is the passage of time ⏰. So our ultimate backstop for catching all loss is a timeout ⏲️. In other words, the sender sets an expectation for how long to wait for confirmation of a given piece of data 🎀. If that time goes by with no confirmation, the sender concludes the data was lost in transit 💀.

Time-based loss detection schemes are a tradeoff between correctness and responsiveness ⚖️. We want to do two things at once 👯:

  • wait long enough that detecting a loss is correct, and
  • keep the delay we impose on applications (before repairing loss) and on the network (before we ease off congestion) as small as possible 🏃‍♀️.

Doing both is hard, because they pull in opposite directions [AP99] 🙃. If we don't wait long enough to be accurate about a packet being lost, we might get a needed retransmission out quickly, but we also risk sending unnecessary ("spurious") retransmissions and needlessly slowing down our transmission rate 😩. If we wait until we're totally, unambiguously sure a packet is lost, we can't repair losses in a timely way, and we risk dragging out network congestion 🚧.

Lots of protocols and apps, like TCP [RFC6298], SCTP [RFC4960], and SIP [RFC3261], use their own time-based loss detection mechanisms 🧁. At this point, our experience tells us that specific tweaks that stray from standardized time-based loss detectors often don't materially affect network safety with respect to congestion control [AP99] ✨. So in this document we outline a set of high-level, protocol-agnostic requirements for time-based loss detection 🌈. The goal is a safe foundation that gives implementations the freedom to build the mechanisms that best meet their own 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 doc is kinda different from how we'd ideally like to build systems 🙃. Usually, we want to understand the high-level requirements first, as a starting point 🎯. Then we carefully engineer specific protocols, algorithms, and systems that meet those requirements 🛠️. But in the IETF standards process, we came up with a lot of time-based loss detection schemes without any overarching requirements doc, because we had no idea how to write one! 😭 So we made the best specific calls we could for the needs in front of us 💅.

By now, though, the community's experience has matured enough that we can define a set of general, high-level requirements for time-based loss detection schemes 🌸. We now get how to separate the strategies these mechanisms use that are crucial for network safety from the small details that don't materially affect it 🔍. The requirements here might not fit every case. Specifically, the guidance in Section 4 is about the general case, but specific situations can allow more flexibility in loss detection, because particular parts of the environment are known (for example, when operating over a single physical link or inside a tightly controlled data center) 🏢. So variants, deviations, or completely different time-based loss detectors may be necessary or useful in some cases 🦋. The right way to read this document is as the default case, not as one-size-fits-all guidance that's optimal everywhere 💜.

Bolting a requirements umbrella onto a pile of existing specs is inherently messy, and we risk creating inconsistencies with both past and future mechanisms 😬. So here's how this document relates to past and future specifications 📜:

  • This document does not update or obsolete any existing RFC. These previous specifications, while generally consistent with the requirements here, reflect community consensus, and this document doesn't change that consensus 🫶.
  • The requirements in this document are meant to provide for network safety, so they SHOULD be used by all future time-based loss detection mechanisms 🔥.
  • The requirements in this document might not be appropriate in all cases, so deviations and variants may be necessary in the future (that's why there's a "SHOULD" in the last bullet) 🙈. However, inconsistencies MUST be (a) explained and (b) gather consensus 💅.

that's the end of part 1 bestie, more parts are coming, so stay tuned 🎀✨

3. Scope 🎀

Okay so the principles in this doc are protocol-agnostic 💅 which means they aren't married to any one protocol, and they're widely applicable 🦋 Before we get to the requirements in Section 4, here are the scope statements, bestie 🫶

(S.1) Timers are everywhere in protocols 🙈 There's a whole bevy of uses for them, from rate-based pacing to connection failure detection and beyond ✨ But this document is focused only on loss detection 💖

(S.2) This one's the big one 👑 The requirements for time-based loss detection mechanisms here are for the primary or "last resort" loss detection mechanism 🫶 That's true whether the mechanism is the sole loss repair strategy or it works in concert with other mechanisms.

Now, a straightforward time-based loss detector is enough for simple protocols like DNS [RFC1034] [RFC1035] 💅 But more complex protocols often use fancier loss detectors to help with performance. For example, TCP and SCTP have ways to detect (and repair) loss based on explicit endpoint state sharing [RFC2018] [RFC4960] [RFC6675] 🧚 These mechanisms often give more timely and precise loss detection than time-based loss detectors do.

BUT (and this is a big but 😭), these mechanisms do not get rid of the need for a "retransmission timeout" or "RTO." Why? As we talk about in Section 1, only the passage of time can ultimately be relied upon to detect loss 💀 We can't count on acknowledgments to reach the data sender to say which packets never arrived at the receiver. So in cases like these, we need a time-based loss detector to function as a "last resort" 🌸

Also, some recent proposals have baked time into advanced loss detection methods, either as an aggressive first loss detector in certain situations or together with endpoint state sharing [DCCM13] [CCDJ20] [IS20] ✨ These can totally help with timely loss recovery, but the protocol still leans on another, more conservative timer to keep reliability intact when these mechanisms break down 🙃 The requirements in this document are only directly applicable to last-resort loss detection. That said, we expect that many of the requirements can serve as useful guidelines for more aggressive non-last-resort timers too 🌈

(S.3) The requirements in this document apply only to endpoint-to-endpoint unicast communication 🦋 Reliable multicast protocols (e.g., [RFC5740]) are explicitly outside the scope of this document, so no multicast drama here 🙅‍♀️

That said, protocols like SCTP [RFC4960] and Multipath TCP (MP-TCP) [RFC6182] communicate in a unicast fashion with multiple specific endpoints 💜 They can leverage the requirements in this document, provided they track state and follow the requirements for each endpoint independently. Like, if host A talks to addresses B and C, then A needs to use independent time-based loss detector instances for traffic sent to B and C. Separate instances, no mixing 💅

(S.4) There are cases where state is shared across connections or flows (e.g., [RFC2140] and [RFC3124]) 👀 State about time-based loss detection is often discussed as sharable. But these situations raise issues that the simple flow-oriented time-based loss detection mechanism in this document doesn't consider, like how long to preserve state between connections 😬 So even though the general principles in Section 4 are likely applicable, sharing time-based loss detection information across flows is outside the scope of this document 🚫

4. Requirements ✨

okay so bestie, this is the part where we get into the actual rules 💅 we're designing a time-based loss detection mechanism, which means the primary one or the last-resort one. 🦋 for historical reasons (and to make things easier to explain), we call the time between sending a packet and deciding it got lost because nobody confirmed delivery the "retransmission timeout" or "RTO" ⏰. once the RTO passes with no delivery confirmation, the sender can safely assume the packet is lost 🫶. BUT, as we talked about earlier, the loss doesn't have to get repaired. it could be detected just for congestion control and not for reliability 🌸

Here are the requirements, numbered (1) through (4) 🎀

(1) ✨ The initial RTO ✨

okay so loss detection happens when the sender doesn't get delivery confirmation within some expected amount of time 🙈 if we know nothing about how fast a path is, the initial RTO MUST be set conservatively to no less than 1 second. no exceptions, periodt 💖

correctness is the most important thing when you're sending into a network with unknown properties, because:

  • premature loss detection can trigger spurious retransmits 💀 which is a disaster when the network is already congested
  • premature loss detection can also make congestion control dramatically lower the sender's allowed transmission rate 📉 and the rate is probably already low at this stage, so recovering from that takes forever 😭
  • sometimes time-based loss detection and retransmissions make it ambiguous to figure out the latency of a network path 🌀 so it's super important that the very first latency sample is unambiguous, so there's a solid baseline for everything after 👑

the 1 second number comes from the analysis of Internet round-trip times (RTTs) in Appendix A of [RFC6298] 📚

(2) ✨ Setting the expected time interval ✨

we've got four requirements about how to set the expected time for delivery confirmation 🧚

people usually talk about this as measuring the RTT of the path 💅 the RTT is the minimum time needed to get delivery confirmation, and it often works because acknowledgments are sent really quickly after data shows up ⚡ that's how the RTO works in TCP [RFC6298] and SCTP [RFC4960] 🌈 but honestly that's a bit misleading 🙃 the expected latency is better described as the "feedback time" (FT) ✨ the expectation isn't always just a network property, it can include extra time before a sender should reasonably expect a reply 🦋

for example, think about a UDP-based DNS request from a client to a recursive resolver [RFC1035] 💜 if the answer comes straight from the resolver's cache, the FT pretty much matches the network RTT between client and resolver 🍓 but on a cache miss, the resolver has to ask one or more authoritative DNS servers, and that noticeably increases the FT compared to the RTT between client and resolver 😤

so we express the requirements in terms of FT 🎀 and again, to keep things simple, we use "RTO" for the interval between sending a packet and deciding it was lost, whether or not it'll get retransmitted 🔥

(a) ✨ Use multiple observations ✨

The RTO SHOULD be set based on multiple observations of the FT when they're available. 💖

basically the RTO should be an empirically derived, reasonable amount of time the sender waits for delivery confirmation before deciding the data is lost 🌸 network paths are always changing, so it's crucial to include multiple recent FT samples in the RTO to account for delay variation over time 🌊

TCP's RTO [RFC6298] totally satisfies this because it uses an exponentially weighted moving average (EWMA) to combine multiple FT samples into a "smoothed RTT" 👑 and to be extra conservative, TCP also adds an explicit variance term when computing the RTO 🫶

we're really not going to pin down exactly how this works 🙅‍♀️ including how many FT samples to use and how/when to age them out of the RTO calculation 🕰️ the details could depend on each loss detector's situation and goals, so they're up to the implementer 💅

finally, FT samples come from packet exchanges between peers 🤝 we really encourage protocol designers (especially for new protocols) to make sure the feedback can't be easily spoofed by on-path or off-path attackers 🕵️‍♀️ because they could mess with a host's idea of the FT 😈 ideally every message would be cryptographically secure 🔐 but that's not always possible, especially in legacy protocols, so using a healthy amount of randomness in the packets is encouraged 🎲

(b) ✨ Keep sampling ✨

FT observations SHOULD be taken and incorporated into the RTO at least once per RTT, or as often as data is exchanged if that happens less than once per RTT 🦋

internet measurements show that taking just a single FT sample per TCP connection gives a relatively poorly performing RTO mechanism [AP99] 😬 that's why this requirement says the FT should be sampled continuously for the whole lifetime of the communication ⏳

for example, TCP takes an FT sample roughly once per RTT, or, if it uses the timestamp option [RFC7323], on each acknowledgment arrival ✨ [AP99] shows that both of these approaches give roughly equivalent performance for the RTO estimator 🙌

(c) ✨ Non-data exchanges are optional ✨

FT observations MAY be taken from non-data exchanges 🧁

some protocols use non-data exchanges for stuff like keepalives, heartbeats, and control messages 💌 to the extent that the latency of these exchanges mirrors data exchange, they can be used to take FT samples for the RTO mechanism 🎯 those samples can help protocols keep their RTO accurate during lulls in data transmission 😌 however, since these messages might not face the same delays as data, we don't take a general position on whether this is useful 🤷‍♀️

(d) ✨ No ambiguous samples ✨

An RTO mechanism MUST NOT use ambiguous FT samples. 🚫

imagine two copies of some packet X get sent at times t0 and t1 📦📦 then at time t2, the sender gets confirmation that X arrived 📬 but sometimes it's unclear which copy triggered that confirmation 😵 so the actual FT is either t2-t1 or t2-t0, and nobody knows which one 🔮 in that situation, an implementation MUST NOT use either version of the FT sample, and so it must not update the RTO (as discussed in [KP87] and [RFC6298]) 🙅‍♀️

there are situations where the sender can tell which copy an incoming ACK is for 🙌 for example, TCP's timestamp option [RFC7323] lets packets be uniquely identified, so the ambiguity goes away ✨ in those cases there's no ambiguity, and the resulting samples can update the RTO 💖

(3) ✨ Loss means congestion ✨

Loss detected by the RTO mechanism MUST be taken as an indication of network congestion, and the sending rate MUST be adapted using a standard mechanism (e.g., TCP collapses the congestion window to one packet [RFC5681]). 🚨

this keeps the network safe 🛡️

there's one exception 🙃 if an IETF standardized mechanism figures out that a particular loss was due to a non-congestion event (like packet corruption), then a congestion control action isn't required 🙅‍♀️ also, congestion control actions taken based on time-based loss detection can be reversed when a standard mechanism later decides the loss wasn't caused by congestion (e.g., [RFC5682]) 🔄

(4) ✨ Backing off the RTO ✨

Each time the RTO is used to detect a loss, the value of the RTO MUST be exponentially backed off so 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, and 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 keeps the network safe too 🛡️

same as guideline (3), there's an exception 💅 if an IETF standardized mechanism determines that a particular loss isn't due to congestion, the rule doesn't apply 🦋

5. Discussion 🧠✨

okay so research has shown that the tension between responsiveness and correctness in time-based loss detection seems to be a fundamental tradeoff for TCP [AP99] 😭. Making the RTO more aggressive (like changing TCP's exponentially weighted moving average (EWMA) gains or lowering the minimum RTO) can cut the time it takes to detect actual loss. but ngl, that same aggressiveness leads to more cases of mistakenly declaring packets lost when they actually did reach the receiver 💀. So being as aggressive as the requirements in the previous section allow, in any particular situation, may not be the best move, because even a false loss detection still has to invoke a congestion response that ultimately reduces the transmission rate 🙈

the tradeoff seems fundamental, but it can become way less relevant if the sender can detect and recover from mistaken loss detection 🦋. There are a few mechanisms for this, like Eifel [RFC3522], Forward RTO-Recovery (F-RTO) [RFC5682], and Duplicate Selective Acknowledgement (DSACK) [RFC2883] [RFC3708]. Using these may let a data originator tip toward being more responsive without taking on (as much of) the attendant costs of mistakenly declaring packets lost 🎀

also, besides the experiments in [AP99], the Linux TCP implementation has been using various non-standard RTO mechanisms for many years, seemingly without large-scale problems 👑 (for example, using different EWMA gains than specified in [RFC6298]). A number of TCP implementations also use a steady-state minimum RTO that is less than the 1 second specified in [RFC6298] 🌸. The implication of these deviations may be more spurious retransmits (per [AP99]), but 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, while letting implementations be more aggressive could in fact increase needless retransmissions, the requirements above fail safely 🛡️. They insist on exponential backoff and a transmission rate reduction. So giving 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 ✨

the vibe check: aggressive isn't automatically unsafe, but it's never free, and the mechanism is built so that the cost always comes back around 💅

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
📦 where this page comes from