draft-ietf-tcpm-tcp-lcd-02.txt   draft-ietf-tcpm-tcp-lcd-03.txt 
TCP Maintenance and Minor A. Zimmermann TCP Maintenance and Minor A. Zimmermann
Extensions (TCPM) WG A. Hannemann Extensions (TCPM) WG A. Hannemann
Internet-Draft RWTH Aachen University Internet-Draft RWTH Aachen University
Intended status: Experimental July 29, 2010 Intended status: Experimental September 14, 2010
Expires: January 30, 2011 Expires: March 18, 2011
Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD) Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD)
draft-ietf-tcpm-tcp-lcd-02 draft-ietf-tcpm-tcp-lcd-03
Abstract Abstract
Disruptions in end-to-end path connectivity, which last longer than Disruptions in end-to-end path connectivity, which last longer than
one retransmission timeout, cause suboptimal TCP performance. The one retransmission timeout, cause suboptimal TCP performance. The
reason for this performance degradation is that TCP interprets reason for this performance degradation is that TCP interprets
segment loss induced by long connectivity disruptions as a sign of segment loss induced by long connectivity disruptions as a sign of
congestion, resulting in repeated retransmission timer backoffs. congestion, resulting in repeated retransmission timer backoffs.
This, in turn, leads to a delayed detection of the re-establishment This, in turn, leads to a delayed detection of the re-establishment
of the connection since TCP waits for the next retransmission timeout of the connection since TCP waits for the next retransmission timeout
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 30, 2011. This Internet-Draft will expire on March 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Connectivity Disruption Indication . . . . . . . . . . . . . . 6 3. Connectivity Disruption Indication . . . . . . . . . . . . . . 6
4. Connectivity Disruption Reaction . . . . . . . . . . . . . . . 8 4. Connectivity Disruption Reaction . . . . . . . . . . . . . . . 8
4.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Algorithm Details . . . . . . . . . . . . . . . . . . . . 8 4.2. Algorithm Details . . . . . . . . . . . . . . . . . . . . 9
5. Discussion of TCP-LCD . . . . . . . . . . . . . . . . . . . . 11 5. Discussion of TCP-LCD . . . . . . . . . . . . . . . . . . . . 12
5.1. Retransmission Ambiguity . . . . . . . . . . . . . . . . . 12 5.1. Retransmission Ambiguity . . . . . . . . . . . . . . . . . 13
5.2. Wrapped Sequence Numbers . . . . . . . . . . . . . . . . . 12 5.2. Wrapped Sequence Numbers . . . . . . . . . . . . . . . . . 13
5.3. Packet Duplication . . . . . . . . . . . . . . . . . . . . 14 5.3. Packet Duplication . . . . . . . . . . . . . . . . . . . . 14
5.4. Probing Frequency . . . . . . . . . . . . . . . . . . . . 14 5.4. Probing Frequency . . . . . . . . . . . . . . . . . . . . 15
5.5. Reaction during Connection Establishment . . . . . . . . . 14 5.5. Reaction during Connection Establishment . . . . . . . . . 15
5.6. Reaction in Steady-State . . . . . . . . . . . . . . . . . 15 5.6. Reaction in Steady-State . . . . . . . . . . . . . . . . . 15
6. Dissolving Ambiguity Issues using the TCP Timestamps Option . 15 6. Dissolving Ambiguity Issues using the TCP Timestamps Option . 16
7. Interoperability Issues . . . . . . . . . . . . . . . . . . . 17 7. Interoperability Issues . . . . . . . . . . . . . . . . . . . 17
7.1. Detection of TCP Connection Failures . . . . . . . . . . . 17 7.1. Detection of TCP Connection Failures . . . . . . . . . . . 18
7.2. Explicit Congestion Notification . . . . . . . . . . . . . 17 7.2. Explicit Congestion Notification (ECN) . . . . . . . . . . 18
7.3. ICMP for IP version 6 . . . . . . . . . . . . . . . . . . 18 7.3. TCP-LCD and IP Tunnels . . . . . . . . . . . . . . . . . . 18
7.4. TCP-LCD and IP Tunnels . . . . . . . . . . . . . . . . . . 18
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Changes from previous versions of the draft . . . . . 23 Appendix A. Changes from previous versions of the draft . . . . . 24
A.1. Changes from draft-ietf-tcpm-tcp-lcd-01 . . . . . . . . . 24 A.1. Changes from draft-ietf-tcpm-tcp-lcd-02 . . . . . . . . . 24
A.2. Changes from draft-ietf-tcpm-tcp-lcd-00 . . . . . . . . . 24 A.2. Changes from draft-ietf-tcpm-tcp-lcd-01 . . . . . . . . . 25
A.3. Changes from draft-zimmermann-tcp-lcd-02 . . . . . . . . . 24 A.3. Changes from draft-ietf-tcpm-tcp-lcd-00 . . . . . . . . . 25
A.4. Changes from draft-zimmermann-tcp-lcd-01 . . . . . . . . . 25 A.4. Changes from draft-zimmermann-tcp-lcd-02 . . . . . . . . . 25
A.5. Changes from draft-zimmermann-tcp-lcd-00 . . . . . . . . . 25 A.5. Changes from draft-zimmermann-tcp-lcd-01 . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 A.6. Changes from draft-zimmermann-tcp-lcd-00 . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The reader should be familiar with the algorithm and terminology from The reader should be familiar with the algorithm and terminology from
[RFC2988], which defines the standard algorithm Transmission Control [RFC2988], which defines the standard algorithm Transmission Control
Protocol (TCP) senders are required to use to compute and manage Protocol (TCP) senders are required to use to compute and manage
skipping to change at page 5, line 22 skipping to change at page 5, line 22
before the retransmission timer fires for the first time. In this before the retransmission timer fires for the first time. In this
case, TCP recovers lost data segments through Fast Retransmit and case, TCP recovers lost data segments through Fast Retransmit and
lost acknowledgments (ACK) through successfully delivered later ACKs. lost acknowledgments (ACK) through successfully delivered later ACKs.
Connectivity disruptions are declared as "long" for a given TCP Connectivity disruptions are declared as "long" for a given TCP
connection if the retransmission timer fires at least once before connection if the retransmission timer fires at least once before
connectivity is resumed. Whether or not path characteristics, like connectivity is resumed. Whether or not path characteristics, like
the round trip time (RTT) or the available bandwidth, have changed the round trip time (RTT) or the available bandwidth, have changed
when connectivity resumes after a disruption is another important when connectivity resumes after a disruption is another important
aspect for TCP's retransmission scheme [I-D.schuetz-tcpm-tcp-rlci]. aspect for TCP's retransmission scheme [I-D.schuetz-tcpm-tcp-rlci].
This document improves TCP's behavior in case of "long connectivity The algorithm specified in this document improves TCP's behavior in
disruptions". In particular, it focuses on the period prior to the case of "long connectivity disruptions". In particular, it focuses
re-establishment of the connectivity to a previously disconnected on the period prior to the re-establishment of the connectivity to a
peer node. The document does not describe any modifications to TCP's previously disconnected peer node. The document does not describe
behavior and its congestion control mechanisms [RFC5681] after any modifications to TCP's behavior and its congestion control
connectivity has been restored. mechanisms [RFC5681] after connectivity has been restored.
When a long connectivity disruption occurs on a TCP connection, the When a long connectivity disruption occurs on a TCP connection, the
TCP sender eventually does not receive any more acknowledgments. TCP sender eventually does not receive any more acknowledgments.
After the retransmission timer expires, the TCP sender enters the After the retransmission timer expires, the TCP sender enters the
timeout-based loss recovery and declares the oldest outstanding timeout-based loss recovery and declares the oldest outstanding
segment (SND.UNA) as lost. Since TCP tightly couples reliability and segment (SND.UNA) as lost. Since TCP tightly couples reliability and
congestion control, the retransmission of SND.UNA is triggered congestion control, the retransmission of SND.UNA is triggered
together with the reduction of the transmission rate. This is based together with the reduction of the transmission rate. This is based
on the assumption that segment loss is an indication of congestion on the assumption that segment loss is an indication of congestion
[RFC5681]. As long as the connectivity disruption persists, TCP will [RFC5681]. As long as the connectivity disruption persists, TCP will
skipping to change at page 6, line 19 skipping to change at page 6, line 19
only modification to provide robustness to long connectivity only modification to provide robustness to long connectivity
disruptions (TCP-LCD). The memo describes how the standard Internet disruptions (TCP-LCD). The memo describes how the standard Internet
Control Message Protocol (ICMP) can be exploited during timeout-based Control Message Protocol (ICMP) can be exploited during timeout-based
loss recovery to identify non-congestion loss caused by long loss recovery to identify non-congestion loss caused by long
connectivity disruptions. TCP-LCD's reversion strategy of the connectivity disruptions. TCP-LCD's reversion strategy of the
retransmission timer enables higher-frequency retransmissions and retransmission timer enables higher-frequency retransmissions and
thereby a prompt detection when connectivity to a previously thereby a prompt detection when connectivity to a previously
disconnected peer node has been restored. If no congestion is disconnected peer node has been restored. If no congestion is
present, TCP-LCD approaches the ideal behavior. 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.
3. Connectivity Disruption Indication 3. Connectivity Disruption Indication
If the queue of an intermediate router that is experiencing a link If the queue of an intermediate router that is experiencing a link
outage can buffer all incoming packets, a connectivity disruption outage can buffer all incoming packets, a connectivity disruption
will only cause a variation in delay, which is handled well by TCP will only cause a variation in delay, which is handled well by TCP
implementations using either Eifel [RFC3522], [RFC4015] or Forward implementations using either Eifel [RFC3522], [RFC4015] or Forward
RTO-Recovery (F-RTO) [RFC5682]. However, if the link outage lasts RTO-Recovery (F-RTO) [RFC5682]. However, if the link outage lasts
for too long, the router experiencing the link outage is forced to for too long, the router experiencing the link outage is forced to
drop packets, and finally to discard the according route. Means to drop packets, and finally to discard the according route. Means to
detect such link outages include reacting on failed address detect such link outages include reacting on failed address
resolution protocol (ARP) [RFC0826] queries, unsuccessful link resolution protocol (ARP) [RFC0826] queries, unsuccessful link
sensing, and the like. However, this is solely in the responsibility sensing, and the like. However, this is solely in the responsibility
of the respective router. of the respective router.
Note: The focus of this memo is on introducing a method how ICMP Note: The focus of this memo is on introducing a method how ICMP
messages may be exploited to improve TCP's performance; how messages may be exploited to improve TCP's performance; how
different physical and link layer mechanisms below the network different physical and link layer mechanisms below the network
layer may trigger ICMP destination unreachable messages are out of layer may trigger ICMP destination unreachable messages are out of
scope of this memo. scope of this memo.
Provided that no other route to the specific destination exists, the Provided that no other route to the specific destination exists, an
router will notify the corresponding sending host about the dropped Internet Protocol version 4 (IPv4) [RFC0791] router will notify the
packets via ICMP destination unreachable messages of code 0 (net corresponding sending host about the dropped packets via ICMP
unreachable) or code 1 (host unreachable) [RFC1812]. Therefore, the destination unreachable messages of code 0 (net unreachable) or code
sending host can use the ICMP destination unreachable messages of 1 (host unreachable) [RFC1812]. Therefore, the sending host can use
these codes as an indication for a connectivity disruption, since the the ICMP destination unreachable messages of these codes as an
reception of these messages provide evidence that packets were indication for a connectivity disruption, since the reception of
dropped due to a link outage. these messages provide evidence that packets were dropped due to a
link outage.
Note that there are also other ICMP destination unreachable messages For Internet Protocol version 6 (IPv6) [RFC2460], the counterpart of
with different codes. Some of them are candidates for connectivity the ICMP destination unreachable message of code 0 (net unreachable)
disruption indications, too, but need further investigation. For and of code 1 (host unreachable) is the ICMPv6 destination
example, ICMP destination unreachable messages with code 5 (source unreachable message of code 0 (no route to destination) [RFC4443].
route failed), code 11 (net unreachable for TOS), or code 12 (host As with IPv4, a router should generate an ICMPv6 destination
unreachable for TOS) [RFC1812]. On the other hand, codes that flag unreachable message of code 0 in response to a packet that cannot be
hard errors are of no use for this scheme, since TCP should abort the delivered to its destination address because it lacks a matching
connection when those are received [RFC1122]. In the following, the entry in its routing table.
term "ICMP unreachable message" is used as synonym for ICMP
destination unreachable messages of code 0 or code 1. 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), 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 synonym
for ICMP destination unreachable messages of code 0 or code 1 and
ICMPv6 destination unreachable 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 The accurate interpretation of ICMP unreachable messages as a
connectivity disruption indication is complicated by the following connectivity disruption indication is complicated by the following
two peculiarities of ICMP messages. First, they do not necessarily two peculiarities of ICMP messages. First, they do not necessarily
operate on the same timescale as the packets, i.e., TCP segments that 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, elicited them. When a router drops a packet due to a missing route,
it will not necessarily send an ICMP unreachable message immediately, it will not necessarily send an ICMP unreachable message immediately,
but will rather queue it for later delivery. Second, ICMP messages but will rather queue it for later delivery. Second, ICMP messages
are subject to rate limiting, e.g., when a router drops a whole 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 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 ICMP unreachable messages as dropped TCP segments. Depending on the
load of the router, it may not even send any ICMP unreachable load of the router, it may not even send any ICMP unreachable
messages at all. Both peculiarities originate from [RFC1812]. messages at all. Both peculiarities originate from [RFC1812] for
ICMPv4 and [RFC4443] for ICMPv6.
Fortunately, according to [RFC0792], ICMP unreachable messages have Fortunately, according to [RFC0792], ICMPv4 unreachable messages have
to contain in their body the entire Internet Protocol (IP) header to contain in their body the entire IPv4 header [RFC0791] of the
[RFC0791] of the datagram eliciting the ICMP unreachable message, datagram eliciting the ICMPv4 unreachable message, plus the first 64
plus the first 64 bits of the payload of that datagram. This allows bits of the payload of that datagram. This allows the sending host
the sending host to match the ICMP error message to the transport to match the ICMPv4 error message to the transport connection that
connection that elicited it. RFC 1812 [RFC1812] augments these elicited it. RFC 1812 [RFC1812] augments these requirements and
requirements and states that ICMP messages should contain as much of states that ICMPv4 messages should contain as much of the original
the original datagram as possible without the length of the ICMP datagram as possible without the length of the ICMPv4 datagram
datagram exceeding 576 bytes. Therefore, in case of TCP, at least exceeding 576 bytes. Therefore, in case of TCP, at least the source
the source port number, the destination port number, and the 32-bit port number, the destination port number, and the 32-bit TCP sequence
TCP sequence number are included. This allows the originating TCP to number are included. This allows the originating TCP to demultiplex
demultiplex the received ICMP message and to identify the affected the received ICMPv4 message and to identify the affected connection.
connection. Moreover, it can identify which segment of the Moreover, it can identify which segment of the respective connection
respective connection triggered the ICMP unreachable message, unless triggered the ICMPv4 unreachable message, unless there are several
there are several segments in-flight with the same sequence number segments in-flight with the same sequence number (see Section 5.1).
(see Section 5.1).
For IPv6 [RFC2460], the payload of an ICMPv6 error messages 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 form of an ICMP unreachable A connectivity disruption indication in form of an ICMP unreachable
message associated with a presumably lost TCP segment provides strong message associated with a presumably lost TCP segment provides strong
evidence that the segment was not dropped due to congestion, but was evidence that the segment was not dropped due to congestion, but was
successfully delivered as far as the reporting router. It therefore successfully delivered as far as the reporting router. It therefore
did not witness any congestion at least on that part of the path that 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 was traversed by both the TCP segment eliciting the ICMP unreachable
message as well as the ICMP unreachable message itself. message as well as the ICMP unreachable message itself.
4. Connectivity Disruption Reaction 4. Connectivity Disruption Reaction
skipping to change at page 11, line 40 skipping to change at page 12, line 25
retransmit immediately. In case the shortened retransmission timer retransmit immediately. In case the shortened retransmission timer
has not yet expired, TCP MUST wait accordingly. has not yet expired, TCP MUST wait accordingly.
5. Discussion of TCP-LCD 5. Discussion of TCP-LCD
TCP-LCD takes caution to only react to connectivity disruption TCP-LCD takes caution to only react to connectivity disruption
indications in the form of ICMP unreachable messages during timeout- indications in the form of ICMP unreachable messages during timeout-
based loss recovery. Therefore, TCP's behavior is not altered when based loss recovery. Therefore, TCP's behavior is not altered when
either no ICMP unreachable messages are received, or the either no ICMP unreachable messages are received, or the
retransmission timer of the TCP sender did not expire since the last retransmission timer of the TCP sender did not expire since the last
received acceptable ACK. Thus, by defintion, the algorithm triggers received acceptable ACK. Thus, by definition, the algorithm triggers
only in the case of long connectivity disruptions. only in the case of long connectivity disruptions.
Only such ICMP unreachable messages that contain a TCP segment with a Only such ICMP unreachable messages that contain a TCP segment with
the sequence number of a retransmission, i.e., contain SND.UNA, are the sequence number of a retransmission, i.e., contain SND.UNA, are
evaluated by TCP-LCD. All other ICMP unreachable messages are evaluated by TCP-LCD. All other ICMP unreachable messages are
ignored. The arrival of those ICMP unreachable messages provides ignored. The arrival of those ICMP unreachable messages provides
strong evidence that the retransmissions were not dropped due to strong evidence that the retransmissions were not dropped due to
congestion, but were successfully delivered to the reporting router. congestion, but were successfully delivered to the reporting router.
In other words, there is no evidence for any congestion at least on 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 that very part of the path that was traversed by both the TCP segment
eliciting the ICMP unreachable message as well as the ICMP eliciting the ICMP unreachable message as well as the ICMP
unreachable message itself. unreachable message itself.
skipping to change at page 12, line 42 skipping to change at page 13, line 27
retransmission ambiguity, too. In contrast to the above case, TCP retransmission ambiguity, too. In contrast to the above case, TCP
suffers from ambiguity regarding ICMP unreachable messages received suffers from ambiguity regarding ICMP unreachable messages received
during timeout-based loss recovery. With the TCP segment number during timeout-based loss recovery. With the TCP segment number
included in the ICMP unreachable message, a TCP sender is not able to included in the ICMP unreachable message, a TCP sender is not able to
determine if the ICMP unreachable message refers to the original determine if the ICMP unreachable message refers to the original
transmission or to any of the timeout-based retransmissions. That transmission or to any of the timeout-based retransmissions. That
is, there is an ambiguity with regards to which TCP segment an ICMP is, there is an ambiguity with regards to which TCP segment an ICMP
unreachable message reports on. unreachable message reports on.
However, this ambiguity is not considered to be a problem for the However, this ambiguity is not considered to be a problem for the
algorithm. The assumption that a received ICMP message provides algorithm. The assumption that a received ICMP unreachable message
evidence that a non-congestion loss caused by the connectivity provides evidence that a non-congestion loss caused by the
disruption was wrongly considered a congestion loss still holds, connectivity disruption was wrongly considered a congestion loss
regardless to which TCP segment, transmission or retransmission, the still holds, regardless to which TCP segment, transmission or
message refers. retransmission, the message refers.
5.2. Wrapped Sequence Numbers 5.2. Wrapped Sequence Numbers
Besides the ambiguity whether a received ICMP unreachable message Besides the ambiguity whether a received ICMP unreachable message
refers to the original transmission or to any of the retransmissions, refers to the original transmission or to any of the retransmissions,
there is another source of ambiguity related to the TCP sequence there is another source of ambiguity related to the TCP sequence
numbers contained in ICMP unreachable messages. For high bandwidth numbers contained in ICMP unreachable messages. For high bandwidth
paths, the sequence space may wrap quickly. This migth cause that paths, the sequence space may wrap quickly. This might cause that
delayed ICMP unreachable messages may coincidentally fit as valid delayed ICMP unreachable messages may coincidentally fit as valid
input in the proposed scheme. As a result, the scheme may input in the proposed scheme. As a result, the scheme may
incorrectly undo retransmission timer backoffs. Chances for this to incorrectly undo retransmission timer backoffs. Chances for this to
happen are minuscule, since a particular ICMP message would need to happen are minuscule, since a particular ICMP unreachable message
contain the exact sequence number of the current oldest outstanding would need to contain the exact sequence number of the current oldest
segment (SND.UNA), while at the same time TCP is in timeout-based outstanding segment (SND.UNA), while at the same time TCP is in
loss recovery. However, two "worst case" scenarios for the algorithm timeout-based loss recovery. However, two "worst case" scenarios for
are possible: the algorithm are possible:
For instance, consider a steady state TCP connection, which will be For instance, consider a steady state TCP connection, which will be
disrupted at an intermediate router R due to a link outage. Upon the disrupted at an intermediate router due to a link outage. Upon the
expiration of the RTO, the TCP sender enters the timeout-based loss expiration of the RTO, the TCP sender enters the timeout-based loss
recovery and starts to retransmit the earliest segment that has not recovery and starts to retransmit the earliest segment that has not
been acknowledged (SND.UNA). For some reason, router R delays all been acknowledged (SND.UNA). For some reason, the router delays all
corresponding ICMP unreachable messages so that the TCP sender backs corresponding ICMP unreachable messages so that the TCP sender backs
the retransmission timer off normally without any undoing. At the the retransmission timer off normally without any undoing. At the
end of the connectivity disruption, the TCP sender eventually detects end of the connectivity disruption, the TCP sender eventually detects
the re-establishment, leaves the scheme and finally the timeout-based the re-establishment, leaves the scheme and finally the timeout-based
loss recovery, too. A sequence number wrap-around later, the loss recovery, too. A sequence number wrap-around later, the
connectivity between the two peers is disrupted again, but this time connectivity between the two peers is disrupted again, but this time
due to congestion and exactly at the time at which the current due to congestion and exactly at the time at which the current
SND.UNA matches the SND.UNA from the previous cycle. If router R SND.UNA matches the SND.UNA from the previous cycle. If the router
emits the delayed ICMP unreachable messages now, the TCP sender would emits the delayed ICMP unreachable messages now, the TCP sender would
incorrectly undo retransmission timer backoffs. As the TCP sequence incorrectly undo retransmission timer backoffs. As the TCP sequence
number contains 32 bits, the probability of this scenario is at most number contains 32 bits, the probability of this scenario is at most
1/2^32. Given sufficiently many retransmissions in the first 1/2^32. Given sufficiently many retransmissions in the first
timeout-based loss recovery, the corresponding ICMP unreachable timeout-based loss recovery, the corresponding ICMP unreachable
messages could reduce the RTO in the second recovery at most to messages could reduce the RTO in the second recovery at most to
"RTO_BASE". However, once the ICMP unreachable messages are "RTO_BASE". However, once the ICMP unreachable messages are
depleted, the standard exponential backoff will be performed. Thus, depleted, the standard exponential backoff will be performed. Thus,
the congestion response will only be delayed by some false the congestion response will only be delayed by some false
retransmissions. retransmissions.
Similar to the above, consider the case where a steady state TCP Similar to the above, consider the case where a steady state TCP
connection with n segments in flight will be disrupted at some point connection with n segments in flight will be disrupted at some point
due to a link outage at an intermediate router R. For each segment in due to a link outage at an intermediate router. For each segment in
flight, router R may generate an ICMP unreachable message. However, flight, the router may generate an ICMP unreachable message.
due to some reason it delays them. Once the link outage is over and However, due to some reason it delays them. Once the link outage is
the connection has been re-established, the TCP sender leaves the over and the connection has been re-established, the TCP sender
scheme and slow-starts the connection. Following a sequence number leaves the scheme and slow-starts the connection. Following a
wrap-around, a retransmission timeout occurs, just at the moment the sequence number wrap-around, a retransmission timeout occurs, just at
TCP sender's current window of data reaches the previous range of the the moment the TCP sender's current window of data reaches the
sequence number space again. In case router R emits the delayed ICMP previous range of the sequence number space again. In case the
unreachable messages now, spurious undoing of the retransmission router emits the delayed ICMP unreachable messages now, spurious
timer backoff is possible once, if the TCP segment number contained undoing of the retransmission timer backoff is possible once, if the
in ICMP unreachable messages matches the current SND.UNA, and the TCP segment number contained in ICMP unreachable messages matches the
timeout was a result of congestion. In the case of another current SND.UNA, and the timeout was a result of congestion. In the
connectivity disruption, the additional undoing of the retransmission case of another connectivity disruption, the additional undoing of
timer backoff has no impact. The probability of this scenario is at the retransmission timer backoff has no impact. The probability of
most n/2^32. this scenario is at most n/2^32.
5.3. Packet Duplication 5.3. Packet Duplication
In case an intermediate router duplicates packets, a TCP sender may In case an intermediate router duplicates packets, a TCP sender may
receive more ICMP unreachable messages during timeout-based loss receive more ICMP unreachable messages during timeout-based loss
recovery than sent timeout-based retransmissions. However, since recovery than sent timeout-based retransmissions. However, since
TCP-LCD keeps track of the number of performed retransmission timer TCP-LCD keeps track of the number of performed retransmission timer
backoffs in the "BACKOFF_CNT" variable, it will not undo more backoffs in the "BACKOFF_CNT" variable, it will not undo more
retransmission timer backoffs than were actually performed. retransmission timer backoffs than were actually performed.
Nevertheless, if packet duplication and congestion coincide on the Nevertheless, if packet duplication and congestion coincide on the
path between the two communicating hosts, duplicated ICMP messages path between the two communicating hosts, duplicated ICMP unreachable
could hide the congestion loss of some retransmissions or ICMP messages could hide the congestion loss of some retransmissions or
messages, and the algorithm may incorrectly undo retransmission timer ICMP unreachable messages, and the algorithm may incorrectly undo
backoffs. Considering the overall impact of a router that duplicates retransmission timer backoffs. Considering the overall impact of a
packets, the additional load induced by some spurious timeout-based router that duplicates packets, the additional load induced by some
retransmits can probably be neglected. spurious timeout-based retransmits can probably be neglected.
5.4. Probing Frequency 5.4. Probing Frequency
One could argue that if an ICMP unreachable message arrives for a One might argue that if an ICMP unreachable message arrives for a
timeout-based retransmission, the RTO shall be reset or recalculated, timeout-based retransmission, the RTO shall be reset or recalculated,
similar to what is done when an ACK arrives during timeout-based loss similar to what is done when an ACK arrives during timeout-based loss
recovery (see Karn's algorithm [KP87], [RFC2988]), and a new recovery (see Karn's algorithm [KP87], [RFC2988]), and a new
retransmission should be sent immediately. Generally, this would retransmission should be sent immediately. Generally, this would
allow for a much higher probing frequency based on the round trip result in a much higher probing frequency based on the round trip
time up to the router where connectivity has been disrupted. time to the router where connectivity has been disrupted. However,
However, we believe the current scheme provides a good trade-off we believe the current scheme provides a good trade-off between
between conservative behavior and fast detection of connectivity re- conservative behavior and fast detection of connectivity re-
establishment. establishment. TCP-LCD focuses on long-connectivity disruptions,
i.e., on disruptions that last for several RTOs. Thus, a much higher
probing frequency (less then 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 5.5. Reaction during Connection Establishment
It is possible that a TCP sender enters timeout-based loss recovery It is possible that a TCP sender enters timeout-based loss recovery
while the connection is in SYN-SENT or SYN-RECEIVED states [RFC0793]. while the connection is in SYN-SENT or SYN-RECEIVED states [RFC0793].
The algorithm described in this document could also be used for The algorithm described in this document could also be used for
faster connection establishment in networks with connectivity faster connection establishment in networks with connectivity
disruptions. However, because existing TCP implementations [RFC5461] disruptions. However, because existing TCP implementations [RFC5461]
already interpret ICMP unreachable messages during connection already interpret ICMP unreachable messages during connection
establishment and abort the corresponding connection, we refrain from establishment and abort the corresponding connection, we refrain from
suggesting this. suggesting this.
5.6. Reaction in Steady-State 5.6. Reaction in Steady-State
Another exploitation of ICMP unreachable messages in the context of Another exploitation of ICMP unreachable messages in the context of
TCP congestion control might seem appropriate in case the ICMP TCP congestion control might seem appropriate, while TCP is in
unreachable message is received while TCP is in steady-state, and the steady-state. As the RTT up to the router that generated the ICMP
message refers to a segment from within the current window of data. unreachable message is likely to be substantially shorter than the
As the RTT up to the router that generated the ICMP unreachable overall RTT to the destination, the ICMP unreachable message may very
message is likely to be substantially shorter than the overall RTT to well reach the originating TCP while it is transmitting the current
the destination, the ICMP unreachable message may very well reach the window of data. In case the remaining window is large, it might seem
originating TCP while it is transmitting the current window of data. appropriate to refrain from transmitting the remaining window as
In case the remaining window is large, it might seem appropriate to there is timely evidence that it will only trigger further ICMP
refrain from transmitting the remaining window as there is timely unreachable messages at the very router. Although this promises
evidence that it will only trigger further ICMP unreachable messages improvement from a wastage perspective, it may be counterproductive
at the very router. Although this promises improvement from a from a security perspective. An attacker could forge such ICMP
wastage perspective, it may be counterproductive from a security messages, thereby forcing the originating TCP to stop sending data,
perspective. An attacker could forge such ICMP messages, thereby very similar to the blind throughput-reduction attack mentioned in
forcing the originating TCP to stop sending data, very similar to the [RFC5927].
blind throughput-reduction attack mentioned in [RFC5927].
An additional consideration is the following: in the presence of An additional consideration is the following: in the presence of
multi-path routing, even the receipt of a legitimate ICMP unreachable multi-path routing, even the receipt of a legitimate ICMP unreachable
message cannot be exploited accurately, because there is the message cannot be exploited accurately, because there is the
possibility that only one of the multiple paths to the destination is possibility that only one of the multiple paths to the destination is
suffering from a connectivity disruption, which causes ICMP suffering from a connectivity disruption, which causes ICMP
unreachable messages to be sent. Then, however, there is the unreachable messages to be sent. Then, however, there is the
possibility that the path along which the connectivity disruption possibility that the path along which the connectivity disruption
occurred contributed considerably to the overall bandwidth, such that occurred contributed considerably to the overall bandwidth, such that
a congestion response is very well reasonable. However, this is not a congestion response is very well reasonable. However, this is not
skipping to change at page 17, line 37 skipping to change at page 18, line 25
Due to TCP-LCD's reversion strategy of the retransmission timer, the Due to TCP-LCD's reversion strategy of the retransmission timer, the
assumption that a certain number of retransmissions corresponds to a assumption that a certain number of retransmissions corresponds to a
specific time interval no longer holds, as additional retransmissions specific time interval no longer holds, as additional retransmissions
may be performed during timeout-based-loss recovery to detect the end may be performed during timeout-based-loss recovery to detect the end
of the connectivity disruption. Therefore, a TCP employing TCP-LCD of the connectivity disruption. Therefore, a TCP employing TCP-LCD
either MUST measure the thresholds R1 and R2 in time units or, in either MUST measure the thresholds R1 and R2 in time units or, in
case R1 and R2 are counters of retransmissions, MUST convert them case R1 and R2 are counters of retransmissions, MUST convert them
into time intervals, which correspond to the time an unmodified TCP into time intervals, which correspond to the time an unmodified TCP
would need to reach the specified number of retransmissions. would need to reach the specified number of retransmissions.
7.2. Explicit Congestion Notification 7.2. Explicit Congestion Notification (ECN)
With Explicit Congestion Notification (ECN) [RFC3168], ECN-capable With Explicit Congestion Notification (ECN) [RFC3168], ECN-capable
routers are no longer limited to dropping packets to indicate routers are no longer limited to dropping packets to indicate
congestion. Instead, they can set the Congestion Experienced (CE) congestion. Instead, they can set the Congestion Experienced (CE)
codepoint in the IP header to indicate congestion. With TCP-LCD, it codepoint in the IP header to indicate congestion. With TCP-LCD, it
may happen that during a connectivity disruption, a received ICMP may happen that during a connectivity disruption, a received ICMP
unreachable message has been elicited by a timeout-based unreachable message has been elicited by a timeout-based
retransmission that was marked with the CE codepoint before reaching retransmission that was marked with the CE codepoint before reaching
the router experiencing the link outage. In such a case, a TCP the router experiencing the link outage. In such a case, a TCP
sender MUST, corresponding to [RFC3168] (Section 6.1.2), additionally sender MUST, corresponding to [RFC3168] (Section 6.1.2), additionally
reset the retransmission timer in case the algorithm undoes a reset the retransmission timer in case the algorithm undoes a
retransmission timer backoff. retransmission timer backoff.
7.3. ICMP for IP version 6 7.3. TCP-LCD and IP Tunnels
RFC 4443 [RFC4443] specifies the Internet Control Message Protocol
(ICMPv6) to be used with the Internet Protocol version 6 (IPv6)
[RFC2460]. From TCP-LCD's point of view, it is important to notice
that for IPv6, the payload of an ICMPv6 error messages 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, more information is
available for TCP-LCD than in the case of IPv4.
The counterpart of the ICMPv4 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. As a result, TCP-LCD can
employ this ICMPv6 error messages as connectivity disruption
indication, too.
7.4. TCP-LCD and IP Tunnels
It is worth noting that IP tunnels, including IPsec [RFC4301], IP in It is worth noting that IP tunnels, including IPsec [RFC4301], IP in
IP [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], and IP [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], and
others are compatible with TCP-LCD, as long as the received ICMP others are compatible with TCP-LCD, as long as the received ICMP
unreachable messages can be demultiplexed and extracted appropriately unreachable messages can be demultiplexed and extracted appropriately
by the TCP sender during timeout-based loss recovery. by the TCP sender during timeout-based loss recovery.
If, for example, end-to-end tunnels like IPsec in transport mode If, for example, end-to-end tunnels like IPsec in transport mode
[RFC4301] are employed, a TCP sender may receive ICMP unreachable [RFC4301] are employed, a TCP sender may receive ICMP unreachable
messages where additional steps, e.g., decrypting in step (5) of the messages where additional steps, e.g., decrypting in step (5) of the
skipping to change at page 20, line 23 skipping to change at page 20, line 35
specifying TCP response mechanisms, nevertheless underlying layers specifying TCP response mechanisms, nevertheless underlying layers
would have to be modified to explicitly send CCIs to make these would have to be modified to explicitly send CCIs to make these
immediate responses possible. immediate responses possible.
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
The algorithm proposed in this document is considered to be secure. Generally, an attacker has only two attack alternatives: to generate
For example, an attacker who already guessed the correct four-tuple ICMP unreachable messages to try to make a TCP modified with TCP-LCD
to 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, (i.e., Source IP Address, Source TCP port, Destination IP Address,
and Destination TCP port), can still not make a TCP modified with and Destination TCP port) and the exact segment sequence number of
TCP-LCD flood the network just by sending forged ICMP unreachable the current timeout-based retransmission. Yet, the correct sequence
messages in an attempt to maliciously shorten the retransmission number is generally hard to guess as; with a probability of 1/2^32.
timer. The attacker additionally would need to guess the correct Even if an attacker has information about that sequence number (i.e.,
segment sequence number of the current timeout-based retransmission, the attacker can eavesdrop on the retransmissions) the impact on the
with a probability of at most 1/2^32. Even in the case of man-in- network load the attacker may be considered low, since the
the-middle attacks, i.e., attacks performed in scenarios in which the retransmission frequency is limited by the RTO that was computed
attacker can sniff the retransmissions, the impact on network load is before TCP had entered the timeout-based loss recovery. Hence, the
considered to be low, since the retransmission frequency is limited highest probing frequency is expected to be even lower than once per
by the RTO that was computed before TCP had entered the timeout-based minimum RTO, i.e., 1s as specified by [RFC2988]. It is important to
loss recovery. Hence, the highest probing frequency is expected to note, that an attacker, who can correctly guess the four-tuple and
be even lower than once per minimum RTO, i.e. 1s as specified by the segment sequence number, can easily launch more serious attacks
[RFC2988]. (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 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.
11. Acknowledgments 11. Acknowledgments
We would like to thank Lars Eggert, Mark Handley, Kai Jakobs, Ilpo We would like to thank Lars Eggert, Adrian Farrel, Mark Handley, Kai
Jarvinen, Pasi Sarolahti, Tim Shepard, Joe Touch and Carsten Wolff Jakobs, Ilpo Jarvinen, Enrico Marocco, Catherine Meadows, Juergen
for feedback on earlier versions of this document. We also thank Quittek, Pasi Sarolahti, Tim Shepard, Joe Touch and Carsten Wolff for
Michael Faber, Daniel Schaffrath, and Damian Lukowski for feedback on earlier versions of this document. We also thank Michael
implementing and testing the algorithm in Linux. Special thanks go Faber, Daniel Schaffrath, and Damian Lukowski for implementing and
to Ilpo Jarvinen for giving valuable feedback regarding the Linux testing the algorithm in Linux. Special thanks go to Ilpo Jarvinen
implementation. for giving valuable feedback regarding the Linux implementation.
This work has been supported by the German National Science This work has been supported by the German National Science
Foundation (DFG) within the research excellence cluster Ultra High- Foundation (DFG) within the research excellence cluster Ultra High-
Speed Mobile Information and Communication (UMIC), RWTH Aachen Speed Mobile Information and Communication (UMIC), RWTH Aachen
University. University.
12. References 12. References
12.1. Normative References 12.1. Normative References
skipping to change at page 21, line 29 skipping to change at page 22, line 14
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. 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 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
12.2. Informative References 12.2. Informative References
[CRVP01] Chandran, K., Raghunathan, S., Venkatesan, S., and R. [CRVP01] Chandran, K., Raghunathan, S., Venkatesan, S., and R.
Prakash, "A feedback-based scheme for improving TCP Prakash, "A feedback-based scheme for improving TCP
performance in ad hoc wireless networks", IEEE Personal performance in ad hoc wireless networks", IEEE Personal
Communications vol. 8, no. 1, pp. 34-39, February 2001. Communications vol. 8, no. 1, pp. 34-39, February 2001.
skipping to change at page 23, line 14 skipping to change at page 23, line 51
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
for TCP", RFC 4015, February 2005. for TCP", RFC 4015, February 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[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.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
February 2009. February 2009.
[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,
"Forward RTO-Recovery (F-RTO): An Algorithm for Detecting "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP", RFC 5682, Spurious Retransmission Timeouts with TCP", RFC 5682,
September 2009. September 2009.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
skipping to change at page 23, line 43 skipping to change at page 24, line 27
[SM03] Scott, J. and G. Mapp, "Link layer-based TCP optimisation [SM03] Scott, J. and G. Mapp, "Link layer-based TCP optimisation
for disconnecting networks", SIGCOMM Computer for disconnecting networks", SIGCOMM Computer
Communication Review vol. 33, no. 5, pp. 31-42, Communication Review vol. 33, no. 5, pp. 31-42,
October 2003. October 2003.
[Zh86] Zhang, L., "Why TCP Timers Don't Work Well", Proceedings [Zh86] Zhang, L., "Why TCP Timers Don't Work Well", Proceedings
of the Conference on Applications, Technologies, of the Conference on Applications, Technologies,
Architectures, and Protocols for Computer Communication Architectures, and Protocols for Computer Communication
(SIGCOMM'86) pp. 397-405, August 1986. (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>.
Appendix A. Changes from previous versions of the draft Appendix A. Changes from previous versions of the draft
This appendix should be removed by the RFC Editor before publishing This appendix should be removed by the RFC Editor before publishing
this document as an RFC. this document as an RFC.
A.1. Changes from draft-ietf-tcpm-tcp-lcd-01 A.1. Changes from draft-ietf-tcpm-tcp-lcd-02
o Incorporated feedback submitted by Lars Eggert o Incorporated feedback submitted by Enrico Marocco (Gen-ART Review)
A.2. Changes from draft-ietf-tcpm-tcp-lcd-00 o Incorporated feedback submitted by Juergen Quittek (OpsDir Review)
o Incorporated feedback submitted by Catherine Meadows (SecDir
Review)
o Incorporated feedback submitted by Adrian Farrel (IESG Review)
A.2. Changes from draft-ietf-tcpm-tcp-lcd-01
o Incorporated feedback submitted by Lars Eggert (AD Review)
A.3. Changes from draft-ietf-tcpm-tcp-lcd-00
o Editorial changes. o Editorial changes.
o Clarified TCP-LCD's behaviour during connection establishment o Clarified TCP-LCD's behaviour during connection establishment
(Thanks to Mark Handley). (Thanks to Mark Handley).
A.3. Changes from draft-zimmermann-tcp-lcd-02 A.4. Changes from draft-zimmermann-tcp-lcd-02
o Incorporated feedback submitted by Ilpo Jarvinen. o Incorporated feedback submitted by Ilpo Jarvinen.
<http://www.ietf.org/mail-archive/web/tcpm/current/msg04841.html> <http://www.ietf.org/mail-archive/web/tcpm/current/msg04841.html>
o Incorporated feedback submitted by Pasi Sarolahti. o Incorporated feedback submitted by Pasi Sarolahti.
<http://www.ietf.org/mail-archive/web/tcpm/current/msg04870.html> <http://www.ietf.org/mail-archive/web/tcpm/current/msg04870.html>
o Incorporated feedback submitted by Joe Touch. o Incorporated feedback submitted by Joe Touch.
<http://www.ietf.org/mail-archive/web/tcpm/current/msg04895.html> <http://www.ietf.org/mail-archive/web/tcpm/current/msg04895.html>
<http://www.ietf.org/mail-archive/web/tcpm/current/msg04900.html> <http://www.ietf.org/mail-archive/web/tcpm/current/msg04900.html>
skipping to change at page 25, line 5 skipping to change at page 26, line 5
subsection anymore. Moreover, the section was renamed to subsection anymore. Moreover, the section was renamed to
"Dissolving Ambiguity Issues" and has now real content. "Dissolving Ambiguity Issues" and has now real content.
o An interoperability issues section (Section 7) was added. In o An interoperability issues section (Section 7) was added. In
particular comments to ECN, ICMPv6, and to the two thresholds R1 particular comments to ECN, ICMPv6, and to the two thresholds R1
and R2 of [RFC1122] (Section 4.2.3.5) were added. and R2 of [RFC1122] (Section 4.2.3.5) were added.
o Miscellaneous editorial changes. In particular, the algorithm has o Miscellaneous editorial changes. In particular, the algorithm has
a name now: TCP-LCD. a name now: TCP-LCD.
A.4. Changes from draft-zimmermann-tcp-lcd-01 A.5. Changes from draft-zimmermann-tcp-lcd-01
o The algorithm in Section 4.2 was slightly changed. Instead of o The algorithm in Section 4.2 was slightly changed. Instead of
reverting the last retransmission timer backoff by halving the reverting the last retransmission timer backoff by halving the
RTO, the RTO is recalculated with help of the "BACKOFF_CNT" RTO, the RTO is recalculated with help of the "BACKOFF_CNT"
variable. This fixes an issue that occurred when the variable. This fixes an issue that occurred when the
retransmission timer was backed off but bounded by a maximum retransmission timer was backed off but bounded by a maximum
value. The algorithm in the previous version of the draft, would value. The algorithm in the previous version of the draft, would
have "reverted" to half of that maximum value, instead of using have "reverted" to half of that maximum value, instead of using
the value, before the RTO was doubled (and then bounded). the value, before the RTO was doubled (and then bounded).
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
A.5. Changes from draft-zimmermann-tcp-lcd-00 A.6. Changes from draft-zimmermann-tcp-lcd-00
o Miscellaneous editorial changes in Section 1, 2 and 3. o Miscellaneous editorial changes in Section 1, 2 and 3.
o The document was restructured in Section 1, 2 and 3 for easier o The document was restructured in Section 1, 2 and 3 for easier
reading. The motivation for the algorithm is changed according reading. The motivation for the algorithm is changed according
TCP's problem to disambiguate congestion from non-congestion loss. TCP's problem to disambiguate congestion from non-congestion loss.
o Added Section 4.1. o Added Section 4.1.
o The algorithm in Section 4.2 was restructured and simplified: o The algorithm in Section 4.2 was restructured and simplified:
 End of changes. 42 change blocks. 
178 lines changed or deleted 230 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/