diff options
Diffstat (limited to 'doc/rfc/rfc6069.txt')
| -rw-r--r-- | doc/rfc/rfc6069.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc6069.txt b/doc/rfc/rfc6069.txt new file mode 100644 index 0000000..263f4f8 --- /dev/null +++ b/doc/rfc/rfc6069.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Zimmermann +Request for Comments: 6069 A. Hannemann +Category: Experimental RWTH Aachen University +ISSN: 2070-1721 December 2010 + + + Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) + +Abstract + + Disruptions in end-to-end path connectivity, which last longer than + one retransmission timeout, cause suboptimal TCP performance. The + reason for this performance degradation is that TCP interprets + segment loss induced by long connectivity disruptions as a sign of + congestion, resulting in repeated retransmission timer backoffs. + This, in turn, leads to a delayed detection of the re-establishment + of the connection since TCP waits for the next retransmission timeout + before it attempts a retransmission. + + This document proposes an algorithm to make TCP more robust to long + connectivity disruptions (TCP-LCD). It describes how standard ICMP + messages can be exploited during timeout-based loss recovery to + disambiguate true congestion loss from non-congestion loss caused by + connectivity disruptions. Moreover, a reversion strategy of the + retransmission timer is specified that enables a more prompt + detection of whether or not the connectivity to a previously + disconnected peer node has been restored. TCP-LCD is a TCP sender- + only modification that effectively improves TCP performance in the + case of connectivity disruptions. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. 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). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6069. + + + + +Zimmermann & Hannemann Experimental [Page 1] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + +Copyright Notice + + Copyright (c) 2010 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 + (http://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 ....................................................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 + + + + + + + + + + +Zimmermann & Hannemann Experimental [Page 2] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + +1. Introduction + + Connectivity disruptions can occur in many different situations. The + frequency of connectivity disruptions depends on the properties of + the end-to-end path between the communicating hosts. While + connectivity disruptions can occur in traditional wired networks, + e.g., disruption caused by an unplugged network cable, the likelihood + of their occurrence is significantly higher in wireless (multi-hop) + networks. Especially, end-host mobility, network topology changes, + and wireless interferences are crucial factors. In the case of the + Transmission Control Protocol (TCP) [RFC0793], the performance of the + connection can experience a significant reduction compared to a + permanently connected path [SESB05]. This is because TCP, which was + originally designed to operate in fixed and wired networks, generally + assumes that the end-to-end path connectivity is relatively stable + over the connection's lifetime. + + Depending on their duration, connectivity disruptions can be + classified into two groups [TCP-RLCI]: "short" and "long". A + connectivity disruption is "short" if connectivity returns before the + retransmission timer fires for the first time. In this case, TCP + recovers lost data segments through Fast Retransmit and lost + acknowledgments (ACKs) through successfully delivered later ACKs. + Connectivity disruptions are declared as "long" for a given TCP + connection if the retransmission timer fires at least once before + connectivity is resumed. Whether or not 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 specified in this document improves TCP's behavior in + the case of "long connectivity disruptions". In particular, it + focuses on the period prior to the re-establishment of the + connectivity to a previously disconnected peer node. The document + does not describe any modifications to TCP's behavior and its + congestion control mechanisms [RFC5681] after connectivity has been + restored. + + When a long connectivity disruption occurs on a TCP connection, the + TCP sender eventually does not receive any more acknowledgments. + After the retransmission timer expires, the TCP sender enters the + timeout-based loss recovery and declares the oldest outstanding + segment (SND.UNA) as lost. Since TCP tightly couples reliability and + congestion control, the retransmission of SND.UNA is triggered + together with the reduction of the transmission rate. This is based + on the assumption that segment loss is an indication of congestion + [RFC5681]. As long as the connectivity disruption persists, TCP will + repeat this procedure until the oldest outstanding segment has + + + +Zimmermann & Hannemann Experimental [Page 3] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + successfully been acknowledged or until the connection has timed 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 + until the retransmission timer expires before resuming transmission, + since it simply does not have any means to know if the connectivity + has been re-established. Therefore, depending on when connectivity + becomes available again, this can waste up to a maximum RTO of + possible transmission time. + + This retransmission behavior is not 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. In this document, we specify a TCP sender- + only modification to provide robustness to long connectivity + disruptions (TCP-LCD). The memo 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 of the + retransmission timer enables higher-frequency retransmissions and + thereby a prompt detection when connectivity to a previously + disconnected peer node has been restored. If no congestion is + present, TCP-LCD approaches 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 is already used within the Internet. Thus + far, no negative experiences have been reported that could be + attributed to the algorithm. However, we consider TCP-LCD as + experimental until more real-life results have been obtained. + Nevertheless, we encourage implementation of TCP-LCD under other + operating systems to provide for broader testing and experimentation + opportunities. + +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]. + + The reader should be familiar with the algorithm and terminology from + [RFC2988], which 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 + + + +Zimmermann & Hannemann Experimental [Page 4] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + defined in [RFC2988]. The retransmission timer ensures data delivery + in the absence of any feedback from the receiver. The duration of + this timer is referred to as retransmission timeout (RTO). + + As defined in [RFC0793], the term "acceptable acknowledgment (ACK)" + refers to 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 has + not been acknowledged by the TCP receiver (the oldest outstanding + segment). SEG.SEQ is the segment sequence number of a given segment. + + For the purposes of this specification, we define the term "timeout- + based loss recovery", which refers to the state that a TCP sender + enters upon the first timeout of the oldest outstanding segment + (SND.UNA) and leaves upon the arrival of the *first* acceptable ACK. + It is important to note that other documents use a different + interpretation of the term "timeout-based loss recovery". For + example, the NewReno modification to TCP's Fast Recovery algorithm + [RFC3782] extends the period that a TCP sender remains in timeout- + based loss recovery compared to the one defined in this document. + This is because [RFC3782] attempts to avoid unnecessary multiple Fast + Retransmits that can occur after an RTO. + +3. Connectivity Disruption Indication + + If the queue of an intermediate router that is experiencing a link + outage can buffer all incoming packets, a connectivity disruption + will only cause a variation in delay, which is handled well by TCP + implementations using either Eifel [RFC3522], [RFC4015] or Forward + RTO-Recovery (F-RTO) [RFC5682]. However, if the link outage lasts + for too long, the router experiencing the link outage is forced to + drop packets, and finally may remove the corresponding next hop from + its routing table. Means to detect such link outages include + reacting to failed address resolution protocol (ARP) [RFC0826] + queries, sensing unsuccessful links, and the like. However, this is + solely the responsibility of the respective router. + + Note: The focus of this memo is on introducing a method of how + ICMP messages may be exploited to improve TCP's performance; how + different physical and link-layer mechanisms below the network + layer may trigger ICMP destination unreachable messages are out of + scope of this memo. + + Provided that no other route to the specific destination exists, an + Internet Protocol version 4 (IPv4) [RFC0791] router will notify the + corresponding sending host about the dropped packets via ICMP + destination unreachable messages of code 0 (net unreachable) or + + + +Zimmermann & Hannemann Experimental [Page 5] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + code 1 (host unreachable) [RFC1812]. Therefore, the sending host can + use the ICMP destination unreachable messages of these codes as an + indication of a connectivity disruption, since the reception of these + messages provides evidence that packets were dropped due to a link + outage. + + For Internet Protocol version 6 (IPv6) [RFC2460], the counterpart of + the ICMP destination unreachable message of code 0 (net unreachable) + and of code 1 (host unreachable) is the ICMPv6 destination + unreachable message of code 0 (no route to destination) [RFC4443]. + As with IPv4, a router should generate an ICMPv6 destination + unreachable message of code 0 in response to a packet that cannot be + delivered to its destination address because it lacks a matching + entry in its routing table. + + Note that there are also other ICMP and ICMPv6 destination + unreachable messages with different codes. Some of them are + candidates for connectivity disruption indications, too, but need + further 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 of no + use for this scheme, since TCP should abort the connection when those + are received [RFC1122]. + + For the sake of simplicity, we will use, unless explicitly qualified + with ICMPv4 or ICMPv6, the term "ICMP unreachable message" as a + synonym for ICMP destination unreachable messages of code 0 or code 1 + and ICMPv6 destination unreachable messages of code 0. This implies + that all keywords from [RFC2119] that deal with the handling of + received ICMP messages apply in the same way to ICMPv6 messages. + + The accurate interpretation of ICMP unreachable messages as a + connectivity disruption indication is complicated by the following + two peculiarities of ICMP messages. First, they do not necessarily + operate on the same timescale as the packets, i.e., TCP segments that + elicited them. When a router drops a packet due to a missing route, + it will not necessarily send an ICMP unreachable message immediately, + but will rather queue it for later delivery. Second, ICMP messages + are subject to rate-limiting, e.g., when a router drops a whole + window of data due to a link outage, it is unlikely to send as many + ICMP unreachable messages as dropped TCP segments. Depending on the + load of the router, it may not even send any ICMP unreachable + messages at all. Both peculiarities originate from [RFC1812] for + ICMPv4 and [RFC4443] for ICMPv6. + + + + + + +Zimmermann & Hannemann Experimental [Page 6] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + Fortunately, according to [RFC0792], ICMPv4 unreachable messages have + to contain, in their body, the entire IPv4 header [RFC0791] of the + datagram eliciting the ICMPv4 unreachable message, plus the first + 64 bits of the payload of that datagram. This allows the sending + host to match the ICMPv4 error message to the transport connection + that elicited it. RFC 1812 [RFC1812] augments these requirements and + states that ICMPv4 messages should contain as much of the original + datagram as possible without the length of the ICMPv4 datagram + exceeding 576 bytes. Therefore, in the case of TCP, at least the + source port number, the destination port number, and the 32-bit TCP + sequence number are included. This allows the originating TCP to + demultiplex the received ICMPv4 message and to identify the affected + connection. Moreover, it can identify which segment of the + respective connection triggered the ICMPv4 unreachable message, + unless there are several segments in flight with 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 + elicited the ICMPv6 error message, without making the error message + exceed the minimum IPv6 MTU (1280 bytes) [RFC4443]. Thus, enough + information is available to identify both the affected connection and + the corresponding segment that triggered the ICMPv6 error message. + + A connectivity disruption indication in the form of an ICMP + unreachable message associated with a presumably lost TCP segment + provides strong evidence that the segment was not dropped due to + congestion, but was successfully delivered as far as the reporting + router. It therefore did not witness any congestion at least on that + part of the path that was traversed by both the TCP segment eliciting + the ICMP unreachable message and the ICMP unreachable message itself. + +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 been restored after a long + connectivity disruption, while retaining appropriate behavior in case + of congestion. TCP-LCD exploits standard ICMP unreachable messages + during timeout-based loss recovery. This increases TCP's + retransmission frequency by undoing one retransmission timer backoff + whenever an ICMP unreachable message is received that contains a + segment with a sequence number of a presumably lost retransmission. + + + + +Zimmermann & Hannemann Experimental [Page 7] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + This approach has the advantage of appropriately reducing the probing + rate in case of congestion. If either the retransmission itself or + the corresponding ICMP message is dropped, the previously performed + retransmission timer backoff is not undone, which effectively halves + the probing rate. + +4.2. Algorithm Details + + A TCP sender that uses RFC 2988 [RFC2988] to compute TCP's + retransmission timer MAY employ the following scheme to avoid over- + conservative retransmission timer backoffs in case of long + connectivity disruptions. If a TCP sender does implement the + following steps, the algorithm MUST be initiated upon the first + timeout of the oldest outstanding segment (SND.UNA) and MUST be + stopped upon the arrival of the first acceptable ACK. The algorithm + MUST NOT be re-initiated upon subsequent timeouts for the same + segment. The scheme SHOULD NOT be used in SYN-SENT or SYN-RECEIVED + states [RFC0793] (see Section 5.5). + + A TCP sender that does not employ RFC 2988 [RFC2988] to compute TCP's + retransmission timer MUST NOT use TCP-LCD. We envision that the + scheme could be easily adapted to algorithms other than RFC 2988. + However, we leave this as future work. + + RFC 2988 [RFC2988] provides in rule (2.5) the option to place a + maximum value on the RTO. When a TCP implements this rule to provide + an upper bound for the RTO, it MUST also be used in the following + algorithm. In particular, if the RTO is bounded by an upper limit + (maximum RTO), the "MAX_RTO" variable used in this scheme MUST be + initialized with this upper limit. Otherwise, if the RTO is + unbounded, the "MAX_RTO" variable MUST be set to infinity. + + The scheme specified in this document uses the "BACKOFF_CNT" + variable, whose initial value is zero. The variable is used to count + the number of performed retransmission timer backoffs during one + timeout-based loss recovery. Moreover, the "RTO_BASE" variable is + used to recover the previous RTO if the retransmission timer backoff + was unnecessary. The variable is initialized with the RTO upon + initiation of timeout-based loss recovery. + + (1) Before TCP updates the variable "RTO" when it initiates timeout- + based loss recovery, set the variables "BACKOFF_CNT" and + "RTO_BASE" as follows: + + BACKOFF_CNT := 0; + RTO_BASE := RTO. + + Proceed to step (R). + + + +Zimmermann & Hannemann Experimental [Page 8] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + (R) This is a placeholder for standard TCP's behavior in case the + retransmission timer has expired. In particular, if RFC 2988 + [RFC2988] is used, steps (5.4) to (5.6) of that algorithm go + here. Proceed to step (2). + + (2) To account for the expiration of the retransmission timer in the + previous step (R), increment the "BACKOFF_CNT" variable by one: + + BACKOFF_CNT := BACKOFF_CNT + 1. + + (3) Wait either + + a) for the expiration of the retransmission timer. When the + retransmission timer expires, proceed to step (R); or + + b) for the arrival of an acceptable ACK. When an acceptable + ACK arrives, proceed to step (A); or + + c) for the arrival of an ICMP unreachable message. 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" + eliciting the ICMP unreachable message "ICMP_DU" contains the + sequence number of a retransmission, then + + proceed to step (7); + + else + + proceed to step (3). + + + + + + +Zimmermann & Hannemann Experimental [Page 9] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + (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 due to the undoing 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 in case an + acceptable ACK has arrived. No further processing. + + When a TCP in steady-state detects a segment loss using the + retransmission timer, it enters the timeout-based loss recovery and + initiates 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 expiration of the retransmission timer, the TCP + sender increments the "BACKOFF_CNT" variable by one (step (2)). + + In case the retransmission timer expires again (step (3a)), a TCP + will repeat the retransmission of the first unacknowledged segment + and back off the retransmission timer once more (step (R)) [RFC2988], + as well as increment the "BACKOFF_CNT" variable by one (step (2)). + Note that a TCP may implement RFC 2988's [RFC2988] option to place a + maximum value on the RTO that may result in not performing the + retransmission timer backoff. However, step (2) MUST always and + unconditionally be applied, no matter whether or not the + retransmission timer is actually backed off. In other words, each + time the retransmission timer expires, the "BACKOFF_CNT" variable + MUST be incremented by one. + + If the first received packet after the retransmission(s) is an + acceptable ACK (step (3b)), a TCP will proceed as normal, i.e., slow- + start the connection and terminate the algorithm (step (A)). Later + ICMP unreachable messages from the just terminated timeout-based loss + recovery are ignored, since the ACK clock is already restarting due + to the successful retransmission. + + On the other hand, if the first received packet after the + retransmission(s) is an ICMP unreachable message (step (3c)), and if + step (4) permits it, TCP SHOULD undo one backoff for each ICMP + + + +Zimmermann & Hannemann Experimental [Page 10] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + unreachable message reporting an error on a retransmission. To + decide if an ICMP unreachable message was elicited by a + retransmission, the sequence number it contains is inspected + (step (5), step (6)). The undo is performed by recalculating the RTO + with the decremented "BACKOFF_CNT" variable (step (7)). This + calculation explicitly matches the (bounded) exponential backoff + specified in rule (5.5) of [RFC2988]. + + Upon receipt of an ICMP unreachable message that legitimately undoes + one backoff, there is the possibility that the shortened + retransmission timer has already expired (step (8)). Then, TCP + SHOULD retransmit immediately. In case the shortened retransmission + timer has not yet expired, TCP MUST wait accordingly. + +5. Discussion of TCP-LCD + + TCP-LCD takes caution to only react to connectivity disruption + indications in the form of ICMP unreachable messages during timeout- + based loss recovery. Therefore, TCP's behavior is not altered when + either no ICMP unreachable messages are received or the + retransmission timer of the TCP sender did not expire since the last + received acceptable ACK. Thus, by definition, the algorithm triggers + only in the case of long connectivity disruptions. + + Only such ICMP unreachable messages that contain a TCP segment with + the sequence number of a retransmission, i.e., that contain SND.UNA, + are evaluated by TCP-LCD. All other ICMP unreachable messages are + ignored. The arrival of those ICMP unreachable messages provides + strong evidence that the retransmissions were not dropped due to + congestion, but were successfully delivered to the reporting router. + In other words, there is no evidence for any congestion at least on + that very part of the path that was traversed by both the TCP segment + eliciting the ICMP unreachable message and the ICMP unreachable + message itself. + + However, there are some situations where TCP-LCD makes a false + decision and incorrectly undoes a retransmission timer backoff. This + can happen, even when the received ICMP unreachable message contains + the segment number of a retransmission (SND.UNA), because the TCP + segment that elicited the ICMP unreachable message may either not be + a retransmission (Section 5.1) or does 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 discusses possible probing frequencies, while Section 5.6 + describes the motivation for not reacting to ICMP unreachable + messages while TCP is in steady-state. + + + + +Zimmermann & Hannemann Experimental [Page 11] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + +5.1. Retransmission Ambiguity + + Historically, the retransmission ambiguity problem [Zh86], [KP87] is + the TCP sender's inability to distinguish whether the first + acceptable ACK after a retransmission refers to the original + transmission or to the retransmission. This problem occurs after + both a Fast Retransmit and a timeout-based retransmit. However, + modern TCP implementations can eliminate the retransmission ambiguity + with either the help of Eifel [RFC3522], [RFC4015] or Forward RTO- + Recovery (F-RTO) [RFC5682]. + + The reversion strategy of the given algorithm suffers from a form of + retransmission ambiguity, too. In contrast to the above case, TCP + suffers from ambiguity regarding ICMP unreachable messages received + during timeout-based loss recovery. With the TCP segment number + included in the ICMP unreachable message, a TCP sender is not able to + determine if the ICMP unreachable message refers to the original + transmission or to any of the timeout-based retransmissions. That + is, there is an ambiguity with regard to which TCP segment an ICMP + unreachable message reports on. + + However, this ambiguity is not considered to be 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, regardless of to which TCP segment (transmission or + retransmission) the message refers. + +5.2. Wrapped Sequence Numbers + + Besides the ambiguity whether a received ICMP unreachable message + refers to the original transmission or to any of the retransmissions, + there is another source of ambiguity related to the TCP sequence + numbers contained in ICMP unreachable messages. For high-bandwidth + paths, the sequence space may wrap quickly. This might cause delayed + ICMP unreachable messages to coincidentally fit as valid input in the + proposed scheme. As a result, the scheme may incorrectly undo + retransmission timer backoffs. The chances of this happening are + minuscule, since a particular ICMP unreachable message would need to + contain the exact sequence number of the current oldest outstanding + segment (SND.UNA), while at the same time TCP is in timeout-based + loss recovery. However, two "worst case" scenarios for the algorithm + are possible. + + For instance, consider a steady-state TCP connection, which will be + disrupted at an intermediate router due to a link outage. Upon the + expiration of the RTO, the TCP sender enters the timeout-based loss + recovery and starts to retransmit the earliest segment that has not + + + +Zimmermann & Hannemann Experimental [Page 12] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + been acknowledged (SND.UNA). For some reason, the router delays all + corresponding ICMP unreachable messages so that the TCP sender backs + the retransmission timer off normally without any undoing. At the + end of the connectivity disruption, the TCP sender eventually detects + the re-establishment, and it leaves the scheme and finally the + timeout-based loss recovery, too. A sequence number wrap-around + later, the connectivity between the two peers is disrupted again, but + this time due to congestion and exactly at the time at which 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. As the + TCP sequence number contains 32 bits, the probability of this + scenario is at most 1/2^32. Given sufficiently many 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". However, once the ICMP unreachable messages are + depleted, the standard exponential backoff will be performed. Thus, + the congestion response will only be delayed by some false + retransmissions. + + Similar to the above, consider the case where a steady-state TCP + connection with n segments in flight will be disrupted at some point + due to a link outage at an intermediate router. For each segment in + flight, the router may generate an ICMP unreachable message. + However, for some reason, it delays them. Once the link outage is + over and the connection has been re-established, the TCP sender + leaves the scheme and slow-starts the connection. Following a + sequence number wrap-around, a retransmission timeout occurs, just at + the moment the TCP sender's current window of data reaches the + previous range of the sequence number space again. In case the + router emits the delayed ICMP unreachable messages now, spurious + undoing of the retransmission timer backoff is possible once, if the + TCP segment number contained in the ICMP unreachable messages matches + the current SND.UNA, and the timeout was a result of congestion. In + the case of another connectivity disruption, the additional undoing + of the retransmission timer backoff has no impact. The probability + of this scenario is at most n/2^32. + +5.3. Packet Duplication + + In case an intermediate router duplicates packets, a TCP sender may + receive more ICMP unreachable messages during timeout-based loss + recovery than sent timeout-based retransmissions. However, since + TCP-LCD keeps track of the number of performed retransmission timer + backoffs in the "BACKOFF_CNT" variable, it will not undo more + retransmission timer backoffs than were actually performed. + Nevertheless, if packet duplication and congestion coincide on the + path between the two communicating hosts, duplicated ICMP unreachable + + + +Zimmermann & Hannemann Experimental [Page 13] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + messages could hide the congestion loss of some retransmissions or + ICMP unreachable messages, and the algorithm may incorrectly undo + retransmission timer backoffs. Considering the overall impact of a + router that duplicates packets, the additional load induced by some + spurious timeout-based retransmits can probably be neglected. + +5.4. Probing Frequency + + One might argue that if an ICMP unreachable message arrives for a + timeout-based retransmission, the RTO shall be reset or recalculated, + similar to what is done when an ACK arrives during timeout-based loss + recovery (see Karn's algorithm [KP87], [RFC2988]), and a new + retransmission should be sent immediately. Generally, this would + result in a much higher probing frequency based on the round-trip + time to the router where connectivity has been disrupted. However, + we believe the current scheme provides a good trade-off between + conservative behavior and fast detection of connectivity + re-establishment. TCP-LCD focuses on long-connectivity disruptions, + i.e., on disruptions that last for several RTOs. Thus, a much higher + probing frequency (less than once per RTO) would not significantly + increase the available transmission time compared to the duration of + the connectivity disruption. + +5.5. Reaction during Connection Establishment + + It is possible that a TCP sender enters timeout-based loss recovery + while the connection is in SYN-SENT or SYN-RECEIVED states [RFC0793]. + The algorithm described in this document could also be used for + faster connection establishment in networks with connectivity + disruptions. However, because existing TCP implementations [RFC5461] + already interpret ICMP unreachable messages during connection + establishment and abort the corresponding connection, we refrain from + suggesting this. + +5.6. Reaction in Steady-State + + Another exploitation of ICMP unreachable messages in the context of + TCP congestion control might seem appropriate, while TCP is in + steady-state. As the RTT up to the router that generated the ICMP + unreachable message is likely to be substantially shorter than the + overall RTT to the destination, the ICMP unreachable message may very + well reach the originating TCP while it is transmitting the current + window of data. In case the remaining window is large, it might seem + appropriate to refrain from transmitting the remaining window as + there is timely evidence that it will only trigger further ICMP + unreachable messages at that very router. Although this promises + improvement from a wastage perspective, it may be counterproductive + from a security perspective. An attacker could forge such ICMP + + + +Zimmermann & Hannemann Experimental [Page 14] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + messages, thereby forcing the originating TCP to stop sending data, + very similar to the blind throughput-reduction attack mentioned in + [RFC5927]. + + An additional consideration is the following: in the presence of + multi-path routing, even the receipt of a legitimate ICMP unreachable + message cannot be exploited accurately, because there is the + possibility that only one of the multiple paths to the destination is + suffering from a connectivity disruption, which causes ICMP + unreachable messages to be sent. Then, however, there is the + possibility that the path along which the connectivity disruption + occurred contributed considerably to the overall bandwidth, such that + a congestion response is very well reasonable. However, this is not + necessarily the case. Therefore, a TCP has no means except for its + inherent congestion control to decide on this matter. All in all, it + seems that for a connection in steady-state, i.e., not in timeout- + based loss recovery, reacting to ICMP unreachable messages in regard + to congestion control is not appropriate. For the case of timeout- + based retransmissions, however, there is a reasonable congestion + response, which is skipping further retransmission timer backoffs + because there is no congestion indication -- as described above. + +6. Dissolving Ambiguity Issues Using the TCP Timestamps Option + + 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. In + particular, both the retransmission ambiguity and the packet + duplication problems are prevented by the following TCP-LCD variant. + On the other hand, the false positives caused by wrapped sequence + numbers cannot be completely avoided, but the likelihood is further + reduced by a factor of 1/2^32, since the Timestamp Value field + (TSval) of the TCP Timestamps option contains 32 bits. + + Hence, implementers may choose to employ the TCP-LCD with the + following modifications. + + Step (1) is 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", as + follows: + + BACKOFF_CNT := 0; + RTO_BASE := RTO; + + RETRANS_TS := []. + + + +Zimmermann & Hannemann Experimental [Page 15] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + Proceed to step (R). + + Step (2) is 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) is 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) is 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. 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. + + + + + + + + + + + + +Zimmermann & Hannemann Experimental [Page 16] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + +7. Interoperability Issues + + This section discusses interoperability issues related to introducing + TCP-LCD. + +7.1. Detection of TCP Connection Failures + + TCP-LCD may produce side effects for TCP implementations that attempt + to detect TCP connection failures by counting timeout-based + retransmissions. [RFC1122] states in Section 4.2.3.5 that a TCP host + must handle excessive retransmissions of data segments with two + thresholds, R1 and R2, that measure the number of retransmissions + that have occurred for the same segment. Both thresholds might be + measured either in time units or as a count of retransmissions. + + Due to TCP-LCD's reversion strategy of the retransmission timer, the + assumption that a certain number of retransmissions corresponds to a + specific time interval no longer holds, as additional retransmissions + may be performed during timeout-based-loss recovery to detect the end + of the connectivity disruption. Therefore, a TCP employing TCP-LCD + either MUST measure the thresholds R1 and R2 in time units or, in + case R1 and R2 are counters of retransmissions, MUST convert them + into time intervals that correspond to the time an unmodified TCP + would need to reach the specified number of retransmissions. + +7.2. Explicit Congestion Notification (ECN) + + With Explicit Congestion Notification (ECN) [RFC3168], ECN-capable + routers are no longer limited to dropping packets to indicate + congestion. Instead, they can set the Congestion Experienced (CE) + codepoint in the IP header to indicate congestion. With TCP-LCD, it + may happen that during a connectivity disruption, a received ICMP + unreachable message has been elicited by a timeout-based + retransmission that was marked with the CE codepoint before reaching + the router experiencing the link outage. In such a case, a TCP + sender MUST, corresponding to Section 6.1.2 of [RFC3168], + additionally reset the retransmission timer in case the algorithm + undoes a retransmission timer backoff. + +7.3. TCP-LCD and IP Tunnels + + It is worth noting that IP tunnels, including IPsec [RFC4301], IP + encapsulation within IP [RFC2003], Generic Routing Encapsulation + (GRE) [RFC2784], and others, are compatible with TCP-LCD, as long as + the received ICMP unreachable messages can be demultiplexed and + extracted appropriately by the TCP sender during timeout-based loss + recovery. + + + + +Zimmermann & Hannemann Experimental [Page 17] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + If, for example, end-to-end tunnels like IPsec in transport mode + [RFC4301] are employed, a TCP sender may receive ICMP unreachable + messages where additional steps, e.g., also performing decryption in + step (5) of the algorithm, are needed to extract the TCP header from + these ICMP messages. Provided that the received ICMP unreachable + message contains enough information, i.e., SEG.SEQ is extractable, + this information can still be used as a valid input for the proposed + algorithm. + + Likewise, if IP encapsulation like [RFC2003] is used in some part of + the path between the communicating hosts, the tunnel ingress node may + receive the ICMP unreachable messages from an intermediate router + experiencing the link outage. Nevertheless, the tunnel ingress node + may replay the ICMP unreachable messages in order to inform the TCP + sender. If enough information is preserved to extract SEG.SEQ, the + replayed ICMP unreachable messages can still be used in TCP-LCD. + +8. Related Work + + Several methods that address TCP's problems in the presence of + connectivity disruptions have been proposed in literature. Some of + them try to improve TCP's performance by modifying lower layers. For + example, [SM03] introduces a "smart link layer", which buffers one + segment for each active connection and replays these segments upon + connectivity re-establishment. This approach has a serious drawback: + previously stateless intermediate routers have to be modified in + order to inspect TCP headers, to track the end-to-end connection, and + to provide additional buffer space. This leads to an additional need + for memory and processing power. + + On the other hand, stateless link-layer schemes, as proposed in + [RFC3819], which unconditionally buffer some small number of packets, + may have another problem: if a packet is buffered longer than the + maximum segment lifetime (MSL) of 2 min. [RFC0793], i.e., the + disconnection lasts longer than the MSL, TCP's assumption that such + segments will never be received will no longer be true, violating + 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] inform a TCP + sender about a disrupted path by special messages generated and sent + from intermediate routers. In the case of a link failure, the TCP + sender stops sending segments and freezes its retransmission timers. + TCP-F stays in this state and remains silent until either a "route + establishment notification" is received or an internal timer expires. + In contrast, ELFN periodically probes the network to detect + connectivity re-establishment. Both proposals rely on changes to + intermediate routers, whereas the scheme proposed in this document is + + + +Zimmermann & Hannemann Experimental [Page 18] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + a sender-only modification. Moreover, ELFN does not consider + congestion and may impose serious additional load on the network, + depending on the probe interval. + + The authors of "ad hoc TCP" (ATCP) [LS01] propose enhancements to + identify different types of packet loss by introducing a layer + between TCP and IP. They utilize ICMP destination unreachable + messages to set TCP's receiver advertised window to zero, thus + forcing the TCP sender to perform 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 exploits ICMP messages to + undo a retransmission timer backoff when TCP is already probing. In + principle, both mechanisms could be combined. However, due to + security considerations, it does not 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 proposed extensions modify + the local behavior of TCP and introduce a new TCP option to signal + locally received connectivity-change indications (CCIs) to remote + peers. Upon receipt of a CCI, they re-probe the path characteristics + either by performing a speculative retransmission or by sending a + single segment of new data, depending on whether the connection is + currently stalled in exponential backoff or transmitting in steady- + state, respectively. The authors focus on specifying TCP response + mechanisms; nevertheless, underlying layers would have to be modified + to explicitly send CCIs to make these immediate responses possible. + +9. Security Considerations + + Generally, an attacker has only two attack alternatives: to generate + ICMP unreachable messages to try to make a TCP modified with TCP-LCD + flood the network, or to suppress legitimate ICMP unreachable + messages to try to slow down the transmission rate of a TCP sender. + + In order 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. Yet, the correct sequence + number is generally hard to guess, given the probability of 1/2^32. + Even if an attacker has information about that sequence number (i.e., + the attacker can eavesdrop on the retransmissions) the impact on the + network load from the attacker may be considered low, since the + retransmission frequency is limited by the RTO that was computed + before TCP had entered the timeout-based loss recovery. Hence, the + + + +Zimmermann & Hannemann Experimental [Page 19] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + highest probing frequency is expected to be even lower than once per + minimum RTO, i.e., 1 s as specified by [RFC2988]. It is 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. + + There may be means by which an attacker can cause the suppression of + legitimate ICMP unreachable messages (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 such an 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 is + not 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. + + + +Zimmermann & Hannemann Experimental [Page 20] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + [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 + + [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. + + + + +Zimmermann & Hannemann Experimental [Page 21] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + [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. + + + + +Zimmermann & Hannemann Experimental [Page 22] + +RFC 6069 Making TCP More Robust to LCDs December 2010 + + + [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 + + 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 + + + + + +Zimmermann & Hannemann Experimental [Page 23] + |