draft-ietf-tsvwg-tcp-eifel-alg-07.txt   rfc3522.txt 
Network Working Group Reiner Ludwig Network Working Group R. Ludwig
INTERNET-DRAFT Michael Meyer Request for Comments: 3522 M. Meyer
Expires: June 2003 Ericsson Research Category: Experimental Ericsson Research
December, 2002 April 2003
The Eifel Detection Algorithm for TCP The Eifel Detection Algorithm for TCP
<draft-ietf-tsvwg-tcp-eifel-alg-07.txt>
Status of this memo Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. It does not specify an Internet standard of any kind.
time. It is inappropriate to use Internet-Drafts as reference Discussion and suggestions for improvement are requested.
material or cite them other than as "work in progress". Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html
Abstract Abstract
The Eifel detection algorithm allows a TCP sender to detect a The Eifel detection algorithm allows a TCP sender to detect a
posteriori whether it has entered loss recovery unnecessarily. It posteriori whether it has entered loss recovery unnecessarily. It
requires that the TCP Timestamps option defined in RFC1323 is enabled requires that the TCP Timestamps option defined in RFC 1323 be
for a connection. The Eifel detection algorithm makes use of the fact enabled for a connection. The Eifel detection algorithm makes use of
that the TCP Timestamps option eliminates the retransmission the fact that the TCP Timestamps option eliminates the retransmission
ambiguity in TCP. Based on the timestamp of the first acceptable ACK ambiguity in TCP. Based on the timestamp of the first acceptable ACK
that arrives during loss recovery, it decides whether loss recovery that arrives during loss recovery, it decides whether loss recovery
was entered unnecessarily. The Eifel detection algorithm provides a was entered unnecessarily. The Eifel detection algorithm provides a
basis for future TCP enhancements. This includes response algorithms basis for future TCP enhancements. This includes response algorithms
to back out of loss recovery by restoring a TCP sender's congestion to back out of loss recovery by restoring a TCP sender's congestion
control state. control state.
Terminology Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]. document, are to be interpreted as described in [RFC2119].
We refer to the first-time transmission of an octet as the 'original We refer to the first-time transmission of an octet as the 'original
transmit'. A subsequent transmission of the same octet is referred to transmit'. A subsequent transmission of the same octet is referred
as a 'retransmit'. In most cases this terminology can likewise be to as a 'retransmit'. In most cases, this terminology can likewise
applied to data segments as opposed to octets. However, with be applied to data segments as opposed to octets. However, with
repacketization a segment can contain both first-time transmissions repacketization, a segment can contain both first-time transmissions
and retransmissions of octets. In that case, this terminology is only and retransmissions of octets. In that case, this terminology is
consistent when applied to octets. For the Eifel detection algorithm only consistent when applied to octets. For the Eifel detection
this makes no difference as it also operates correctly when algorithm, this makes no difference as it also operates correctly
repacketization occurs. when repacketization occurs.
We use the term 'acceptable ACK' as defined in [RFC793]. That is an We use the term 'acceptable ACK' as defined in [RFC793]. That is an
ACK that acknowledges previously unacknowledged data. We use the term ACK that acknowledges previously unacknowledged data. We use the
'duplicate ACK', and the variable 'dupacks' as defined in [WS95]. The term 'duplicate ACK', and the variable 'dupacks' as defined in
variable 'dupacks' is a counter of duplicate ACKs that have already [WS95]. The variable 'dupacks' is a counter of duplicate ACKs that
been received by a TCP sender before the fast retransmit is sent. We have already been received by a TCP sender before the fast retransmit
use the variable 'DupThresh' to refer to the so-called duplicate is sent. We use the variable 'DupThresh' to refer to the so-called
acknowledgement threshold, i.e., the number of duplicate ACKs that duplicate acknowledgement threshold, i.e., the number of duplicate
need to arrive at a TCP sender to trigger a fast retransmit. ACKs that need to arrive at a TCP sender to trigger a fast
Currently, DupThresh is specified as a fixed value of three retransmit. Currently, DupThresh is specified as a fixed value of
[RFC2581]. Future TCPs might implement an adaptive DupThresh. three [RFC2581]. Future TCPs might implement an adaptive DupThresh.
1. Introduction 1. Introduction
The retransmission ambiguity problem [Zh86][KP87] is a TCP sender's The retransmission ambiguity problem [Zh86], [KP87] is a TCP sender's
inability to distinguish whether the first acceptable ACK that inability to distinguish whether the first acceptable ACK that
arrives after a retransmit, was sent in response to the original arrives after a retransmit was sent in response to the original
transmit or the retransmit. This problem occurs after a timeout-based transmit or the retransmit. This problem occurs after a timeout-
retransmit and after a fast retransmit. The Eifel detection algorithm based retransmit and after a fast retransmit. The Eifel detection
uses the TCP Timestamps option defined in [RFC1323] to eliminate the algorithm uses the TCP Timestamps option defined in [RFC1323] to
retransmission ambiguity. It thereby allows a TCP sender to detect a eliminate the retransmission ambiguity. It thereby allows a TCP
posteriori whether it has entered loss recovery unnecessarily. sender to detect a posteriori whether it has entered loss recovery
unnecessarily.
This added capability of a TCP sender is useful in environments where This added capability of a TCP sender is useful in environments where
TCP's loss recovery and congestion control algorithms may often get TCP's loss recovery and congestion control algorithms may often get
falsely triggered. This can be caused by packet reordering, packet falsely triggered. This can be caused by packet reordering, packet
duplication, or a sudden delay increase in the data or the ACK path duplication, or a sudden delay increase in the data or the ACK path
that results in a spurious timeout. For example, such sudden delay that results in a spurious timeout. For example, such sudden delay
increases can often occur in wide-area wireless access networks due increases can often occur in wide-area wireless access networks due
to handovers, resource preemption due to higher priority traffic to handovers, resource preemption due to higher priority traffic
(e.g., voice), or because the mobile transmitter traverses through a (e.g., voice), or because the mobile transmitter traverses through a
radio coverage hole (e.g., see [Gu01]). In such wireless networks, radio coverage hole (e.g., see [Gu01]). In such wireless networks,
the often unnecessary go-back-N retransmits that typically occur the often unnecessary go-back-N retransmits that typically occur
after a spurious timeout create a serious problem. They decrease end- after a spurious timeout create a serious problem. They decrease
to-end throughput, are useless load upon the network, and waste end-to-end throughput, are useless load upon the network, and waste
transmission (battery) power. Note, that across such networks the use transmission (battery) power. Note that across such networks the use
of timestamps is recommended anyway [IMLGK02]. of timestamps is recommended anyway [RFC3481].
Based on the Eifel detection algorithm, a TCP sender may then choose Based on the Eifel detection algorithm, a TCP sender may then choose
to implement dedicated response algorithms. One goal of such a to implement dedicated response algorithms. One goal of such a
response algorithm would be to alleviate the consequences of a response algorithm would be to alleviate the consequences of a
falsely triggered loss recovery. This may include restoring the TCP falsely triggered loss recovery. This may include restoring the TCP
sender's congestion control state, and avoiding the mentioned sender's congestion control state, and avoiding the mentioned
unnecessary go-back-N retransmits. Another goal would be to adapt unnecessary go-back-N retransmits. Another goal would be to adapt
protocol parameters such as the duplicate acknowledgement threshold protocol parameters such as the duplicate acknowledgement threshold
[RFC2581], and the RTT estimators [RFC2988]. This is to reduce the [RFC2581], and the RTT estimators [RFC2988]. This is to reduce the
risk of falsely triggering TCP's loss recovery again as the risk of falsely triggering TCP's loss recovery again as the
connection progresses. However, such response algorithms are outside connection progresses. However, such response algorithms are outside
the scope of this document. Note: The original proposal, the "Eifel the scope of this document. Note: The original proposal, the "Eifel
algorithm" [LK00], comprises both a detection and a response algorithm" [LK00], comprises both a detection and a response
algorithm. This document only defines the detection part. The algorithm. This document only defines the detection part. The
response part is defined in [LG02]. response part is defined in [LG03].
A key feature of the Eifel detection algorithm is that it already A key feature of the Eifel detection algorithm is that it already
detects upon the first acceptable ACK that arrives during loss detects, upon the first acceptable ACK that arrives during loss
recovery whether a fast retransmit or a timeout was spurious. This is recovery, whether a fast retransmit or a timeout was spurious. This
crucial to be able to avoid the mentioned go-back-N retransmits. is crucial to be able to avoid the mentioned go-back-N retransmits.
Another feature is that the Eifel detection algorithm is fairly Another feature is that the Eifel detection algorithm is fairly
robust against the loss of ACKs. robust against the loss of ACKs.
Also the DSACK option [RFC2883] can be used to detect a posteriori Also the DSACK option [RFC2883] can be used to detect a posteriori
whether a TCP sender has entered loss recovery unnecessarily [BA02]. whether a TCP sender has entered loss recovery unnecessarily [BA02].
However, the first ACK carrying a DSACK option usually arrives at a However, the first ACK carrying a DSACK option usually arrives at a
TCP sender only after loss recovery has already terminated. Thus, the TCP sender only after loss recovery has already terminated. Thus,
DSACK option cannot be used to eliminate the retransmission the DSACK option cannot be used to eliminate the retransmission
ambiguity. Consequently, it cannot be used to avoid the mentioned ambiguity. Consequently, it cannot be used to avoid the mentioned
unnecessary go-back-N retransmits. Moreover, a DSACK-based detection unnecessary go-back-N retransmits. Moreover, a DSACK-based detection
algorithm is less robust against ACK losses. A recent proposal algorithm is less robust against ACK losses. A recent proposal based
neither based on the TCP timestamps nor the DSACK option does not on neither the TCP timestamps nor the DSACK option does not have the
have the limitation of DSACK-based schemes, but only addresses the limitation of DSACK-based schemes, but only addresses the case of
case of spurious timeouts [SK02]. spurious timeouts [SK03].
2. Events that Falsely Trigger TCP Loss Recovery 2. Events that Falsely Trigger TCP Loss Recovery
The following events may falsely trigger a TCP sender's loss recovery The following events may falsely trigger a TCP sender's loss recovery
and congestion control algorithms. This causes a so-called spurious and congestion control algorithms. This causes a so-called spurious
retransmit, and an unnecessary reduction of the TCP sender's retransmit, and an unnecessary reduction of the TCP sender's
congestion window and slow start threshold [RFC2581]. congestion window and slow start threshold [RFC2581].
- Spurious timeout - Spurious timeout
- Packet reordering - Packet reordering
- Packet duplication - Packet duplication
A spurious timeout is a timeout that would not have occurred had the A spurious timeout is a timeout that would not have occurred had the
sender "waited longer". This may be caused by increased delay that sender "waited longer". This may be caused by increased delay that
suddenly occurs in the data and/or the ACK path. That in turn might suddenly occurs in the data and/or the ACK path. That in turn might
cause an acceptable ACK to arrive too late, i.e., only after a TCP cause an acceptable ACK to arrive too late, i.e., only after a TCP
sender's retransmission timer has expired. For the purpose of sender's retransmission timer has expired. For the purpose of
specifying the algorithm in Section 3, we define this case as SPUR_TO specifying the algorithm in Section 3, we define this case as SPUR_TO
(equal 1). (equal 1).
Note: There is another case where a timeout would not have Note: There is another case where a timeout would not have
occurred had the sender "waited longer": the retransmission timer occurred had the sender "waited longer": the retransmission timer
expires, and afterwards the TCP sender receives the duplicate ACK expires, and afterwards the TCP sender receives the duplicate ACK
that would have triggered a fast retransmit of the oldest that would have triggered a fast retransmit of the oldest
outstanding segment. We call this a "fast timeout" since in outstanding segment. We call this a 'fast timeout', since in
competition with the fast retransmit algorithm the timeout was competition with the fast retransmit algorithm the timeout was
faster. However, a fast timeout is not spurious since apparently a faster. However, a fast timeout is not spurious since apparently
segment was in fact lost, i.e., loss recovery was initiated a segment was in fact lost, i.e., loss recovery was initiated
rightfully. In this document, we do not consider fast timeouts. rightfully. In this document, we do not consider fast timeouts.
This case is addressed in an independent document [Lu02].
Packet reordering in the network may occur because IP [RFC791] does Packet reordering in the network may occur because IP [RFC791] does
not guarantee in-order delivery of packets. Additionally, a TCP not guarantee in-order delivery of packets. Additionally, a TCP
receiver generates a duplicate ACK for each segment that arrives out- receiver generates a duplicate ACK for each segment that arrives
of-order. This results in a spurious fast retransmit if three or more out-of-order. This results in a spurious fast retransmit if three or
data segments arrive out-of-order at a TCP receiver, and at least more data segments arrive out-of-order at a TCP receiver, and at
three of the resulting duplicate ACKs arrive at the TCP sender. This least three of the resulting duplicate ACKs arrive at the TCP sender.
assumes that the duplicate acknowledgement threshold is set to three This assumes that the duplicate acknowledgement threshold is set to
as defined in [RFC2581]. three as defined in [RFC2581].
Packet duplication may occur because a receiving IP does not (cannot) Packet duplication may occur because a receiving IP does not (cannot)
remove packets that have been duplicated in the network. A TCP remove packets that have been duplicated in the network. A TCP
receiver in turn also generates a duplicate ACK for each duplicate receiver in turn also generates a duplicate ACK for each duplicate
segment. As with packet reordering, this results in a spurious fast segment. As with packet reordering, this results in a spurious fast
retransmit if duplication of data segments or ACKs results in three retransmit if duplication of data segments or ACKs results in three
or more duplicate ACKs to arrive at a TCP sender. Again, this assumes or more duplicate ACKs to arrive at a TCP sender. Again, this
that the duplicate acknowledgement threshold is set to three. assumes that the duplicate acknowledgement threshold is set to three.
The negative impact on TCP performance caused by packet reordering The negative impact on TCP performance caused by packet reordering
and packet duplication is commonly the same: a single spurious and packet duplication is commonly the same: a single spurious
retransmit (the fast retransmit), and the unnecessary halving of a retransmit (the fast retransmit), and the unnecessary halving of a
TCP sender's congestion window as a result of the subsequent fast TCP sender's congestion window as a result of the subsequent fast
recovery phase [RFC2581]. recovery phase [RFC2581].
The negative impact on TCP performance caused by a spurious timeout The negative impact on TCP performance caused by a spurious timeout
is more severe. First, the timeout event itself causes a single is more severe. First, the timeout event itself causes a single
spurious retransmit, and unnecessarily forces a TCP sender into slow spurious retransmit, and unnecessarily forces a TCP sender into slow
start [RFC2581]. Then, as the connection progresses, a chain reaction start [RFC2581]. Then, as the connection progresses, a chain
gets triggered that further decreases TCP's performance. Since the reaction gets triggered that further decreases TCP's performance.
timeout was spurious, at least some ACKs for original transmits Since the timeout was spurious, at least some ACKs for original
typically arrive at the TCP sender before the ACK for the retransmit transmits typically arrive at the TCP sender before the ACK for the
arrives. (This is unless severe packet reordering coincided with the retransmit arrives. (This is unless severe packet reordering
spurious timeout in such a way that the ACK for the retransmit is the coincided with the spurious timeout in such a way that the ACK for
first acceptable ACK to arrive at the TCP sender.) Those ACKs for the retransmit is the first acceptable ACK to arrive at the TCP
original transmits then trigger an implicit go-back-N loss recovery sender.) Those ACKs for original transmits then trigger an implicit
at the TCP sender. Assuming that none of the outstanding segments and go-back-N loss recovery at the TCP sender [LK00]. Assuming that none
none of the corresponding ACKs were lost, all outstanding segments of the outstanding segments and none of the corresponding ACKs were
get retransmitted unnecessarily. In fact, during this phase a TCP lost, all outstanding segments get retransmitted unnecessarily. In
sender breaks 'packet conservation' [Jac88]. This is because the fact, during this phase, a TCP sender violates the packet
unnecessary go-back-N retransmits are sent during slow start. Thus, conservation principle [Jac88]. This is because the unnecessary go-
for each packet that leaves the network and that belongs to the first back-N retransmits are sent during slow start. Thus, for each packet
half of the original flight, two useless retransmits are sent into that leaves the network and that belongs to the first half of the
the network. Moreover, some TCPs in addition suffer from a spurious original flight, two useless retransmits are sent into the network.
fast retransmit. This is because the unnecessary go-back-N In addition, some TCPs suffer from a spurious fast retransmit. This
retransmits arrive as duplicates at the TCP receiver, which in turn is because the unnecessary go-back-N retransmits arrive as duplicates
triggers a series of duplicate ACKs. Note that this last spurious at the TCP receiver, which in turn triggers a series of duplicate
fast retransmit could be avoided with the careful variant of 'bug ACKs. Note that this last spurious fast retransmit could be avoided
fix' [RFC2582]. with the careful variant of 'bugfix' [RFC2582].
More detailed explanations including TCP trace plots that visualize More detailed explanations, including TCP trace plots that visualize
the effects of spurious timeouts and packet reordering can be found the effects of spurious timeouts and packet reordering, can be found
in the original proposal [LK00]. in the original proposal [LK00].
3. The Eifel Detection Algorithm 3. The Eifel Detection Algorithm
3.1 The Idea 3.1 The Idea
The goal of the Eifel detection algorithm is to allow a TCP sender to The goal of the Eifel detection algorithm is to allow a TCP sender to
detect a posteriori whether it has entered loss recovery detect a posteriori whether it has entered loss recovery
unnecessarily. Furthermore, the TCP sender should be able to make unnecessarily. Furthermore, the TCP sender should be able to make
this decision upon the first acceptable ACK that arrives after the this decision upon the first acceptable ACK that arrives after the
timeout-based retransmit or the fast retransmit has been sent. This timeout-based retransmit or the fast retransmit has been sent. This
in turn requires extra information in ACKs by which the TCP sender in turn requires extra information in ACKs by which the TCP sender
can unambiguously distinguish whether that first acceptable ACK was can unambiguously distinguish whether that first acceptable ACK was
sent in response to the original transmit or the retransmit. Such sent in response to the original transmit or the retransmit. Such
extra information is provided by the TCP Timestamps option [RFC1323]. extra information is provided by the TCP Timestamps option [RFC1323].
Generally speaking, timestamps are monotonously increasing "serial Generally speaking, timestamps are monotonously increasing "serial
numbers" added into every segment that are then echoed within the numbers" added into every segment that are then echoed within the
corresponding ACKs. This is exploited by the Eifel detection corresponding ACKs. This is exploited by the Eifel detection
algorithm in the following way. algorithm in the following way.
Given that timestamps are enabled for a connection, a TCP sender Given that timestamps are enabled for a connection, a TCP sender
always stores the timestamp of the retransmit sent in the beginning always stores the timestamp of the retransmit sent in the beginning
of loss recovery, i.e., the timestamp of the timeout-based retransmit of loss recovery, i.e., the timestamp of the timeout-based retransmit
or the fast retransmit. If the timestamp of the first acceptable ACK, or the fast retransmit. If the timestamp of the first acceptable
that arrives after the retransmit was sent, is smaller then the ACK, that arrives after the retransmit was sent, is smaller then the
stored timestamp of that retransmit, then that ACK must have been stored timestamp of that retransmit, then that ACK must have been
sent in response to an original transmit. Hence, the TCP sender must sent in response to an original transmit. Hence, the TCP sender must
have entered loss recovery unnecessarily. have entered loss recovery unnecessarily.
The fact that the Eifel detection algorithm decides upon the first The fact that the Eifel detection algorithm decides upon the first
acceptable ACK is crucial to allow future response algorithms to acceptable ACK is crucial to allow future response algorithms to
avoid the unnecessary go-back-N retransmits that typically occur avoid the unnecessary go-back-N retransmits that typically occur
after a spurious timeout. Also, if loss recovery was entered after a spurious timeout. Also, if loss recovery was entered
unnecessarily, a window worth of ACKs are outstanding that all carry unnecessarily, a window worth of ACKs are outstanding that all carry
a timestamp that is smaller than the stored timestamp of the a timestamp that is smaller than the stored timestamp of the
retransmit. The arrival of any one of those ACKs suffices the Eifel retransmit. The arrival of any one of those ACKs is sufficient for
detection algorithm to work. Hence, the solution is fairly robust the Eifel detection algorithm to work. Hence, the solution is fairly
against ACK losses. Even the ACK sent in response to the retransmit, robust against ACK losses. Even the ACK sent in response to the
i.e., the one that carries the stored timestamp, may get lost. retransmit, i.e., the one that carries the stored timestamp, may get
lost without compromising the algorithm.
3.2 The Algorithm 3.2 The Algorithm
Given that the TCP Timestamps option [RFC1323] is enabled for a Given that the TCP Timestamps option [RFC1323] is enabled for a
connection, a TCP sender MAY use the Eifel detection algorithm as connection, a TCP sender MAY use the Eifel detection algorithm as
defined in this subsection. defined in this subsection.
If the Eifel detection algorithm is used, the following steps MUST be If the Eifel detection algorithm is used, the following steps MUST be
taken by a TCP sender, but only upon initiation of loss recovery, taken by a TCP sender, but only upon initiation of loss recovery,
i.e., when either the timeout-based retransmit or the fast retransmit i.e., when either the timeout-based retransmit or the fast retransmit
is sent. The Eifel detection algorithm MUST NOT be reinitiated after is sent. The Eifel detection algorithm MUST NOT be reinitiated after
loss recovery has already started. In particular, it may not be loss recovery has already started. In particular, it must not be
reinitiated upon subsequent timeouts for the same segment, and not reinitiated upon subsequent timeouts for the same segment, and not
upon retransmitting segments other than the oldest outstanding upon retransmitting segments other than the oldest outstanding
segment, e.g., during selective loss recovery. segment, e.g., during selective loss recovery.
(1) Set a "SpuriousRecovery" variable to FALSE (equal 0). (1) Set a "SpuriousRecovery" variable to FALSE (equal 0).
(2) Set a "RetransmitTS" variable to the value of the (2) Set a "RetransmitTS" variable to the value of the
Timestamp Value field of the Timestamps option included in Timestamp Value field of the Timestamps option included in
the retransmit sent when loss recovery is initiated. A TCP the retransmit sent when loss recovery is initiated. A
sender must ensure that RetransmitTS does not get TCP sender must ensure that RetransmitTS does not get
overwritten as loss recovery progresses, e.g., in case of overwritten as loss recovery progresses, e.g., in case of
a second timeout and subsequent second retransmit of the a second timeout and subsequent second retransmit of the
same octet. same octet.
(3) Wait for the arrival of an acceptable ACK. When an (3) Wait for the arrival of an acceptable ACK. When an
acceptable ACK has arrived proceed to step (4). acceptable ACK has arrived, proceed to step (4).
(4) If the value of the Timestamp Echo Reply field of the (4) If the value of the Timestamp Echo Reply field of the
acceptable ACK's Timestamps option is smaller than the acceptable ACK's Timestamps option is smaller than the
value of RetransmitTS, then proceed to step (5), value of RetransmitTS, then proceed to step (5),
else proceed to step (DONE). else proceed to step (DONE).
(5) If the acceptable ACK carries a DSACK option [RFC2883], (5) If the acceptable ACK carries a DSACK option [RFC2883],
then proceed to step (DONE), then proceed to step (DONE),
skipping to change at page 7, line 16 skipping to change at page 7, line 16
based retransmit, then set based retransmit, then set
SpuriousRecovery <- SPUR_TO (equal 1), SpuriousRecovery <- SPUR_TO (equal 1),
else set else set
SpuriousRecovery <- dupacks+1 SpuriousRecovery <- dupacks+1
(RESP) Do nothing (Placeholder for a response algorithm). (RESP) Do nothing (Placeholder for a response algorithm).
(DONE) No further processing. (DONE) No further processing.
The comparison "smaller than" in step (4) is conservative. In theory, The comparison "smaller than" in step (4) is conservative. In
if the timestamp clock is slow or the network is fast, RetransmitTS theory, if the timestamp clock is slow or the network is fast,
could at most be equal to the timestamp echoed by an ACK sent in RetransmitTS could at most be equal to the timestamp echoed by an ACK
response to an original transmit. In that case, it is assumed that sent in response to an original transmit. In that case, it is
the loss recovery was not falsely triggered. assumed that the loss recovery was not falsely triggered.
Note that the condition "if during the lifetime of the TCP connection Note that the condition "if during the lifetime of the TCP connection
the TCP sender has previously received an ACK with a DSACK option" in the TCP sender has previously received an ACK with a DSACK option" in
step (5) would be true in case the TCP receiver would signal in the step (5) would be true in case the TCP receiver would signal in the
SYN that it is DSACK-enabled. But unfortunately, this is not required SYN that it is DSACK-enabled. But unfortunately, this is not
by [RFC2883]. required by [RFC2883].
3.3 Fixing a Corner Case: "Timeout due to loss of all ACKs" (step 5) 3.3 A Corner Case: "Timeout due to loss of all ACKs" (step 5)
Even though the oldest outstanding segment arrived at a TCP receiver, Even though the oldest outstanding segment arrived at a TCP receiver,
the TCP sender is forced into a timeout if all ACKs are lost. the TCP sender is forced into a timeout if all ACKs are lost.
Although, the resulting retransmit is unnecessary, such a timeout is Although the resulting retransmit is unnecessary, such a timeout is
unavoidable. It should therefore not be considered to be spurious. unavoidable. It should therefore not be considered spurious.
Moreover, the subsequent reduction of the congestion window is a Moreover, the subsequent reduction of the congestion window is an
crucial response to the potentially heavy congestion in the ACK path. appropriate response to the potentially heavy congestion in the ACK
The original proposal [LK00] does not handle this case well. It path. The original proposal [LK00] does not handle this case well.
effectively disables this implicit form of congestion control for the It effectively disables this implicit form of congestion control for
ACK path, which otherwise does not exist in TCP. This problem is the ACK path, which otherwise does not exist in TCP. This problem is
fixed by step (5) of the Eifel detection algorithm as explained in fixed by step (5) of the Eifel detection algorithm as explained in
the remainder of this section. the remainder of this section.
If all ACKs are lost while the oldest outstanding segment arrived at If all ACKs are lost while the oldest outstanding segment arrived at
the TCP receiver, the retransmit arrives as a duplicate. In response the TCP receiver, the retransmit arrives as a duplicate. In response
to duplicates, RFC1323 mandates that the timestamp of the last to duplicates, RFC 1323 mandates that the timestamp of the last
segment that arrived in-sequence should be echoed. That timestamp is segment that arrived in-sequence should be echoed. That timestamp is
carried by the first acceptable ACK that arrives at the TCP sender carried by the first acceptable ACK that arrives at the TCP sender
after loss recovery was entered, and is commonly smaller than the after loss recovery was entered, and is commonly smaller than the
timestamp carried by the retransmit. Consequently, the Eifel timestamp carried by the retransmit. Consequently, the Eifel
detection algorithm misinterprets such a timeout as being spurious, detection algorithm misinterprets such a timeout as being spurious,
unless the TCP receiver is DSACK-enabled [RFC2883]. In that case, the unless the TCP receiver is DSACK-enabled [RFC2883]. In that case,
acceptable ACK carries a DSACK option, and the Eifel algorithm is the acceptable ACK carries a DSACK option, and the Eifel algorithm is
terminated through the first part of step (5). terminated through the first part of step (5).
Note: Not all TCP implementations strictly follow RFC1323. In Note: Not all TCP implementations strictly follow RFC 1323. In
response to a duplicate data segment, some TCP receivers echo the response to a duplicate data segment, some TCP receivers echo the
timestamp of the duplicate. With such TCP receivers, the corner timestamp of the duplicate. With such TCP receivers, the corner
case discussed in this section does not apply. The timestamp case discussed in this section does not apply. The timestamp
carried by the retransmit would be echoed in the first acceptable carried by the retransmit would be echoed in the first acceptable
ACK, and the Eifel detection algorithm would be terminated through ACK, and the Eifel detection algorithm would be terminated through
step (4). Thus, even though all ACKs were lost, and independent of step (4). Thus, even though all ACKs were lost and independent of
whether the DSACK option was enabled for a connection, the Eifel whether the DSACK option was enabled for a connection, the Eifel
detection algorithm would have no effect. detection algorithm would have no effect.
With TCP receivers that are not DSACK-enabled, disabling the With TCP receivers that are not DSACK-enabled, disabling the
mentioned implicit congestion control for the ACK path is not a mentioned implicit congestion control for the ACK path is not a
problem as long as data segments are lost in addition to the entire problem as long as data segments are lost, in addition to the entire
flight of ACKs. The Eifel detection algorithm misinterprets such a flight of ACKs. The Eifel detection algorithm misinterprets such a
timeout as being spurious, and the Eifel response algorithm would timeout as being spurious, and the Eifel response algorithm would
reverse congestion control state. Still, the TCP sender would respond reverse the congestion control state. Still, the TCP sender would
to congestion (in the data path) as soon as it finds out about the respond to congestion (in the data path) as soon as it finds out
first loss in the outstanding flight. I.e., the TCP sender would about the first loss in the outstanding flight. I.e., the TCP sender
still half its congestion window for that flight of packets. If no would still halve its congestion window for that flight of packets.
data segment is lost while the entire flight of ACKs is lost, the If no data segment is lost while the entire flight of ACKs is lost,
first acceptable ACK, that arrives at the TCP sender after loss the first acceptable ACK that arrives at the TCP sender after loss
recovery was entered, acknowledges all outstanding data. In that recovery was entered acknowledges all outstanding data. In that
case, the Eifel algorithm is terminated through the second part of case, the Eifel algorithm is terminated through the second part of
step (5). step (5).
Note that there is little concern about breaking 'packet Note that there is little concern about violating the packet
conservation' when entering slow start after an unavoidable timeout conservation principle when entering slow start after an unavoidable
caused by the loss of an entire flight of ACKs, i.e., when the Eifel timeout caused by the loss of an entire flight of ACKs, i.e., when
detection algorithm was terminated through step (5). This is because the Eifel detection algorithm was terminated through step (5). This
in that case, the acceptable ACK corresponds to the retransmit, which is because in that case, the acceptable ACK corresponds to the
is a strong indication that the pipe has drained entirely, i.e., that retransmit, which is a strong indication that the pipe has drained
no more original transmits are in the network. This is different with entirely, i.e., that no more original transmits are in the network.
spurious timeouts as discussed in Section 2. This is different with spurious timeouts as discussed in Section 2.
3.4 Protecting Against Misbehaving TCP Receivers (the Safe Variant) 3.4 Protecting Against Misbehaving TCP Receivers (the Safe Variant)
A TCP receiver can easily make a genuine retransmit appear to the TCP A TCP receiver can easily make a genuine retransmit appear to the TCP
sender as a spurious retransmit by forging echoed timestamps. This sender as a spurious retransmit by forging echoed timestamps. This
may pose a security concern. may pose a security concern.
Fortunately, there is a way to modify the Eifel detection algorithm Fortunately, there is a way to modify the Eifel detection algorithm
in a way that makes it robust against lying TCP receivers. The idea in a way that makes it robust against lying TCP receivers. The idea
is to use timestamps as a "segment's secret" that a TCP receiver only is to use timestamps as a segment's "secret" that a TCP receiver only
gets to know if it receives the segment. Conversely, a TCP receiver gets to know if it receives the segment. Conversely, a TCP receiver
will not know the timestamp of a segment that was lost. Hence, to will not know the timestamp of a segment that was lost. Hence, to
"prove" that it received the original transmit of a segment that a "prove" that it received the original transmit of a segment that a
TCP sender retransmitted, the TCP receiver would need to return the TCP sender retransmitted, the TCP receiver would need to return the
timestamp of that original transmit. The Eifel detection algorithm timestamp of that original transmit. The Eifel detection algorithm
could then be modified to only decide that loss recovery has been could then be modified to only decide that loss recovery has been
unnecessarily entered if the first acceptable ACK echoes the unnecessarily entered if the first acceptable ACK echoes the
timestamp of the original transmit. timestamp of the original transmit.
Hence, implementers may choose to implement the algorithm with the Hence, implementers may choose to implement the algorithm with the
following modifications. following modifications.
Step (2) is replaced with step (2'): Step (2) is replaced with step (2'):
(2') Set a "RetransmitTS" variable to the value of the (2') Set a "RetransmitTS" variable to the value of the
Timestamp Value field of the Timestamps option that was Timestamp Value field of the Timestamps option that was
included in the original transmit corresponding to the included in the original transmit corresponding to the
retransmit. Note: This step requires that the TCP sender retransmit. Note: This step requires that the TCP sender
stores the timestamps of all outstanding original stores the timestamps of all outstanding original
transmits. transmits.
Step (4) is replaced with step (4'): Step (4) is replaced with step (4'):
(4') If the value of the Timestamp Echo Reply field of the (4') If the value of the Timestamp Echo Reply field of the
acceptable ACK's Timestamps option is equal to the value acceptable ACK's Timestamps option is equal to the value
of the variable RetransmitTS, then proceed to step (5), of the variable RetransmitTS, then proceed to step (5),
else proceed to step (DONE). else proceed to step (DONE).
These modifications come at a cost: the modified algorithm is fairly These modifications come at a cost: the modified algorithm is fairly
sensitive against ACK losses since it relies on the arrival of the sensitive against ACK losses since it relies on the arrival of the
acceptable ACK that corresponds to the original transmit. acceptable ACK that corresponds to the original transmit.
Note: The first acceptable ACK that arrives after loss recovery Note: The first acceptable ACK that arrives after loss recovery
has been unnecessarily entered, should echo the timestamp of the has been unnecessarily entered should echo the timestamp of the
original transmit. This assumes that the ACK corresponding to the original transmit. This assumes that the ACK corresponding to the
original transmit was not lost, that that ACK was not reordered in original transmit was not lost, that that ACK was not reordered in
the network, and that the TCP receiver does not forge timestamps the network, and that the TCP receiver does not forge timestamps
but complies with RFC1323. In case of a spurious fast retransmit, but complies with RFC 1323. In case of a spurious fast
this is implied by the rules for generating ACKs for data segments retransmit, this is implied by the rules for generating ACKs for
that fill in all or part of a gap in the sequence space (see data segments that fill in all or part of a gap in the sequence
section 4.2 of [RFC2581]) and by the rules for echoing timestamps space (see section 4.2 of [RFC2581]) and by the rules for echoing
in that case (see rule (C) in section 3.4 of [RFC1323]). In case timestamps in that case (see rule (C) in section 3.4 of
of a spurious timeout, it is likely that the delay (in the data [RFC1323]). In case of a spurious timeout, it is likely that the
path) that has caused the spurious timeout has also caused the TCP delay that has caused the spurious timeout has also caused the TCP
receiver's delayed ACK timer [RFC1122] to expire before the receiver's delayed ACK timer [RFC1122] to expire before the
original transmit arrives. Also, in this case the rules for original transmit arrives. Also, in this case the rules for
generating ACKs and the rules for echoing timestamps (see rule (A) generating ACKs and the rules for echoing timestamps (see rule (A)
in section 3.4 of [RFC1323]) ensure that the original transmit's in section 3.4 of [RFC1323]) ensure that the original transmit's
timestamp is echoed. timestamp is echoed.
A remaining problem is that a TCP receiver might guess a lost A remaining problem is that a TCP receiver might guess a lost
segment's timestamp from observing the timestamps of recently segment's timestamp from observing the timestamps of recently
received segments. For example, if segment N was lost while segment received segments. For example, if segment N was lost while segment
N-1 and N+1 have arrived, a TCP receiver could guess the timestamp N-1 and N+1 have arrived, a TCP receiver could guess the timestamp
that lies in the middle of the timestamps of segments N-1 and N+1, that lies in the middle of the timestamps of segments N-1 and N+1,
and echo it in the ACK for segment N+1. Especially if the TCP sender and echo it in the ACK sent in response to the retransmit of segment
implements timestamps with a coarse granularity, a misbehaving TCP N. Especially if the TCP sender implements timestamps with a coarse
receiver is likely to be successful with such an approach. In fact, granularity, a misbehaving TCP receiver is likely to be successful
with the 500 ms granularity suggested in [WS95], it even becomes with such an approach. In fact, with the 500 ms granularity
quite likely that the timestamps of segments N-1, N, N+1 are suggested in [WS95], it even becomes quite likely that the timestamps
identical. of segments N-1, N, N+1 are identical.
One way to reduce this risk is to implement fine grained timestamps. One way to reduce this risk is to implement fine grained timestamps.
Note that the granularity of the timestamps is independent of the Note that the granularity of the timestamps is independent of the
granularity of the retransmission timer. For example, some TCP granularity of the retransmission timer. For example, some TCP
implementations run a timestamp clock that even ticks every implementations run a timestamp clock that ticks every millisecond.
microsecond. This should make it more difficult for a TCP receiver to This should make it more difficult for a TCP receiver to guess the
guess the timestamp of a lost segment. Alternatively, it might be timestamp of a lost segment. Alternatively, it might be possible to
possible to combine the timestamps with a nonce, as done for the combine the timestamps with a nonce, as is done for the Explicit
Explicit Congestion Notification (ECN) [RFC3168]. One would need to Congestion Notification (ECN) [RFC3168]. One would need to take
take care, though, that the timestamps of succeeding segments remain care, though, that the timestamps of consecutive segments remain
monotonously increasing and do not interfere with the RTT timing monotonously increasing and do not interfere with the RTT timing
defined in [RFC1323]. defined in [RFC1323].
4. IPR Considerations 4. IPR Considerations
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights at http://www.ietf.org/ipr. rights at http://www.ietf.org/ipr.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
5. Security Considerations 5. Security Considerations
There do not seem to be any security considerations associated with There do not seem to be any security considerations associated with
the Eifel detection algorithm. This is because the Eifel detection the Eifel detection algorithm. This is because the Eifel detection
algorithm does not alter existing protocol state at a TCP sender. algorithm does not alter the existing protocol state at a TCP sender.
Note that the Eifel detection algorithm only requires changes to the Note that the Eifel detection algorithm only requires changes to the
implementation of a TCP sender. implementation of a TCP sender.
Moreover, a variant of the Eifel detection algorithm has been Moreover, a variant of the Eifel detection algorithm has been
proposed in Section 3.4 that makes it robust against lying TCP proposed in Section 3.4 that makes it robust against lying TCP
receivers. This may become relevant when the Eifel detection receivers. This may become relevant when the Eifel detection
algorithm is combined with a response algorithm such as the Eifel algorithm is combined with a response algorithm such as the Eifel
response algorithm [LG02]. response algorithm [LG03].
Acknowledgments Acknowledgments
Many thanks to Keith Sklower, Randy Katz, Stephan Baucke, Sally Many thanks to Keith Sklower, Randy Katz, Stephan Baucke, Sally
Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Andrei Gurtov, Pasi Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Andrei Gurtov, Pasi
Sarolahti, and Alexey Kuznetsov for useful discussions that Sarolahti, and Alexey Kuznetsov for useful discussions that
contributed to this work. contributed to this work.
Normative References Normative References
[RFC2581] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, A. Romanow, [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A.
An Extension to the Selective Acknowledgement (SACK) Option Romanow, "An Extension to the Selective Acknowledgement
for TCP, RFC 2883, July 2000. (SACK) Option for TCP", RFC 2883, July 2000.
[RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High [RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
Performance, RFC 1323, May 1992. High Performance", RFC 1323, May 1992.
[RFC2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Acknowledgement Options, RFC 2018, October 1996. Selective Acknowledgement Options", RFC 2018, October 1996.
[RFC793] J. Postel, Transmission Control Protocol, RFC793, September [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
1981. 793, September 1981.
Informative References Informative References
[BA02] E. Blanton, M. Allman, Using TCP DSACKs and SCTP Duplicate [BA02] Blanton, E. and M. Allman, "Using TCP DSACKs and SCTP
TSNs to Detect Spurious Retransmissions, work in progress, Duplicate TSNs to Detect Spurious Retransmissions", Work in
October 2002.. Progress.
[RFC1122] R. Braden, Requirements for Internet Hosts - Communication [RFC1122] Braden, R., "Requirements for Internet Hosts -
Layers, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2582] S. Floyd, T. Henderson, The NewReno Modification to TCP's [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
Fast Recovery Algorithm, RFC 2582, April 1999. TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[Gu01] A. Gurtov, Effect of Delays on TCP Performance, In [Gu01] Gurtov, A., "Effect of Delays on TCP Performance", In
Proceedings of IFIP Personal Wireless Communications, Proceedings of IFIP Personal Wireless Communications,
August 2001. August 2001.
[IMLGK02] H. Inamura et. al., TCP over Second (2.5G) and Third (3G) [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F.
Generation Wireless Networks, work in progress, July 2002. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation
Wireless Networks", RFC 3481, February 2003.
[Jac88] V. Jacobson, Congestion Avoidance and Control, In [Jac88] Jacobson, V., "Congestion Avoidance and Control", In
Proceedings of ACM SIGCOMM 88. Proceedings of ACM SIGCOMM 88.
[KP87] P. Karn, C. Partridge, Improving Round-Trip Time Estimates [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time
in Reliable Transport Protocols, In Proceedings of ACM Estimates in Reliable Transport Protocols", In Proceedings
SIGCOMM 87. of ACM SIGCOMM 87.
[LK00] R. Ludwig, R. H. Katz, The Eifel Algorithm: Making TCP [LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP
Robust Against Spurious Retransmissions, ACM Computer Robust Against Spurious Retransmissions", ACM Computer
Communication Review, Vol. 30, No. 1, January 2000. Communication Review, Vol. 30, No. 1, January 2000.
[LG02] R. Ludwig, A. Gurtov, The Eifel Response Algorithm for TCP, [LG03] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for
work in progress, October 2002. TCP", Work in Progress.
[Lu02] R. Ludwig, Responding to Fast Timeouts in TCP, work in
progress, July 2002.
[RFC2988] V. Paxson, M. Allman, Computing TCP's Retransmission Timer, [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC791] J. Postel, Internet Protocol, RFC 791, September 1981. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP, RFC 3168, Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001. September 2001.
[SK02] P. Sarolahti, M. Kojo, F-RTO: A TCP RTO Recovery Algorithm [SK03] Sarolahti, P. and M. Kojo, "F-RTO: A TCP RTO Recovery
for Avoiding Unnecessary Retransmissions, work in progress, Algorithm for Avoiding Unnecessary Retransmissions", Work
June 2002. in Progress.
[WS95] G. R. Wright, W. R. Stevens, TCP/IP Illustrated, Volume 2 [WS95] Wright, G. R. and W. R. Stevens, "TCP/IP Illustrated,
(The Implementation), Addison Wesley, January 1995. Volume 2 (The Implementation)", Addison Wesley, January
1995.
[Zh86] L. Zhang, Why TCP Timers Don't Work Well, In Proceedings of [Zh86] Zhang, L., "Why TCP Timers Don't Work Well", In Proceedings
ACM SIGCOMM 88. of ACM SIGCOMM 86.
Author's Address Authors' Addresses
Reiner Ludwig Reiner Ludwig
Ericsson Research Ericsson Research
Ericsson Allee 1 Ericsson Allee 1
52134 Herzogenrath, Germany 52134 Herzogenrath, Germany
Email: Reiner.Ludwig@eed.ericsson.se
Michael Meyer EMail: Reiner.Ludwig@eed.ericsson.se
Ericsson Research
Ericsson Allee 1
52134 Herzogenrath, Germany
Email: Michael.Meyer@eed.ericsson.se
This Internet-Draft expires in June 2003. Michael Meyer
Ericsson Research
Ericsson Allee 1
52134 Herzogenrath, Germany
EMail: Michael.Meyer@eed.ericsson.se
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 104 change blocks. 
281 lines changed or deleted 267 lines changed or added

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