draft-ietf-tcpm-newcwv-04.txt   draft-ietf-tcpm-newcwv-05.txt 
TCPM Working Group G. Fairhurst TCPM Working Group G. Fairhurst
Internet-Draft A. Sathiaseelan Internet-Draft A. Sathiaseelan
Obsoletes: 2861 (if approved) R. Secchi Obsoletes: 2861 (if approved) R. Secchi
Updates: 5681 (if approved) University of Aberdeen Updates: 5681 (if approved) University of Aberdeen
Intended status: Standards Track December 16, 2013 Intended status: Standards Track February 4, 2014
Expires: June 19, 2014 Expires: August 8, 2014
Updating TCP to support Rate-Limited Traffic Updating TCP to support Rate-Limited Traffic
draft-ietf-tcpm-newcwv-04 draft-ietf-tcpm-newcwv-05
Abstract Abstract
This document proposes an update to RFC 5681 to address issues that This document proposes an update to RFC 5681 to address issues that
arise when TCP is used to support traffic that exhibits periods where arise when TCP is used to support traffic that exhibits periods where
the sending rate is limited by the application rather than the the sending rate is limited by the application rather than the
congestion window. It updates TCP to allow a TCP sender to restart congestion window. It updates TCP to allow a TCP sender to restart
quickly following either an idle or rate-limited interval. This quickly following either an idle or rate-limited interval. This
method is expected to benefit applications that send rate-limited method is expected to benefit applications that send rate-limited
traffic using TCP, while also providing an appropriate response if traffic using TCP, while also providing an appropriate response if
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Window Validation, CWV, defined in RFC 2861, and concludes that RFC Window Validation, CWV, defined in RFC 2861, and concludes that RFC
2861 sought to address important issues, but failed to deliver a 2861 sought to address important issues, but failed to deliver a
widely used solution. This document therefore recommends that the widely used solution. This document therefore recommends that the
status of RFC 2861 is moved from Experimental to Historic, and that status of RFC 2861 is moved from Experimental to Historic, and that
it is replaced by the current specification. it is replaced by the current specification.
NOTE: The standards status of this WG document is under review for NOTE: The standards status of this WG document is under review for
consideration as either Experimental (EXP) or Proposed Standard (PS). consideration as either Experimental (EXP) or Proposed Standard (PS).
This decision will be made later as the document is finalised. This decision will be made later as the document is finalised.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 19, 2014. This Internet-Draft will expire on August 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 5 2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. An updated TCP response to idle and application-limited 4. An updated TCP response to idle and application-limited
periods . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 periods . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. A method for preserving cwnd during the idle and 4.1. A method for preserving cwnd during the idle and
application-limited periods. . . . . . . . . . . . . . . . 7 application-limited periods. . . . . . . . . . . . . . . 6
4.2. Initialisation . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Initialisation . . . . . . . . . . . . . . . . . . . . . 7
4.3. The nonvalidated phase . . . . . . . . . . . . . . . . . . 8 4.3. The nonvalidated phase . . . . . . . . . . . . . . . . . 7
4.4. TCP congestion control during the nonvalidated phase . . . 8 4.4. TCP congestion control during the nonvalidated phase . . 7
4.4.1. Response to congestion in the nonvalidated phase . . . 9 4.4.1. Response to congestion in the nonvalidated phase . . 9
4.4.2. Sender burst control during the nonvalidated phase . . 10 4.4.2. Sender burst control during the nonvalidated phase . 10
4.4.3. Adjustment at the end of the nonvalidated phase . . . 11 4.4.3. Adjustment at the end of the nonvalidated phase . . . 10
4.4.4. Examples of Implementation . . . . . . . . . . . . . . 11 4.5. Examples of Implementation . . . . . . . . . . . . . . . 11
5. Determining a safe period to preserve cwnd . . . . . . . . . . 13 4.5.1. Implementing pipeACK . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4.5.2. Implementing detection of the cwnd-limited condition 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Determining a safe period to preserve cwnd . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Other related work . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Revision notes . . . . . . . . . . . . . . . . . . . . . . 17 9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Other related work . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Revision notes . . . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
TCP is used to support a range of application behaviours. The TCP TCP is used to support a range of application behaviours. The TCP
congestion window (cwnd) controls the number of unacknowledged congestion window (cwnd) controls the number of unacknowledged
packets/bytes that a TCP flow may have in the network at any time, a packets/bytes that a TCP flow may have in the network at any time, a
value known as the FlightSize [RFC5681]. A bulk application will value known as the FlightSize [RFC5681]. A bulk application will
always have data available to transmit. The rate at which it sends always have data available to transmit. The rate at which it sends
is therefore limited by the maximum permitted by the receiver is therefore limited by the maximum permitted by the receiver
advertised window and the sender congestion window (cwnd). In advertised window and the sender congestion window (cwnd). In
skipping to change at page 5, line 18 skipping to change at page 4, line 18
control algorithm that decayed the cwnd after the transition to a control algorithm that decayed the cwnd after the transition to a
"sufficiently-long" idle period. This used the slow-start threshold "sufficiently-long" idle period. This used the slow-start threshold
(ssthresh) to save information about the previous value of the (ssthresh) to save information about the previous value of the
congestion window. The approach relaxed the standard TCP behaviour congestion window. The approach relaxed the standard TCP behaviour
[RFC5681] for an idle session, intended to improve application [RFC5681] for an idle session, intended to improve application
performance. CWV also modified the behaviour for a rate-limited performance. CWV also modified the behaviour for a rate-limited
session where a sender transmitted at a rate less than allowed by session where a sender transmitted at a rate less than allowed by
cwnd. cwnd.
RFC 2861 has been implemented in some mainstream operating systems as RFC 2861 has been implemented in some mainstream operating systems as
the default behaviour [Bis08]. Analysis (e.g. [Bis10] [Fai12]) has the default behaviour [Bis08]. Analysis (e.g. [Bis10] [Fai12]) has
shown that a TCP sender using CWV is able to use available capacity shown that a TCP sender using CWV is able to use available capacity
on a shared path after an idle period. This can benefit some on a shared path after an idle period. This can benefit some
applications, especially over long delay paths, when compared to the applications, especially over long delay paths, when compared to the
slow-start restart specified by standard TCP. However, CWV would slow-start restart specified by standard TCP. However, CWV would
only benefit an application if the idle period were less than several only benefit an application if the idle period were less than several
Retransmission Time Out (RTO) intervals [RFC6298], since the Retransmission Time Out (RTO) intervals [RFC6298], since the
behaviour would otherwise be the same as for standard TCP, which behaviour would otherwise be the same as for standard TCP, which
resets the cwnd to the RTCP Restart Window (RW) after this period. resets the cwnd to the RTCP Restart Window (RW) after this period.
Experience with RFC 2861 suggests that although the CWV method Experience with RFC 2861 suggests that although the CWV method
skipping to change at page 6, line 5 skipping to change at page 5, line 5
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 document assumes familiarity with the terminology of TCP The document assumes familiarity with the terminology of TCP
congestion control [RFC5681]. congestion control [RFC5681].
The following new terminology is introduced: The following new terminology is introduced:
cwnd-limited: A TCP flow that sends the number of segments permitted cwnd-limited: A TCP flow that has sent the maximum number of segments
by the cwnd, where the application utilises the allowed sending rate. permitted by the cwnd, where the application utilises the allowed
sending rate (see section 4.5.2).
pipeACK sample: A meaure of the volume of data acknowledged by the pipeACK sample: A measure of the volume of data acknowledged by the
network within an RTT. network within an RTT.
pipeACK variable: A variable that measures the available capacity pipeACK variable: A variable that measures the available capacity
using the set of pipeACK samples. using the set of pipeACK samples.
pipeACK Sampling Period: The maximum period that a measured pipeACK pipeACK Sampling Period: The maximum period that a measured pipeACK
sample may influence the pipeACK variable. sample may influence the pipeACK variable.
Non-validated phase: The phase where the cwnd reflects a previous Non-validated phase: The phase where the cwnd reflects a previous
measurement of the available path capacity. measurement of the available path capacity.
skipping to change at page 9, line 4 skipping to change at page 8, line 4
4.4. TCP congestion control during the nonvalidated phase 4.4. TCP congestion control during the nonvalidated phase
A TCP sender MUST enter the non-validated phase when the pipeACK is A TCP sender MUST enter the non-validated phase when the pipeACK is
less than (1/2)*cwnd. less than (1/2)*cwnd.
A TCP sender that enters the non-validated phase will preserve the A TCP sender that enters the non-validated phase will preserve the
cwnd (i.e., this neither grows nor reduces while the sender remains cwnd (i.e., this neither grows nor reduces while the sender remains
in this phase). If the sender receives an indication of congestion in this phase). If the sender receives an indication of congestion
(loss or Explicit Congestion Notification, ECN, mark [RFC3168]) it (loss or Explicit Congestion Notification, ECN, mark [RFC3168]) it
uses the method described below. The phase is concluded after a uses the method described below. The phase is concluded after a
fixed period of time (the NVP, as explained in section 4.4.2) or when fixed period of time (the NVP, as explained in section 4.4.3) or when
the sender transmits sufficient data so that pipeACK > (1/2)*cwnd the sender transmits sufficient data so that pipeACK > (1/2)*cwnd
(i.e. it is no longer rate-limited). (i.e. it is no longer rate-limited).
The behaviour in the non-validated phase is specified as: The behaviour in the non-validated phase is specified as:
o A cwnd-limited sender uses the standard TCP method to increase o A sender determines whether to increase the cwnd based upon
cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted whether it is cwnd-limited (see section 4.5.2):
to increase cwnd each received ACK).
o A sender that is not cwnd-limited MUST NOT increase the cwnd when o
ACK packets are received in this phase.
* A sender that is cwnd-limited MAY use the standard TCP method
to increase cwnd (i.e. a TCP sender that fully utilises the
cwnd is permitted to increase cwnd each received ACK using
standard methods).
* A sender that is not cwnd-limited MUST NOT increase the cwnd
when ACK packets are received in this phase.
o If the sender receives an indication of congestion while in the o If the sender receives an indication of congestion while in the
non-validated phase (i.e. detects loss, or an ECN mark), the non-validated phase (i.e., detects loss, or an ECN mark), the
sender MUST exit the non-validated phase (reducing the cwnd as sender MUST exit the non-validated phase (reducing the cwnd as
defined in section 4.3.1). defined in section 4.4.1).
o If the Retransmission Time Out (RTO) expires while in the non- o If the Retransmission Time Out (RTO) expires while in the non-
validated phase, the sender MUST exit the non-validated phase. It validated phase, the sender MUST exit the non-validated phase. It
then resumes using the Standard TCP RTO mechanism [RFC5681]. (The then resumes using the Standard TCP RTO mechanism [RFC5681]. (The
resulting reduction of cwnd described in section 4.3.2 is resulting reduction of cwnd described in section 4.4.3 is
appropriate, since any accumulated path history is considered appropriate, since any accumulated path history is considered
unreliable). unreliable).
o A sender with a pipeACK variable greater than (1/2)*cwnd SHOULD o A sender with a pipeACK variable greater than (1/2)*cwnd SHOULD
enter the validated phase. (A rate-limited sender will not enter the validated phase. (A rate-limited sender will not
normally be impacted by whether it is in a validated or non- normally be impacted by whether it is in a validated or non-
validated phase, since it will normally not consume the entire validated phase, since it will normally not consume the entire
cwnd. However a change to the validated phase will release the cwnd. However a change to the validated phase will release the
sender from constraints on the growth of cwnd, and restore the use sender from constraints on the growth of cwnd, and restore the use
of the standard congestion response.) of the standard congestion response.)
The cwnd-limited behaviour may be triggered during a transient
condition that occurs when a sender is in the non-validated phase and
receives an ACK that acknowledges received data, the cwnd was fully
utilised, and more data is awaiting transmission than may be sent
with the current cwnd. The sender is then allowed to use the
standard method to increase the cwnd. (Note, if the sender suceeds
in sending these new segments, the updated cwnd and pipeACK variables
will eventually result in a transition to the validated phase.)
4.4.1. Response to congestion in the nonvalidated phase 4.4.1. Response to congestion in the nonvalidated phase
Reception of congestion feedback while in the non-validated phase is Reception of congestion feedback while in the non-validated phase is
interpreted as an indication that it was inappropriate for the sender interpreted as an indication that it was inappropriate for the sender
to use the preserved cwnd. The sender is therefore required to to use the preserved cwnd. The sender is therefore required to
quickly reduce the rate to avoid further congestion. Since the cwnd quickly reduce the rate to avoid further congestion. Since the cwnd
does not have a validated value, a new cwnd value must be selected does not have a validated value, a new cwnd value must be selected
based on the utilised rate. based on the utilised rate.
A sender that detects a packet-drop, or receives an indication of an A sender that detects a packet-drop, or receives an indication of an
skipping to change at page 10, line 13 skipping to change at page 9, line 29
cwnd = (Max(pipeACK,LossFlightSize))/2. cwnd = (Max(pipeACK,LossFlightSize))/2.
If there is a valid pipeACK value, the new cwnd is adjusted to If there is a valid pipeACK value, the new cwnd is adjusted to
reflect that a nonvalidated cwnd may be larger than the actual reflect that a nonvalidated cwnd may be larger than the actual
FlightSize, or recently used FlightSize (recorded in pipeACK). The FlightSize, or recently used FlightSize (recorded in pipeACK). The
updated cwnd therefore prevents overshoot by a sender significantly updated cwnd therefore prevents overshoot by a sender significantly
increasing its transmission rate during the recovery period. increasing its transmission rate during the recovery period.
At the end of the recovery phase, the TCP sender MUST reset the cwnd At the end of the recovery phase, the TCP sender MUST reset the cwnd
using the method below: using the method below:
cwnd = (Max(pipeACK,LossFlightSize) - R)/2. cwnd = (Max(pipeACK,LossFlightSize) - R)/2.
Where, R is the volume of data that was retransmitted during the Where, R is the volume of data that was retransmitted during the
recovery phase. This follows the method proposed for Jump Start recovery phase. This follows the method proposed for Jump Start
[Liu07]. The inclusion of the term R makes an adjustment more [Liu07]. The inclusion of the term R makes an adjustment more
conservative than standard TCP. (This is required, since the sender conservative than standard TCP. (This is required, since the sender
may have sent more segments than a Standard TCP sender would have may have sent more segments than a standard TCP sender would have
done. The additional reduction is beneficial when the LossFlightSize done. The additional reduction is beneficial when the LossFlightSize
significantly overshoots the available path capacity incurring significantly overshoots the available path capacity incurring
significant loss, for instance an intense traffic burst following a significant loss, for instance an intense traffic burst following a
non-validated period.) non-validated period.)
If the sender implements a method that allows it to identify the If the sender implements a method that allows it to identify the
number of ECN-marked segments within a window that were observed by number of ECN-marked segments within a window that were observed by
the receiver, the sender SHOULD use the method above, further the receiver, the sender SHOULD use the method above, further
reducing R by the number of marked segments. reducing R by the number of marked segments.
The sender MUST also re-initialise the pipeACK variable to the The sender MUST also re-initialise the pipeACK variable to the
"undefined" value. This ensures that standard TCP methods are used "undefined" value. This ensures that standard TCP methods are used
immediately after completing loss recovery until a new pipeACK value immediately after completing loss recovery until a new pipeACK value
can be determined. can be determined.
ssthresh is adjusted using the standard TCP method. ssthresh is adjusted using the standard TCP method.
4.4.2. Sender burst control during the nonvalidated phase 4.4.2. Sender burst control during the nonvalidated phase
TCP congestion control allows a sender to accumulate a cwnd that TCP congestion control allows a sender to accumulate a cwnd that
would allow it to send a bursts of segments with a total size up to would allow it to send a burst of segments with a total size up to
the difference between the FlightsSize and cwnd. Such bursts can the difference between the FlightsSize and cwnd. Such bursts can
impact other flows that share a network bottleneck and/or may induce impact other flows that share a network bottleneck and/or may induce
congestion when buffering is limited. congestion when buffering is limited.
Various methods have been proposed to control the sender bustiness Various methods have been proposed to control the sender burstiness
[Hug01], [All05]. For example, TCP can limit the number of new [Hug01], [All05]. For example, TCP can limit the number of new
segments it sends per received ACK . This is effective when a flow segments it sends per received ACK . This is effective when a flow of
of ACKs is received, but can not be used to control a sender that has ACKs is received, but can not be used to control a sender that has
not send appreciable data in the previous RTT [All05]. not send appreciable data in the previous RTT [All05].
This document recommends using a method to avoid line-rate bursts This document recommends using a method to avoid line-rate bursts
after an idle or rate-limited period when there is less reliable after an idle or rate-limited period when there is less reliable
information about the capacity of the network path: A TCP sender in information about the capacity of the network path: A TCP sender in
the non-validated phase SHOULD control the maximum burst size, e.g. the non-validated phase SHOULD control the maximum burst size, e.g.
using a rate-based pacing algorithm in which a sender paces out the using a rate-based pacing algorithm in which a sender paces out the
cwnd over its estimate of the RTT, or some other method, to prevent cwnd over its estimate of the RTT, or some other method, to prevent
many segments being transmitted contiguously at line-rate. The most many segments being transmitted contiguously at line-rate. The most
appropriate method(s) to implement pacing depend on the design of the appropriate method(s) to implement pacing depend on the design of the
skipping to change at page 11, line 31 skipping to change at page 10, line 50
ssthresh = max(ssthresh, 3*cwnd/4). ssthresh = max(ssthresh, 3*cwnd/4).
(This adjustment of ssthresh ensures that the sender records that it (This adjustment of ssthresh ensures that the sender records that it
has safely sustained the present rate. The change is beneficial to has safely sustained the present rate. The change is beneficial to
rate-limited flows that encounter occasional congestion, and could rate-limited flows that encounter occasional congestion, and could
otherwise suffer an unwanted additional delay in recovering the otherwise suffer an unwanted additional delay in recovering the
sending rate.) sending rate.)
The sender MUST then update cwnd to be not greater than: The sender MUST then update cwnd to be not greater than:
cwnd = max(1/2*cwnd, IW). cwnd = max((1/2)*cwnd, IW).
Where IW is the appropriate TCP initial window, used by the TCP Where IW is the appropriate TCP initial window, used by the TCP
sender (e.g. [RFC5681]). sender (e.g. [RFC5681]).
(This adjustment ensures that sender responds conservatively at the (This adjustment ensures that sender responds conservatively at the
end of the non-validated phase by reducing the cwnd to better reflect end of the non-validated phase by reducing the cwnd to better reflect
the current rate of the sender. The cwnd update does not take into the current rate of the sender. The cwnd update does not take into
account FlightSize or pipeACK value because these values only reflect account FlightSize or pipeACK value because these values only reflect
historical data and do not reflect the current sending rate.) historical data and do not reflect the current sending rate.)
4.4.4. Examples of Implementation 4.5. Examples of Implementation
This section is intended to provide informative examples of This section provides informative examples of implementation methods.
implementation methods. Implementations may choose to use other Implementations may choose to use other methods that comply with the
methods that comply with the normative requirements. normative requirements.
4.5.1. Implementing pipeACK
A pipeACK sample may be measured once each RTT. This reduces the A pipeACK sample may be measured once each RTT. This reduces the
sender processing burden for calculating after each acknowledgement sender processing burden for calculating after each acknowledgement
and also reduces storage requirements at the sender. and also reduces storage requirements at the sender.
Since application behaviour can be bursty using CWV, it may be Since application behaviour can be bursty using CWV, it may be
desirable to implement a maximum filter to accumulate the measured desirable to implement a maximum filter to accumulate the measured
values so that the pipeACK variable records the largest pipeACK values so that the pipeACK variable records the largest pipeACK
sample within the pipeACK Sampling Period. One simple way to sample within the pipeACK Sampling Period. One simple way to
implement this is to divide the pipeACK Sampling Period into several implement this is to divide the pipeACK Sampling Period into several
skipping to change at page 12, line 45 skipping to change at page 12, line 17
within the pipeACK Sampling Period: A, B, and C. There was also a within the pipeACK Sampling Period: A, B, and C. There was also a
period of inactivity between samples B and C during which no period of inactivity between samples B and C during which no
measurements were taken. The current value of the pipeACK variable measurements were taken. The current value of the pipeACK variable
will be 5, the maximum across all samples. will be 5, the maximum across all samples.
After one further measurement period, Sample A will be discarded, After one further measurement period, Sample A will be discarded,
since it then is older than the pipeACK Sampling Period and the since it then is older than the pipeACK Sampling Period and the
pipeACK variable will be recalculated, Its value will be the larger pipeACK variable will be recalculated, Its value will be the larger
of Sample C or the final value accumulated in Sample D. of Sample C or the final value accumulated in Sample D.
Note that the NVP period does not necessarily require a new timer to Note that the pipeACK Sampling Period and the NVP period do not
be implemented. An alternative is to record a timestamp when the necessarily require a new timer to be implemented. An alternative is
sender enters the NVP. Each time a sender transmits a new segment, to record a timestamp when the sender enters the NVP. Each time a
this timestamp may be used to determine if the NVP period has sender transmits a new segment, this timestamp may be used to
expired. If the period expires, the sender may take into account how determine if the NVP period has expired. If the period expires, the
many units of the NVP period have passed and make one reduction (as sender may take into account how many units of the NVP period have
defined in section 4.3.2) for each NVP period. passed and make one reduction (as defined in section 4.4.3) for each
NVP period.
A method is required to detect the cwnd-limited condition. In simple 4.5.2. Implementing detection of the cwnd-limited condition
terms this method is true only when the TCP sender's FlightSize is
equal to or larger than the cwnd. However, an implementation must A method is required to detect the cwnd-limited condition (see
consider other constraints on the way in which cwnd variable is used, section 4.4). This is used to detect a condition where a sender in
for instance the need to support methods such as the Nagle Algorithm the non-validated phase receives an ACK, but the size of cwnd
and TCP Segment Offload (TSO). This can result in a sender becoming prevents sending more new data.
cwnd-limited when the cwnd is nearly, rather than completely, equal
to the FlightSize. In simple terms this condition is true only when the TCP sender's
FlightSize is equal to or larger than the cwnd. However, an
implementation must consider other constraints on the way in which
cwnd variable is used, for instance the need to support methods such
as the Nagle Algorithm and TCP Segment Offload (TSO). This can
result in a sender becoming cwnd-limited when the cwnd is nearly,
rather than completely, equal to the FlightSize.
5. Determining a safe period to preserve cwnd 5. Determining a safe period to preserve cwnd
This section documents the rationale for selecting the maximum period This section documents the rationale for selecting the maximum period
that cwnd may be preserved, known as the non-validated period, NVP. that cwnd may be preserved, known as the non-validated period, NVP.
Limiting the period that cwnd may be preserved avoids undesirable Limiting the period that cwnd may be preserved avoids undesirable
side effects that would result if the cwnd were to be kept side effects that would result if the cwnd were to be kept
unnecessarily high for an arbitrary long period, which was a part of unnecessarily high for an arbitrary long period, which was a part of
the problem that CWV originally attempted to address. The period a the problem that CWV originally attempted to address. The period a
skipping to change at page 14, line 6 skipping to change at page 13, line 33
congestion with the new method, however such variation would likely congestion with the new method, however such variation would likely
also impact TCP's behaviour when supporting interactive and bulk also impact TCP's behaviour when supporting interactive and bulk
applications. applications.
Routing algorithms may modify the network path, disrupting the RTT Routing algorithms may modify the network path, disrupting the RTT
measurement and changing the capacity available to a TCP connection, measurement and changing the capacity available to a TCP connection,
however such changes do not often occur within a time frame of a few however such changes do not often occur within a time frame of a few
minutes. minutes.
The value of five minutes is therefore expected to be sufficient for The value of five minutes is therefore expected to be sufficient for
most current applications. Simulation studies (e.g. [Bis11]) also most current applications. Simulation studies (e.g. [Bis11]) also
suggest that for many practical applications, the performance using suggest that for many practical applications, the performance using
this value will not be significantly different to that observed using this value will not be significantly different to that observed using
a non-standard method that does not reset the cwnd after idle. a non-standard method that does not reset the cwnd after idle.
Finally, other TCP sender mechanisms have used a 5 minute timer, and Finally, other TCP sender mechanisms have used a 5 minute timer, and
there could be simplifications in some implementations by reusing the there could be simplifications in some implementations by reusing the
same interval. TCP defines a default user timeout of 5 minutes same interval. TCP defines a default user timeout of 5 minutes
[RFC0793] i.e. how long transmitted data may remain unacknowledged [RFC0793] i.e. how long transmitted data may remain unacknowledged
before a connection is forcefully closed. before a connection is forcefully closed.
skipping to change at page 16, line 7 skipping to change at page 15, line 33
6928. This is justified by the recent path history. 6928. This is justified by the recent path history.
3) new-CWV is attended to also be used for rate-limited 3) new-CWV is attended to also be used for rate-limited
applications, where the application sends, but does not seek to applications, where the application sends, but does not seek to
fully utilise the cwnd. In this case, new-cwv constrains the fully utilise the cwnd. In this case, new-cwv constrains the
cwnd to that justified by the recent path history. The cwnd to that justified by the recent path history. The
performance trade-offs are hence different, and it would be performance trade-offs are hence different, and it would be
possible to enable new-cwv when also using the method in RFC possible to enable new-cwv when also using the method in RFC
6928, and yield benefits. 6928, and yield benefits.
o There is potential overlap with the Laminar proposal o There is potential overlap with the Laminar proposal (draft-
(draft-mathis-tcpm-tcp-laminar) mathis-tcpm-tcp-laminar)
The current draft was intended as a standards-track update to The current draft was intended as a standards-track update to
TCP, rather than a new transport variant. At least, it would TCP, rather than a new transport variant. At least, it would
be good to understand how the two interact and whether there is be good to understand how the two interact and whether there is
a possibility of a single method. a possibility of a single method.
o There is potential performance loss in loss of a short burst o There is potential performance loss in loss of a short burst
(off list with M Allman) (off list with M Allman)
A sender can transmit several segments then become idle. If A sender can transmit several segments then become idle. If
the first segments are all ACK'ed the ssthresh collapses to a the first segments are all ACK'ed the ssthresh collapses to a
small value (no new data is sent by the idle sender). Loss of small value (no new data is sent by the idle sender). Loss of
the later data results in congestion (e.g. maybe a RED drop or the later data results in congestion (e.g. maybe a RED drop or
some other cause, rather than the maximum rate of this flow). some other cause, rather than the maximum rate of this flow).
When the sender performs loss recovery it may have an When the sender performs loss recovery it may have an
appreciable pipeACK and cwnd, but a very low FlightSize - the appreciable pipeACK and cwnd, but a very low FlightSize - the
Standard algorithm results in an unusually low cwnd (1/2 Standard algorithm results in an unusually low cwnd ((1/2)*
FlightSize). FlightSize).
A constant rate flow would have maintained a FlightSize A constant rate flow would have maintained a FlightSize
appropriate to pipeACK (cwnd if it is a bulk flow). appropriate to pipeACK (cwnd if it is a bulk flow).
This could be fixed by adding a new state variable? It could This could be fixed by adding a new state variable? It could
also be argued this is a corner case (e.g. loss of only the also be argued this is a corner case (e.g. loss of only the
last segments would have resulted in RTO), the impact could be last segments would have resulted in RTO), the impact could be
significant. significant.
skipping to change at page 18, line 47 skipping to change at page 18, line 25
WG draft 04 contained: WG draft 04 contained:
o Editorial corrections. o Editorial corrections.
o Introduced the "cwnd-limited" term. o Introduced the "cwnd-limited" term.
o An adjustment to the procedure at the start of a cwnd-limited o An adjustment to the procedure at the start of a cwnd-limited
phase - the new text is intended to ensure that new-cwv is not phase - the new text is intended to ensure that new-cwv is not
unnecessarily more conservative than standard TCP when the flow is unnecessarily more conservative than standard TCP when the flow is
cwnd-limited. This resolves two issues: first it prevents cwnd-limited. This resolves two issues: first it prevents
pathologies in which pipeACK increases slowly and eraticaly. It pathologies in which pipeACK increases slowly and eratically. It
also ensures that performance of bulk applications is not also ensures that performance of bulk applications is not
significantly impacted when using the method. significantly impacted when using the method.
o Clearly identifies that pacing (or equivalent) is requiring during o Clearly identifies that pacing (or equivalent) is requiring during
the NVP to control bustiness. New section added. the NVP to control burstiness. New section added.
WG draft 05 contained:
o Clarification to first two bullets in section 4.4 describing cwnd-
limited, to explain these are really alternates to the same case.
o Section giving implementation examples was restructured to clarify
there are two methods described.
o Cross References to sections updated - thanks to comments from
Martin Winbjoerk and Tim Wicinski.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
Window Validation", RFC 2861, June 2000. Window Validation", RFC 2861, June 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP", RFC
RFC 3168, September 2001. 3168, September 2001.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003. Recovery Algorithm for TCP", RFC 3517, April 2003.
[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.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298, June
June 2011. 2011.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, April 2013. "Increasing TCP's Initial Window", RFC 6928, April 2013.
10.2. Informative References 10.2. Informative References
[All05] "Notes on burst mitigation for transport protocols", [All05] and , "Notes on burst mitigation for transport protocols",
March 2005. March 2005.
[Bis08] Biswas and Fairhurst, "A Practical Evaluation of [Bis08] Biswas, and Fairhurst, "A Practical Evaluation of
Congestion Window Validation Behaviour, 9th Annual Congestion Window Validation Behaviour, 9th Annual
Postgraduate Symposium in the Convergence of Postgraduate Symposium in the Convergence of
Telecommunications, Networking and Broadcasting (PGNet), Telecommunications, Networking and Broadcasting (PGNet),
Liverpool, UK", June 2008. Liverpool, UK", June 2008.
[Bis10] Biswas, Sathiaseelan, Secchi, and Fairhurst, "Analysing [Bis10] Biswas, , Sathiaseelan, , Secchi, , and Fairhurst,
TCP for Bursty Traffic, Int'l J. of Communications, "Analysing TCP for Bursty Traffic, Int'l J. of
Network and System Sciences, 7(3)", June 2010. Communications, Network and System Sciences, 7(3)", June
2010.
[Bis11] Biswas, "PhD Thesis, Internet congestion control for [Bis11] Biswas, , "PhD Thesis, Internet congestion control for
variable rate TCP traffic, School of Engineering, variable rate TCP traffic, School of Engineering,
University of Aberdeen", June 2011. University of Aberdeen", June 2011.
[Fai12] Sathiaseelan, Secchi, Fairhurst, and Biswas, "Enhancing [Fai12] Sathiaseelan, , Secchi, , Fairhurst, , and Biswas,
TCP Performance to support Variable-Rate Traffic, 2nd "Enhancing TCP Performance to support Variable-Rate
Capacity Sharing Workshop, ACM CoNEXT, Nice, France, 10th Traffic, 2nd Capacity Sharing Workshop, ACM CoNEXT, Nice,
December 2012.", June 2008. France, 10th December 2012.", June 2008.
[Hug01] Hughes, Touch, and Heidemann, "Issues in TCP Slow-Start [Hug01] Hughes, , Touch, , and Heidemann, "Issues in TCP Slow-
Restart After Idle (Work-in-Progress)", December 2001. Start Restart After Idle (Work-in-Progress)", December
2001.
[Liu07] Liu, Allman, Jiny, and Wang, "Congestion Control without a [Liu07] Liu, , Allman, , Jiny, , and Wang, "Congestion Control
Startup Phase, 5th International Workshop on Protocols for without a Startup Phase, 5th International Workshop on
Fast Long-Distance Networks (PFLDnet), Los Angeles, Protocols for Fast Long-Distance Networks (PFLDnet), Los
California, USA", February 2007. Angeles, California, USA", February 2007.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen, Scotland AB24 3UE Aberdeen, Scotland AB24 3UE
UK UK
 End of changes. 44 change blocks. 
96 lines changed or deleted 137 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/