RFC 2988

Computing TCP's Retransmission Timer 🎀

Okay bestie, here's the header tea ☕. This is RFC 2988, called Computing TCP's Retransmission Timer. It's a Standards Track doc, dated November 2000, written by V. Paxson (ACIRI) and M. Allman (NASA GRC/BBN). The header doesn't list anything it obsoletes or updates 🦋.

Status of This Memo

So this is an Internet standards track protocol doc for the whole Internet community, and it's literally asking everyone to share discussion and suggestions for improvements 💬. If you want the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited 🌈.

Copyright Notice

Legal stuff, but make it cute 💅: Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

The big idea: this doc defines the standard algorithm that TCP senders are required to use to compute and manage their retransmission timer ⏱️. It builds on section 4.2.3.1 of RFC 1122, and it levels up the requirement to support the algorithm from a SHOULD to a MUST 👑.

1. Introduction ✨

Okay so TCP [Pos81] uses a retransmission timer to make sure data actually gets delivered when the remote receiver has gone totally silent 🫠. The length of that timer is called RTO (retransmission timeout). RFC 1122 [Bra89] says the RTO should be calculated as outlined in [Jac88].

This doc basically codifies the algorithm for setting the RTO 📝. It also expands on section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST 🔥. RFC 2581 [APS99] outlines the algorithm TCP uses to start sending again after the RTO expires and a retransmission goes out. This document does not alter the behavior outlined in RFC 2581 [APS99].

Sometimes it may be beneficial for a TCP sender to be more conservative than the algorithms in this doc allow 🧁. But a TCP MUST NOT be more aggressive than the following algorithms allow. No speed-running this 😤.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bra97]. These are the official vibes words, so read them carefully 🧐.

2. The Basic Algorithm 💖

To compute the current RTO, a TCP sender keeps track of two state variables: SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation) 📊. We also assume a clock granularity of G seconds ⏲️.

Here are the rules for computing SRTT, RTTVAR, and RTO, in order 💅:

(2.1) Until a round-trip time (RTT) measurement has been made for a segment sent between the sender and receiver, the sender SHOULD set RTO <- 3 seconds (per RFC 1122 [Bra89]). The "backing off" on repeated retransmission from (5.5) still applies, though 🔁.

Note that some implementations may use a "heartbeat" timer that actually yields a value between 2.5 seconds and 3 seconds 💓. So a lower bound of 2.5 seconds is also acceptable, as long as the timer never expires faster than 2.5 seconds. Implementations using a heartbeat timer with a granularity of G SHOULD not set the timer below 2.5 + G seconds 🫶.

(2.2) When the first RTT measurement R is made, the host MUST set:

SRTT <- R
RTTVAR <- R/2
RTO <- SRTT + max (G, K*RTTVAR)

where K = 4 🌸.

(2.3) When a subsequent RTT measurement R' is made, a host MUST set:

RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
SRTT <- (1 - alpha) * SRTT + alpha * R'

Here's the sneaky part 👀. The value of SRTT used in the update to RTTVAR is its value before SRTT gets updated by the second assignment. So updating RTTVAR and SRTT MUST be computed in the above order, no shuffling allowed 🙅‍♀️.

The above SHOULD be computed using alpha=1/8 and beta=1/4 (as suggested in [JK88]) ✨.

After the computation, a host MUST update:

RTO <- SRTT + max (G, K*RTTVAR)

(2.4) Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second 🍓.

Traditionally, TCP implementations use coarse-grained clocks to measure the RTT and trigger the RTO. That imposes a big minimum value on the RTO 🐢. Research suggests a large minimum RTO is needed to keep TCP conservative and avoid spurious retransmissions [AP99]. So this spec requires a large minimum RTO as a conservative approach. It also admits that someday research may show a smaller minimum RTO is acceptable or even better 🔮.

(2.5) A maximum value MAY be placed on RTO, provided it is at least 60 seconds ⏳.

3. Taking RTT Samples 🦋

TCP MUST use Karn's algorithm [KP87] for taking RTT samples 🧠. That means RTT samples MUST NOT be made using segments that were retransmitted, because it's ambiguous whether the reply was for the first instance of the packet or a later one 😵‍💫. The only time TCP can safely take RTT samples from retransmitted segments is when the TCP timestamp option [JBB92] is in use. That's because the timestamp option removes the ambiguity about which instance of the data segment triggered the acknowledgment 💜.

Traditionally, TCP implementations have taken one RTT measurement at a time (typically once per RTT). But when the timestamp option is used, every ACK can count as an RTT sample 🤯. RFC 1323 [JBB92] suggests that TCP connections using large congestion windows should take many RTT samples per window of data, to avoid aliasing effects in the estimated RTT 🌈. A TCP implementation MUST take at least one RTT measurement per RTT (unless that isn't possible under Karn's algorithm) 💅.

For fairly modest congestion window sizes, research suggests that timing each segment doesn't lead to a better RTT estimator [AP99] 🙃. Also, when multiple samples are taken per RTT, the alpha and beta defined in section 2 may keep an inadequate RTT history. How to change these constants is still an open research question 🔬.

References ✨

bestie, here's the reading list for every source this spec leans on 📚🎀

• [AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM 99.
• [APS99] Allman, M., Paxson V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
• [Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
• [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [Jac88] Jacobson, V., "Congestion Avoidance and Control", Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
• [JK88] Jacobson, V. and M. Karels, "Congestion Avoidance and Control", ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
• [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 87.
• [Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

Author's Addresses 🌸

the two authors who wrote this one, and how to reach them 💌

Vern Paxson
ACIRI / ICSI
1947 Center Street
Suite 600
Berkeley, CA 94704-1198

Phone: 510-666-2882
Fax:   510-643-7684
EMail: vern@aciri.org
http://www.aciri.org/vern/

Mark Allman
NASA Glenn Research Center/BBN Technologies
Lewis Field
21000 Brookpark Rd.  MS 54-2
Cleveland, OH  44135

Phone: 216-433-6586
Fax:   216-433-8705
EMail: mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman

Full Copyright Statement 💖

okay so this is the legal part, but it's still lowkey important 🙈

The Internet Society owns the copyright, and it's (C) 2000, all rights reserved 💅. You can copy this document and hand it out, and you can make derivative works that comment on or explain it or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work. The one catch: you can't modify this document itself. That means no deleting the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards (in which case the Internet Standards process copyright procedures have to be followed), or when you're translating it into a language other than English.

The permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them 🦋

Now the disclaimer, which is in all caps for a reason 👑

THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN "AS IS" BASIS AND THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

last but not least, a shoutout to whoever's keeping the lights on 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. ⭐