RFC 6069

Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)

📅 published December 2010, from ietf

Title Block 🎀

Okay bestie, this one is RFC 6069, Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) 🦋. It's an Experimental RFC from December 2010, written by A. Zimmermann and A. Hannemann at RWTH Aachen University. Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's a standalone doc 💅.

Abstract 💖

Okay so, disruptions in end-to-end path connectivity that last longer than one retransmission timeout make TCP perform suboptimally 😭. The reason is that TCP treats the segment loss caused by a long disruption as a sign of congestion, so the retransmission timer keeps backing off again and again 🥲. Then TCP is slow to notice the connection is back, because it waits for the next retransmission timeout before it even tries to retransmit ⏳.

This doc proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD) 🧚. It explains how standard ICMP messages can be used during timeout-based loss recovery to tell true congestion loss apart from non-congestion loss caused by connectivity disruptions 🔍. It also specifies a reversion strategy for the retransmission timer, so TCP can promptly detect whether connectivity to a previously disconnected peer node has been restored 🌸. TCP-LCD is a TCP sender-only modification that effectively improves TCP performance during connectivity disruptions ✨.

Status of This Memo 📝

This document is not an Internet Standards Track specification 🙈. It's published for examination, experimental implementation, and evaluation.

This document defines an Experimental Protocol for the Internet community 🧪. It's a product of the Internet Engineering Task Force (IETF), and 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). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🫶.

Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6069 🔗.

Copyright Notice ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document 📜. Please review these documents carefully, because 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 they're provided without warranty as described in the Simplified BSD License 🎀.

Table of Contents 🗂️

1. Introduction ....................................................3
2. Terminology .....................................................4
3. Connectivity Disruption Indication ..............................5
4. Connectivity Disruption Reaction ................................7
   4.1. Basic Idea .................................................7
   4.2. Algorithm Details ..........................................8
5. Discussion of TCP-LCD ..........................................11
   5.1. Retransmission Ambiguity ..................................12
   5.2. Wrapped Sequence Numbers ..................................12
   5.3. Packet Duplication ........................................13
   5.4. Probing Frequency .........................................14
   5.5. Reaction during Connection Establishment ..................14
   5.6. Reaction in Steady-State ..................................14
6. Dissolving Ambiguity Issues Using the TCP Timestamps Option ....15
7. Interoperability Issues ........................................17
   7.1. Detection of TCP Connection Failures ......................17
   7.2. Explicit Congestion Notification (ECN) ....................17
   7.3. TCP-LCD and IP Tunnels ....................................17
8. Related Work ...................................................18
9. Security Considerations ........................................19
10. Acknowledgments ...............................................20
11. References ....................................................20
   11.1. Normative References .....................................20
   11.2. Informative References ...................................21

1. Introduction 🌈

Connectivity disruptions can happen in lots of different situations 🌍. How often they happen depends on the properties of the end-to-end path between the communicating hosts. They can happen in traditional wired networks too, like when a network cable gets unplugged 🔌, but the likelihood is significantly higher in wireless (multi-hop) networks 📶. End-host mobility, network topology changes, and wireless interference are the crucial factors 🔥. For the Transmission Control Protocol (TCP) [RFC0793], a connection's performance can drop a lot compared to a permanently connected path [SESB05] 😩. That's because TCP was originally designed for fixed, wired networks, so it generally assumes the end-to-end path connectivity stays pretty stable over the connection's lifetime 🥺.

Depending on how long they last, connectivity disruptions can be sorted into two groups [TCP-RLCI]: "short" and "long" 🍓. A disruption is "short" if connectivity comes back before the retransmission timer fires for the first time 💨. In that case, TCP recovers lost data segments through Fast Retransmit, and lost acknowledgments (ACKs) through later ACKs that get delivered successfully 🙌. A disruption is declared "long" for a given TCP connection if the retransmission timer fires at least once before connectivity resumes 🐢. Whether path characteristics, like the round-trip time (RTT) or the available bandwidth, have changed when connectivity resumes after a disruption is another important aspect for TCP's retransmission scheme [TCP-RLCI] 🧐.

The algorithm in this document makes TCP behave better during "long connectivity disruptions" 👑. It focuses on the period before connectivity to a previously disconnected peer node is re-established 🔜. The document doesn't describe any changes to TCP's behavior or its congestion control mechanisms [RFC5681] after connectivity has been restored 🙅‍♀️.

When a long connectivity disruption happens on a TCP connection, the TCP sender eventually stops getting acknowledgments 😱. After the retransmission timer expires, the sender enters timeout-based loss recovery and declares the oldest outstanding segment (SND.UNA) as lost 💀. TCP tightly couples reliability and congestion control, so the retransmission of SND.UNA is triggered together with a reduction in the transmission rate. That's based on the assumption that segment loss is an indication of congestion [RFC5681] 🚦. As long as the disruption persists, TCP repeats this procedure until the oldest outstanding segment is acknowledged successfully, or until the connection times out 🔁. TCP implementations that follow the recommended retransmission timeout (RTO) management of RFC 2988 [RFC2988] double the RTO after each retransmission attempt 📈. However, the RTO growth may be bounded by an upper limit, the maximum RTO, which is at least 60 s but may be longer. Linux, for example, uses 120 s ⏱️. If connectivity is restored between two retransmission attempts, TCP still has to wait for the retransmission timer to expire before it resumes transmission, because it simply has no way to know the connectivity is back 😤. So depending on when connectivity returns, this can waste up to a maximum RTO's worth of possible transmission time 🗑️.

This retransmission behavior isn't efficient, especially in scenarios with long connectivity disruptions 😬. In the ideal case, TCP would attempt a retransmission as soon as connectivity to its peer has been re-established 🤩. This document specifies a TCP sender-only modification that gives robustness to long connectivity disruptions (TCP-LCD) 💅. It describes how the standard Internet Control Message Protocol (ICMP) can be exploited during timeout-based loss recovery to identify non-congestion loss caused by long connectivity disruptions 🕵️‍♀️. TCP-LCD's reversion strategy for the retransmission timer enables higher-frequency retransmissions, and that means a prompt detection when connectivity to a previously disconnected peer node has been restored 🎉. If no congestion is present, TCP-LCD gets really close to the ideal behavior 🫶.

Experimental results of a Linux implementation of TCP-LCD have been presented in [ZimHan09] 🧪. The implementation has been incorporated into mainline Linux, and it's already being used on the Internet 🌐. So far, no negative experiences have been reported that could be attributed to the algorithm 🙏. Still, we consider TCP-LCD experimental until more real-life results have been obtained 🔬. That said, we encourage implementing TCP-LCD under other operating systems too, so there are more chances for broader testing and experimentation 🌟.

2. Terminology 📚

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 [RFC2119] 🎀.

You should be familiar with the algorithm and terminology from [RFC2988] 🧠. It defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. In this document, the terms "retransmission timer" and "retransmission timeout" are used as defined in [RFC2988]. The retransmission timer makes sure data gets delivered even when there's no feedback from the receiver ⏰. The duration of this timer is called the retransmission timeout (RTO) 💖.

As defined in [RFC0793], the term "acceptable acknowledgment (ACK)" means a TCP segment that acknowledges previously unacknowledged data ✅. The TCP sender state variable SND.UNA and the current segment variable SEG.SEQ are used as defined in [RFC0793] 🧩. SND.UNA holds the segment sequence number of the earliest segment that the TCP receiver has not acknowledged yet, which is the oldest outstanding segment 👵. SEG.SEQ is the segment sequence number of a given segment 🔢.

For this specification, we define the term "timeout-based loss recovery" 🧯. It refers to the state a TCP sender enters upon the first timeout of the oldest outstanding segment (SND.UNA), and it leaves that state upon the arrival of the first acceptable ACK 🚪. Heads up, other documents use a different interpretation of "timeout-based loss recovery" 👀. For example, the NewReno modification to TCP's Fast Recovery algorithm [RFC3782] extends the period that a TCP sender stays in timeout-based loss recovery, compared to the one defined in this document. That's because [RFC3782] tries to avoid unnecessary multiple Fast Retransmits that can happen after an RTO 🙃.

Okay so, if the queue of an intermediate router dealing with a link outage can buffer every incoming packet, the disruption only causes a variation in delay 🫠 and TCP handles that really well, whether it's using Eifel [RFC3522], [RFC4015] or Forward RTO-Recovery (F-RTO) [RFC5682]. But if the outage drags on for too long, the router is forced to drop packets, and it might eventually remove that next hop from its routing table 😭. Ways to detect these outages include reacting to failed address resolution protocol (ARP) [RFC0826] queries, sensing unsuccessful links, and things like that. Still, that's totally the router's own job 💅.

Note: The focus of this memo is on introducing a method for how ICMP messages can be exploited to improve TCP's performance 🎀. How different physical and link-layer mechanisms below the network layer might trigger ICMP destination unreachable messages is out of scope here 🙈.

Assuming there's no other route to the destination, an Internet Protocol version 4 (IPv4) [RFC0791] router will tell the sending host about the dropped packets using ICMP destination unreachable messages of code 0 (net unreachable) or code 1 (host unreachable) [RFC1812]. So the sending host can treat ICMP destination unreachable messages with these codes as a sign of a connectivity disruption ✨, because getting one is proof that the packets were dropped because of a link outage 🦋.

For Internet Protocol version 6 (IPv6) [RFC2460], the equivalent of ICMP destination unreachable of code 0 (net unreachable) and code 1 (host unreachable) is the ICMPv6 destination unreachable message of code 0 (no route to destination) [RFC4443]. Same as with IPv4, a router should generate an ICMPv6 destination unreachable message of code 0 when it gets a packet it can't deliver to its destination address because there's no matching entry in its routing table 🧚.

Heads up, there are other ICMP and ICMPv6 destination unreachable messages with different codes too 👀. Some of them could be connectivity disruption indications as well, but they need more investigation (for example, ICMP destination unreachable messages with code 5 (source route failed), code 11 (net unreachable for TOS (Type of Service)), or code 12 (host unreachable for TOS) [RFC1812]). On the other hand, codes that flag hard errors are no use for this scheme, since TCP should abort the connection when it receives those [RFC1122] 💀.

For simplicity, unless we say ICMPv4 or ICMPv6 explicitly, "ICMP unreachable message" means ICMP destination unreachable messages of code 0 or code 1 and ICMPv6 destination unreachable messages of code 0 🌸. That also means every keyword from [RFC2119] that covers how received ICMP messages are handled applies the same way to ICMPv6 messages 🫶.

Reading ICMP unreachable messages as a connectivity disruption indication is tricky, because of two quirks of ICMP messages 🙃. First, they don't necessarily run on the same timescale as the packets, meaning the TCP segments that triggered them. When a router drops a packet because a route is missing, it won't necessarily send the ICMP unreachable message right away. It'll just queue it for later delivery ⏳. Second, ICMP messages get rate-limited. So if a router drops a whole window of data during a link outage, it's unlikely to send as many ICMP unreachable messages as it dropped TCP segments 😩. Depending on how loaded the router is, it might not send any ICMP unreachable messages at all. Both quirks come from [RFC1812] for ICMPv4 and [RFC4443] for ICMPv6 🍓.

Thankfully, according to [RFC0792], ICMPv4 unreachable messages have to include the entire IPv4 header [RFC0791] of the datagram that triggered them in their body, plus the first 64 bits of that datagram's payload 🎀. That lets the sending host match the ICMPv4 error message to the transport connection that caused it 🔍. RFC 1812 [RFC1812] builds on those requirements and says ICMPv4 messages should include as much of the original datagram as possible, as long as the ICMPv4 datagram doesn't go over 576 bytes 📏. So for TCP, at least the source port number, the destination port number, and the 32-bit TCP sequence number are included 💜. That lets the originating TCP demultiplex the received ICMPv4 message and figure out which connection is affected ✨. It can also work out which segment of that connection triggered the ICMPv4 unreachable message, unless several segments in flight share the same sequence number (see Section 5.1) 👑.

For IPv6 [RFC2460], the payload of an ICMPv6 error message has to include as many bytes as possible from the IPv6 datagram that triggered it, without pushing the error message past the minimum IPv6 MTU (1280 bytes) [RFC4443] 🌈. So there's enough info to identify both the affected connection and the exact segment that set off the ICMPv6 error message 🔥.

A connectivity disruption indication in the form of an ICMP unreachable message tied to a presumably lost TCP segment is strong evidence that the segment wasn't dropped because of congestion 🙌. It was successfully delivered as far as the reporting router, so that router didn't see any congestion, at least on the part of the path that both the TCP segment and the ICMP unreachable message crossed 🦋.

4. Connectivity Disruption Reaction ⭐

Section 4.1 introduces the basic idea of TCP-LCD 🩷. The complete algorithm is specified in Section 4.2 📜.

4.1. Basic Idea 💡

The goal of the algorithm is to promptly detect when connectivity to a previously disconnected peer node has come back after a long connectivity disruption, all while keeping the right behavior when there's congestion 🚦. TCP-LCD uses standard ICMP unreachable messages during timeout-based loss recovery 🧠. This increases TCP's retransmission frequency by undoing one retransmission timer backoff each time an ICMP unreachable message arrives that contains a segment with the sequence number of a presumably lost retransmission 🔁.

This approach is great because it reduces the probing rate appropriately when there's congestion 🌷. If either the retransmission itself or the corresponding ICMP message gets dropped, the earlier retransmission timer backoff doesn't get undone, which effectively halves the probing rate 🫧.

4.2. Algorithm Details ✨

okay so this is where it gets SO good 💅 A TCP sender that uses RFC 2988 [RFC2988] to work out TCP's retransmission timer MAY use the following scheme so it doesn't over-punish itself with super-conservative backoffs when a connectivity disruption goes on for ages 🫶 If a TCP sender does implement these steps, the algorithm MUST start on the first timeout of the oldest outstanding segment (SND.UNA) and MUST stop when the first acceptable ACK shows up 🎀 It MUST NOT restart on later timeouts for that same segment. The scheme SHOULD NOT be used in the SYN-SENT or SYN-RECEIVED states [RFC0793] (see Section 5.5) 🙈

A TCP sender that does not use RFC 2988 [RFC2988] to compute its retransmission timer MUST NOT use TCP-LCD. The vibe is that this could be adapted to other algorithms besides RFC 2988 🌈 but that's left as future work, bestie ✨

RFC 2988 [RFC2988] has rule (2.5), which lets you put a maximum value on the RTO. When a TCP does this to set an upper bound on the RTO, it MUST also use it in the following algorithm 💖 Specifically, if the RTO is capped by an upper limit (maximum RTO), the "MAX_RTO" variable used in this scheme MUST be initialized with that upper limit. Otherwise, if the RTO is unbounded, the "MAX_RTO" variable MUST be set to infinity 🧚

This scheme uses a "BACKOFF_CNT" variable, which starts at zero 🍓 It counts how many retransmission timer backoffs happen during one timeout-based loss recovery. There's also a "RTO_BASE" variable that lets you recover the previous RTO if a backoff turned out to be unnecessary 🦋 It gets initialized with the RTO when timeout-based loss recovery starts.

(1) Before TCP updates the "RTO" variable when it starts timeout-based loss recovery, set "BACKOFF_CNT" and "RTO_BASE" like this:

BACKOFF_CNT := 0;
RTO_BASE := RTO.

Then proceed to step (R) 🌸

(R) This is a placeholder for standard TCP's behavior when the retransmission timer has expired. Specifically, if RFC 2988 [RFC2988] is in use, steps (5.4) to (5.6) of that algorithm go here. Then proceed to step (2) 💅

(2) To account for the expiration of the retransmission timer in the previous step (R), increment "BACKOFF_CNT" by one:

BACKOFF_CNT := BACKOFF_CNT + 1.

(3) Wait for ONE of these things 👑

a) the retransmission timer to expire. When it does, proceed to step (R); or

b) an acceptable ACK to arrive. When one does, proceed to step (A); or

c) an ICMP unreachable message to arrive. When the ICMP unreachable message "ICMP_DU" arrives, proceed to step (4).

(4) If "BACKOFF_CNT > 0", i.e., if at least one retransmission timer backoff can be undone, then

proceed to step (5);

else

proceed to step (3).

(5) Extract the TCP segment header included in the ICMP unreachable message "ICMP_DU":

SEG := Extract(ICMP_DU).

(6) If "SEG.SEQ == SND.UNA", i.e., if the TCP segment "SEG" that triggered the ICMP unreachable message "ICMP_DU" contains the sequence number of a retransmission, then

proceed to step (7);

else

proceed to step (3).

(7) Undo the last retransmission timer backoff:

BACKOFF_CNT := BACKOFF_CNT - 1;
RTO := min(RTO_BASE * 2^(BACKOFF_CNT), MAX_RTO).

(8) If the retransmission timer expires because of the undo in the previous step (7), then

proceed to step (R);

else

proceed to step (3).

(A) This is a placeholder for standard TCP's behavior when an acceptable ACK has arrived. No further processing 🫶

When a TCP in steady-state spots a segment loss using the retransmission timer, it enters timeout-based loss recovery and kicks off the algorithm (step (1)) 🔥 It adjusts the slow-start threshold (ssthresh), sets the congestion window (cwnd) to one segment, backs off the retransmission timer, and retransmits the first unacknowledged segment (step (R)) [RFC5681], [RFC2988]. To account for the timer expiring, the TCP sender bumps "BACKOFF_CNT" by one (step (2)) ✨

If the retransmission timer expires again (step (3a)), a TCP repeats the retransmission of the first unacknowledged segment and backs off the timer once more (step (R)) [RFC2988], and also increments "BACKOFF_CNT" by one (step (2)) 💜 Heads up: a TCP may use RFC 2988's [RFC2988] option to cap the RTO, which can mean the backoff doesn't actually happen. Even so, step (2) MUST always and unconditionally be applied, whether or not the timer is really backed off 🚨 In other words, every time the retransmission timer expires, "BACKOFF_CNT" MUST be incremented by one.

If the first packet received after the retransmission(s) is an acceptable ACK (step (3b)), the TCP just carries on as normal: it slow-starts the connection and ends the algorithm (step (A)) 🌈 Any later ICMP unreachable messages from that now-finished timeout-based loss recovery get ignored, since the ACK clock is already restarting thanks to the successful retransmission 🦋

On the other hand, if the first packet received after the retransmission(s) is an ICMP unreachable message (step (3c)), and step (4) allows it, TCP SHOULD undo one backoff for each ICMP unreachable message reporting an error on a retransmission 🙈 To figure out whether an ICMP unreachable message was triggered by a retransmission, the sequence number it contains gets checked (step (5), step (6)). The undo happens by recalculating the RTO using the decremented "BACKOFF_CNT" variable (step (7)). This calculation explicitly matches the (bounded) exponential backoff specified in rule (5.5) of [RFC2988] 💖

When an ICMP unreachable message that legitimately undoes one backoff arrives, the shortened retransmission timer may already have expired (step (8)). In that case, TCP SHOULD retransmit immediately. If the shortened timer hasn't expired yet, TCP MUST wait accordingly 🍓

Discussion of TCP-LCD 🎀

okay so TCP-LCD is SUPER careful 🥹 It only reacts to connectivity disruption indications in the form of ICMP unreachable messages received during timeout-based loss recovery. So TCP's behavior stays the same when either no ICMP unreachable messages arrive, or the TCP sender's retransmission timer hasn't expired since the last acceptable ACK it got. By definition, the algorithm only triggers during long connectivity disruptions 👑

Only ICMP unreachable messages that contain a TCP segment with the sequence number of a retransmission, i.e., that contain SND.UNA, get evaluated by TCP-LCD. Every other ICMP unreachable message gets ignored 💅 Getting one of those ICMP messages is strong evidence that the retransmissions weren't dropped because of congestion, but were successfully delivered to the reporting router ✨ In other words, there's no evidence of congestion, at least on that specific part of the path that was traversed by both the TCP segment that triggered the ICMP unreachable message and the ICMP unreachable message itself 🦋

However, there are some situations where TCP-LCD makes a false call and wrongly undoes a retransmission timer backoff 🙈 This can happen even when the ICMP unreachable message contains the sequence number of a retransmission (SND.UNA), because the TCP segment that triggered the ICMP unreachable message may either not be a retransmission (Section 5.1) or may not belong to the current timeout-based loss recovery (Section 5.2). Finally, packet duplication (Section 5.3) can also spuriously trigger the algorithm 💀

Section 5.4 talks about possible probing frequencies, while Section 5.6 explains the motivation for not reacting to ICMP unreachable messages while TCP is in steady-state 🌸

5.1. Retransmission Ambiguity 🔍

Historically, the retransmission ambiguity problem [Zh86], [KP87] is the TCP sender's inability to tell whether the first acceptable ACK after a retransmission refers to the original transmission or to the retransmission 😭 This problem shows up after both a Fast Retransmit and a timeout-based retransmit. Modern TCP implementations can clear up the retransmission ambiguity with the help of either Eifel [RFC3522], [RFC4015] or Forward RTO-Recovery (F-RTO) [RFC5682] 💖

The reversion strategy of the given algorithm has a form of retransmission ambiguity too 🌈 Unlike the case above, TCP has ambiguity about ICMP unreachable messages received during timeout-based loss recovery. With the TCP segment number included in the ICMP unreachable message, a TCP sender can't determine whether the ICMP unreachable message refers to the original transmission or to any of the timeout-based retransmissions. So there's an ambiguity about which TCP segment an ICMP unreachable message reports on 🧚

But this ambiguity isn't considered a problem for the algorithm 🫶 The assumption that a received ICMP unreachable message provides evidence that a non-congestion loss caused by the connectivity disruption was wrongly considered a congestion loss still holds, no matter which TCP segment (transmission or retransmission) the message refers to ✨

5.2. Wrapped Sequence Numbers ✨

okay so besides the mix-up about whether a received ICMP unreachable message is for the original send or one of the retransmits 🙃, there's another sneaky ambiguity with the TCP sequence numbers stuffed inside those ICMP messages. on high-bandwidth paths the sequence space can wrap around super fast 🏎️💨, so a delayed ICMP unreachable message could accidentally fit as valid input for the scheme. then the scheme might wrongly undo retransmission timer backoffs. ngl the odds are tiny, because one ICMP message would need to contain the exact sequence number of the current oldest outstanding segment (SND.UNA), AND TCP would have to be in timeout-based loss recovery at that same moment 🥹. still, two "worst case" scenarios are possible 👀.

okay first scenario, bestie: picture a steady-state TCP connection that gets disrupted at an intermediate router because of a link outage 🔌. when the RTO expires, the TCP sender enters timeout-based loss recovery and starts retransmitting the earliest segment that hasn't been acknowledged (SND.UNA). for some reason the router delays all of the corresponding ICMP unreachable messages, so the TCP sender backs off its retransmission timer normally without undoing anything. when the disruption ends, the TCP sender eventually detects the re-establishment, leaves the scheme, and finally leaves timeout-based loss recovery too 🙌. then, after a sequence number wrap-around, the connectivity between the two peers gets disrupted again, but this time it's because of congestion, and it happens exactly when the current SND.UNA matches the SND.UNA from the previous cycle 😭. if the router emits the delayed ICMP unreachable messages now, the TCP sender would incorrectly undo retransmission timer backoffs. since the TCP sequence number is 32 bits, the probability of this scenario is at most 1/2^32. given enough retransmissions in the first timeout-based loss recovery, the corresponding ICMP unreachable messages could reduce the RTO in the second recovery at most to "RTO_BASE". but once the ICMP unreachable messages run out, the standard exponential backoff gets performed again 💅. so the congestion response only gets delayed by some false retransmissions, which is honestly not the end of the world 🌸.

second scenario, and this one's giving "one more layer" 🧚: consider a steady-state TCP connection with n segments in flight that gets disrupted at some point by a link outage at an intermediate router. for each segment in flight, the router may generate an ICMP unreachable message. but for some reason, it delays them 🐢. once the link outage is over and the connection is re-established, the TCP sender leaves the scheme and slow-starts the connection. following a sequence number wrap-around, a retransmission timeout occurs, right at the moment the TCP sender's current window of data reaches the previous range of the sequence number space again 😳. if the router emits the delayed ICMP unreachable messages now, spurious undoing of the retransmission timer backoff is possible once, but only if the TCP segment number contained in the ICMP unreachable messages matches the current SND.UNA AND the timeout was a result of congestion. if there's another connectivity disruption, the additional undoing of the retransmission timer backoff has no impact at all 🫶. the probability of this scenario is at most n/2^32.

5.3. Packet Duplication 🍓

okay so if an intermediate router duplicates packets, a TCP sender might receive more ICMP unreachable messages during timeout-based loss recovery than the number of timeout-based retransmissions it actually sent 📬. but TCP-LCD keeps track of how many retransmission timer backoffs were performed in the "BACKOFF_CNT" variable, so it will not undo more retransmission timer backoffs than were actually performed. the tea, though: if packet duplication and congestion happen at the same time on the path between the two communicating hosts, the duplicated ICMP unreachable messages could hide the congestion loss of some retransmissions or ICMP unreachable messages 🫠, and the algorithm might incorrectly undo retransmission timer backoffs. still, looking at the overall impact of a router that duplicates packets, the extra load from some spurious timeout-based retransmits can probably be neglected 🤷‍♀️.

5.4. Probing Frequency 🎀

someone could argue that if an ICMP unreachable message arrives for a timeout-based retransmission, the RTO should be reset or recalculated, kind of like what happens when an ACK arrives during timeout-based loss recovery (see Karn's algorithm [KP87], [RFC2988]), and a new retransmission should be sent immediately ⚡. honestly that would mean a way higher probing frequency, based on the round-trip time to the router where the connectivity got disrupted. but we think the current scheme hits a really good balance between being conservative and detecting connectivity re-establishment fast 💜. TCP-LCD focuses on long connectivity disruptions, meaning disruptions that last for several RTOs. so a much higher probing frequency (less than once per RTO) wouldn't really increase the available transmission time compared to how long the disruption lasts 🥱.

5.5. Reaction during Connection Establishment 🌈

it's possible for a TCP sender to enter timeout-based loss recovery while the connection is in the SYN-SENT or SYN-RECEIVED states [RFC0793]. the algorithm in this document could also be used for faster connection establishment in networks with connectivity disruptions 🚀. however, existing TCP implementations [RFC5461] already interpret ICMP unreachable messages during connection establishment and abort the corresponding connection, so we're going to refrain from suggesting this 🙅‍♀️.

5.6. Reaction in Steady-State 💫

you might think it'd be a good idea to use ICMP unreachable messages for TCP congestion control while TCP is in steady-state too 🤔. the RTT up to the router that generated the ICMP unreachable message is likely to be way shorter than the overall RTT to the destination, so the ICMP message may very well reach the originating TCP while it's still transmitting the current window of data. if the remaining window is large, it might seem smart to hold off on sending the rest of it, since there's timely evidence it would only trigger more ICMP unreachable messages at that very router. this promises improvement from a wastage perspective, but it may be counterproductive from a security perspective 🚨. an attacker could forge such ICMP messages, forcing the originating TCP to stop sending data, very similar to the blind throughput-reduction attack mentioned in [RFC5927].

there's also this extra twist: with multi-path routing, even a legitimate ICMP unreachable message can't be exploited accurately 🌀. only one of the multiple paths to the destination might be suffering a connectivity disruption, which is what causes the ICMP unreachable messages to be sent. but the path where the disruption happened might have contributed a lot to the overall bandwidth, so a congestion response could be totally reasonable. this is not necessarily the case, though. so a TCP has no means except its inherent congestion control to decide on this matter 🧐. all in all, for a connection in steady-state (i.e., not in timeout-based loss recovery), reacting to ICMP unreachable messages in regard to congestion control doesn't seem appropriate 🙅‍♀️. for the case of timeout-based retransmissions, though, there's a reasonable congestion response: skipping further retransmission timer backoffs, because there's no congestion indication, as described above 🫶.

6. Dissolving Ambiguity Issues Using the TCP Timestamps Option 💖

okay this is the glow-up section 🪄. if the TCP Timestamps option [RFC1323] is enabled for a connection, a TCP sender SHOULD use the following algorithm to dissolve the ambiguity issues mentioned in Sections 5.1, 5.2, and 5.3. the retransmission ambiguity and the packet duplication problems are both prevented by the following TCP-LCD variant 🙌. the false positives caused by wrapped sequence numbers can't be completely avoided, but the likelihood gets reduced even further by a factor of 1/2^32, since the Timestamp Value field (TSval) of the TCP Timestamps option contains 32 bits 🔥.

so implementers may choose to employ TCP-LCD with the following modifications 🎀.

step (1) gets replaced by step (1'):

(1') before TCP updates the variable "RTO" when it initiates timeout-based loss recovery, set the variables "BACKOFF_CNT" and "RTO_BASE", and the data structure "RETRANS_TS", like so:

BACKOFF_CNT := 0;
RTO_BASE := RTO;

RETRANS_TS := [].

then proceed to step (R).

step (2) gets extended by step (2b):

(2b) store the value of the Timestamp Value field (TSval) of the TCP Timestamps option included in the retransmission "RET" sent in step (R) into the "RETRANS_TS" data structure:

RETRANS_TS.add(RET.TSval)

step (6) gets replaced by step (6'):

(6') if "SEG.SEQ == SND.UNA && RETRANS_TS.exists(SEQ.TSval)", i.e., if the TCP segment "SEG" eliciting the ICMP unreachable message "ICMP_DU" contains the sequence number of a retransmission, and the value in its Timestamp Value field (TSval) is valid, then proceed to step (7'). else, proceed to step (3).

step (7) gets replaced by step (7'):

(7') undo the last retransmission timer backoff:

RETRANS_TS.remove(SEQ.TSval);
BACKOFF_CNT := BACKOFF_CNT - 1;
RTO := min(RTO_BASE * 2^(BACKOFF_CNT), MAX_RTO).

⚠️ the downside of this variant is twofold, bestie. first, the modifications come at a cost: the TCP sender is required to store the timestamps of all retransmissions sent during one timeout-based loss recovery 📦. second, this variant can only undo a retransmission timer backoff if the intermediate router experiencing the link outage implements [RFC1812] and chooses to include, in addition to the first 64 bits of the payload of the triggering datagram, as many bits as are needed to include the TCP Timestamps option in the ICMP unreachable message 🥲.

7. Interoperability Issues 🧚‍♀️

okay so this section is all about the interop stuff that comes with bringing TCP-LCD into the mix 🌐. it's the part where we check how it plays with everybody else ✨.

7.1. Detection of TCP Connection Failures 💀

okay so, TCP-LCD can cause side effects for TCP implementations that try to detect connection failures by counting timeout-based retransmissions 🙈 [RFC1122] says in Section 4.2.3.5 that a TCP host has to handle excessive retransmissions of data segments with two thresholds, R1 and R2, which measure how many retransmissions have happened for the same segment. Both thresholds can be measured in time units or as a count of retransmissions.

Here's the tea: TCP-LCD reverts the retransmission timer in its own special way, so the assumption that a certain number of retransmissions matches a specific time interval no longer holds 😭 Extra retransmissions might happen during timeout-based loss recovery while it's checking whether the connectivity disruption has ended. So a TCP using TCP-LCD either MUST measure R1 and R2 in time units or, if R1 and R2 are counters of retransmissions, it MUST convert them into time intervals that match the time an unmodified TCP would need to reach that many retransmissions 💅

7.2. Explicit Congestion Notification (ECN) 🌈

With Explicit Congestion Notification (ECN) [RFC3168], ECN-capable routers aren't stuck dropping packets to signal congestion anymore ✨ They can set the Congestion Experienced (CE) codepoint in the IP header instead. With TCP-LCD, it's possible that during a connectivity disruption, a received ICMP unreachable message was triggered by a timeout-based retransmission that had already been marked with the CE codepoint before it reached the router with the link outage. In that case, a TCP sender MUST, in line with Section 6.1.2 of [RFC3168], also reset the retransmission timer if the algorithm undoes a retransmission timer backoff 🔥

7.3. TCP-LCD and IP Tunnels 🧚

It's worth noting that IP tunnels are compatible with TCP-LCD 🦋 That includes IPsec [RFC4301], IP encapsulation within IP [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], and others, as long as the TCP sender can demultiplex and properly extract the received ICMP unreachable messages during timeout-based loss recovery.

If you use end-to-end tunnels like IPsec in transport mode [RFC4301], a TCP sender might receive ICMP unreachable messages where extra steps are needed to pull out the TCP header. For example, it might also have to do decryption in step (5) of the algorithm. As long as the received ICMP unreachable message has enough info, meaning SEG.SEQ is extractable, that info can still be used as a valid input for the proposed algorithm 🎀

Same vibe if IP encapsulation like [RFC2003] is used somewhere along the path between the communicating hosts. The tunnel ingress node might receive the ICMP unreachable messages from an intermediate router that's experiencing the link outage. Even so, the tunnel ingress node can replay those ICMP unreachable messages to inform the TCP sender 🫶 If enough information is kept to extract SEG.SEQ, the replayed ICMP unreachable messages can still be used in TCP-LCD.

Lots of people have tried to fix TCP's problems when connectivity drops, and some of them tweak the lower layers 👀 For example, [SM03] introduces a "smart link layer" that buffers one segment for each active connection and replays those segments once connectivity comes back. Honestly, this has a serious drawback: previously stateless intermediate routers would have to be modified so they can inspect TCP headers, track the end-to-end connection, and provide extra buffer space. That means extra memory and processing power, which is a lot 😩

On the other hand, stateless link-layer schemes, like the ones proposed in [RFC3819], unconditionally buffer some small number of packets. These can have a different problem: if a packet is buffered for longer than the maximum segment lifetime (MSL) of 2 min. [RFC0793], meaning the disconnection lasts longer than the MSL, TCP's assumption that such segments will never be received stops being true. That violates TCP's semantics [TCP-REXMIT-NOW] 💀

Other approaches, like the TCP feedback-based scheme (TCP-F) [CRVP01] or the Explicit Link Failure Notification (ELFN) [HV02], tell a TCP sender about a disrupted path using special messages that intermediate routers generate and send. When there's a link failure, the TCP sender stops sending segments and freezes its retransmission timers. TCP-F stays in this state and stays silent until either a "route establishment notification" arrives or an internal timer expires. ELFN, on the other hand, periodically probes the network to detect when connectivity comes back 🧐 Both proposals rely on changes to intermediate routers, whereas the scheme proposed in this document is a sender-only modification 💖 Also, ELFN doesn't consider congestion and may put serious extra load on the network, depending on the probe interval.

The authors of "ad hoc TCP" (ATCP) [LS01] propose enhancements that identify different types of packet loss by adding a layer between TCP and IP 🌸 They use ICMP destination unreachable messages to set TCP's receiver advertised window to zero, which forces the TCP sender to do zero window probing with an exponential backoff. ICMP destination unreachable messages that arrive during this probing period are ignored. This approach is nearly orthogonal to this document, which uses ICMP messages to undo a retransmission timer backoff while TCP is already probing. In principle, both mechanisms could be combined. However, because of security considerations, it doesn't seem appropriate to adopt ATCP's reaction, as discussed in Section 5.6 🙈

Schuetz et al. [TCP-RLCI] describe a set of TCP extensions that improve TCP's behavior when transmitting over paths whose characteristics can change rapidly ⭐ Their extensions modify the local behavior of TCP and add a new TCP option to signal locally received connectivity-change indications (CCIs) to remote peers. When a CCI arrives, they re-probe the path characteristics, either by doing a speculative retransmission or by sending a single segment of new data, depending on whether the connection is stalled in exponential backoff or transmitting in steady-state. The authors focus on specifying TCP response mechanisms, but underlying layers would still have to be modified to explicitly send CCIs so these immediate responses can happen 🧚

9. Security Considerations 🔒

Generally, an attacker has only two options: generate ICMP unreachable messages to try to make a TCP modified with TCP-LCD flood the network, or suppress legitimate ICMP unreachable messages to try to slow down the transmission rate of a TCP sender 😤

To generate ICMP unreachable messages that fit as an input for TCP-LCD, an attacker would need to guess the correct four-tuple (i.e., Source IP Address, Source TCP port, Destination IP Address, and Destination TCP port) and the exact segment sequence number of the current timeout-based retransmission. The correct sequence number is generally hard to guess, given the probability of 1/2^32. Even if an attacker knows that sequence number (i.e., the attacker can eavesdrop on the retransmissions), the impact on network load may be considered low, since the retransmission frequency is limited by the RTO that was computed before TCP entered the timeout-based loss recovery. So the highest probing frequency is expected to be even lower than once per minimum RTO, i.e., 1 s as specified by [RFC2988] 🕰️

It's really important to note that an attacker who can correctly guess the four-tuple and the segment sequence number can easily launch more serious attacks (i.e., hijack the connection), whether or not TCP-LCD is used. This is not a TCP-LCD-only problem, babe 💀

There may be ways an attacker can cause legitimate ICMP unreachable messages to be suppressed (e.g., by flooding the router experiencing the link outage to trigger ICMP rate-limiting). However, even if the attacker could suppress every legitimate ICMP unreachable message, the security impact of that attack is negligible, since the TCP sender using TCP-LCD will behave like a regular TCP would. Note that this kind of attack is indistinguishable from a router experiencing a link outage that isn't sending ICMP unreachable messages at all (e.g., because of local policy) 🙃

In summary, the algorithm proposed in this document is considered to be secure ✨👑

10. Acknowledgments 🫶

We would like to thank Lars Eggert, Adrian Farrel, Mark Handley, Kai Jakobs, Ilpo Jarvinen, Enrico Marocco, Catherine Meadows, Juergen Quittek, Pasi Sarolahti, Tim Shepard, Joe Touch, and Carsten Wolff for feedback on earlier versions of this document 💖 We also thank Michael Faber, Daniel Schaffrath, and Damian Lukowski for implementing and testing the algorithm in Linux 🐧 Special thanks go to Ilpo Jarvinen for giving valuable feedback regarding the Linux implementation 🙌

This work has been supported by the German National Science Foundation (DFG) within the research excellence cluster Ultra High-Speed Mobile Information and Communication (UMIC), RWTH Aachen University 🌟

11. References 📖

11.1. Normative References

[RFC0792]   Postel, J., "Internet Control Message Protocol", STD 5,
               RFC 792, September 1981.

[RFC0793]   Postel, J., "Transmission Control Protocol", STD 7,
               RFC 793, September 1981.

[RFC1323]   Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
               for High Performance", RFC 1323, May 1992.

[RFC1812]   Baker, F., "Requirements for IP Version 4 Routers",
               RFC 1812, June 1995.

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2988]   Paxson, V. and M. Allman, "Computing TCP's Retransmission
               Timer", RFC 2988, November 2000.

[RFC4443]   Conta, A., Deering, S., and M. Gupta, "Internet Control
               Message Protocol (ICMPv6) for the Internet Protocol
               Version 6 (IPv6) Specification", RFC 4443, March 2006.

[RFC5681]   Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
               Control", RFC 5681, September 2009.

11.2. Informative References ✨

okay bestie, this is the reading list for all the extra background stuff 📚🫶 these aren't required to implement the spec, but they're where the juicy research lives 💅

[CRVP01]    Chandran, K., Raghunathan, S., Venkatesan, S., and R.
            Prakash, "A feedback-based scheme for improving TCP
            performance in ad hoc wireless networks", IEEE Personal
            Communications vol. 8, no. 1, pp. 34-39, February 2001.

[HV02]      Holland, G. and N. Vaidya, "Analysis of TCP performance
            over mobile ad hoc networks", Wireless Networks vol. 8,
            no. 2-3, pp. 275-288, March 2002.

[KP87]      Karn, P. and C. Partridge, "Improving Round-Trip Time
            Estimates in Reliable Transport Protocols", Proceedings
            of the Conference on Applications, Technologies,
            Architectures, and Protocols for Computer Communication
            (SIGCOMM'87) pp. 2-7, August 1987.

[LS01]      Liu, J. and S. Singh, "ATCP: TCP for mobile ad hoc
            networks", IEEE Journal on Selected Areas in
            Communications vol. 19, no. 7, pp. 1300-1315, July 2001.

[RFC0791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
            September 1981.

[RFC0826]   Plummer, D., "Ethernet Address Resolution Protocol: Or
            converting network protocol addresses to 48.bit Ethernet
            address for transmission on Ethernet hardware", STD 37,
            RFC 826, November 1982.

[RFC1122]   Braden, R., "Requirements for Internet Hosts -
            Communication Layers", STD 3, RFC 1122, October 1989.

[RFC2003]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
            October 1996.

[RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.

[RFC2784]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
            Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
            March 2000.

[RFC3168]   Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
            of Explicit Congestion Notification (ECN) to IP",
            RFC 3168, September 2001.

[RFC3522]   Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
            for TCP", RFC 3522, April 2003.

[RFC3782]   Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
            Modification to TCP's Fast Recovery Algorithm", RFC 3782,
            April 2004.

[RFC3819]   Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
            Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
            L.  Wood, "Advice for Internet Subnetwork Designers",
            BCP 89, RFC 3819, July 2004.

[RFC4015]   Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
            for TCP", RFC 4015, February 2005.

[RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
            Internet Protocol", RFC 4301, December 2005.

[RFC5461]   Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
            February 2009.

[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,
            September 2009.

[RFC5927]   Gont, F., "ICMP Attacks against TCP", RFC 5927,
            July 2010.

[SESB05]    Schuetz, S., Eggert, L., Schmid, S., and M. Brunner,
            "Protocol enhancements for intermittently connected
            hosts", SIGCOMM Computer Communication Review vol. 35,
            no. 3, pp. 5-18, December 2005.

[SM03]      Scott, J. and G. Mapp, "Link layer-based TCP optimisation
            for disconnecting networks", SIGCOMM Computer
            Communication Review vol. 33, no. 5, pp. 31-42,
            October 2003.

[TCP-REXMIT-NOW]
            Eggert, L., Schuetz, S., and S. Schmid, "TCP Extensions
            for Immediate Retransmissions", Work in Progress,
            June 2005.

[TCP-RLCI]
            Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami,
            Y., and K. Le, "TCP Response to Lower-Layer Connectivity-
            Change Indications", Work in Progress, February 2008.

[Zh86]      Zhang, L., "Why TCP Timers Don't Work Well", Proceedings
            of the Conference on Applications, Technologies,
            Architectures, and Protocols for Computer Communication
            (SIGCOMM'86) pp. 397-405, August 1986.

[ZimHan09]
            Zimmermann, A., "Make TCP more Robust to Long
            Connectivity Disruptions", Proceedings of the 75th IETF
            Meeting slides, July 2009,
            <http://www.ietf.org/proceedings/75/slides/tcpm-0.pdf>.

Authors' Addresses 🌸

these are the people who wrote it, so you know exactly who to thank (or bug 🙈)

Alexander Zimmermann
RWTH Aachen University
Ahornstrasse 55
Aachen,   52074
Germany

Phone: +49 241 80 21422
EMail: zimmermann@cs.rwth-aachen.de


Arnd Hannemann
RWTH Aachen University
Ahornstrasse 55
Aachen,   52074
Germany

Phone: +49 241 80 21423
EMail: hannemann@nets.rwth-aachen.de

📦 where this page comes from

ietf: rfc6069 2010-12
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 6069

Title Block 🎀

Abstract 💖

Status of This Memo 📝

Copyright Notice ©️

Table of Contents 🗂️

1. Introduction 🌈

2. Terminology 📚

4. Connectivity Disruption Reaction ⭐

4.1. Basic Idea 💡

5.2. Wrapped Sequence Numbers ✨

5.3. Packet Duplication 🍓

5.4. Probing Frequency 🎀

5.5. Reaction during Connection Establishment 🌈

5.6. Reaction in Steady-State 💫

6. Dissolving Ambiguity Issues Using the TCP Timestamps Option 💖

7. Interoperability Issues 🧚‍♀️

7.1. Detection of TCP Connection Failures 💀

7.2. Explicit Congestion Notification (ECN) 🌈

7.3. TCP-LCD and IP Tunnels 🧚

8. Related Work 📚

9. Security Considerations 🔒

10. Acknowledgments 🫶

11. References 📖

11.1. Normative References

11.2. Informative References ✨

Authors' Addresses 🌸