draft-ietf-tcpm-newcwv-05.txt   draft-ietf-tcpm-newcwv-06.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 February 4, 2014 Intended status: Experimental March 23, 2014
Expires: August 8, 2014 Expires: September 24, 2014
Updating TCP to support Rate-Limited Traffic Updating TCP to support Rate-Limited Traffic
draft-ietf-tcpm-newcwv-05 draft-ietf-tcpm-newcwv-06
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 provides an experimental update to TCP that
quickly following either an idle or rate-limited interval. This allows a TCP sender to restart quickly following either a rate-
method is expected to benefit applications that send rate-limited limited interval. This method is expected to benefit applications
traffic using TCP, while also providing an appropriate response if that send rate-limited traffic using TCP, while also providing an
congestion is experienced. appropriate response if congestion is experienced.
It also evaluates the Experimental specification of TCP Congestion It also evaluates the Experimental specification of TCP Congestion
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
consideration as either Experimental (EXP) or Proposed Standard (PS).
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 August 8, 2014.
This Internet-Draft will expire on September 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 4 1.1. Standards Status of this Document . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 5
4. An updated TCP response to idle and application-limited 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
periods . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Initialisation . . . . . . . . . . . . . . . . . . . . . 8
4.1. A method for preserving cwnd during the idle and 4.2. Estimating the validated capacity supported by a path . . 8
application-limited periods. . . . . . . . . . . . . . . 6 4.3. Preserving cwnd during a rate-limited period. . . . . . . 9
4.2. Initialisation . . . . . . . . . . . . . . . . . . . . . 7 4.4. TCP congestion control during the non-validated phase . . 9
4.3. The nonvalidated phase . . . . . . . . . . . . . . . . . 7 4.4.1. Response to congestion in the non-validated phase . . 11
4.4. TCP congestion control during the nonvalidated phase . . 7 4.4.2. Sender burst control during the non-validated phase . 12
4.4.1. Response to congestion in the nonvalidated phase . . 9 4.4.3. Adjustment at the end of the non-validated phase . . 13
4.4.2. Sender burst control during the nonvalidated phase . 10 4.5. Examples of Implementation . . . . . . . . . . . . . . . 13
4.4.3. Adjustment at the end of the nonvalidated phase . . . 10 4.5.1. Implementing the pipeACK measurement . . . . . . . . 13
4.5. Examples of Implementation . . . . . . . . . . . . . . . 11 4.5.2. Implementing detection of the cwnd-limited condition 15
4.5.1. Implementing pipeACK . . . . . . . . . . . . . . . . 11 5. Determining a safe period to preserve cwnd . . . . . . . . . 15
4.5.2. Implementing detection of the cwnd-limited condition 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Determining a safe period to preserve cwnd . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Other related work . . . . . . . . . . . . . . . . . . . 16
9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Revision notes . . . . . . . . . . . . . . . . . . . . . 19
9.1. Other related work . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Revision notes . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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
contrast, a rate-limited application will experience periods when the contrast, a rate-limited application will experience periods when the
sender is either idle or is unable to send at the maximum rate sender is either idle or is unable to send at the maximum rate
permitted by the cwnd. This latter case is called rate-limited. The permitted by the cwnd. The update in this document targets the
focus of this document is on the operation of TCP in such an idle or operation of TCP in such rate-limited cases.
rate-limited case.
Standard TCP [RFC5681] requires the cwnd to be reset to the restart Standard TCP [RFC5681] states that a TCP sender SHOULD set cwnd to no
window (RW) when an application becomes idle. [RFC2861] noted that more than the Restart Window (RW) before beginning transmission, if
this TCP behaviour was not always observed in current the TCP sender has not sent data in an interval exceeding the
implementations. Recent experiments [Bis08] confirm this to still be retransmission timeout, i..e when an application becomes idle.
the case. [RFC2861] noted that this TCP behaviour was not always observed in
current implementations. Experiments [Bis08] confirm this to still
be the case.
CWV introduced the terminology of "application limited periods".
This document describes any time that an application limits the
sending rate, rather than being limited by the transport, as "rate-
limited". This update improves support for applications that vary
their transmission rate, either with (short) idle periods between
transmission or by changing the rate the application sends. These
applications are characterised by the TCP FlightSize often being less
than cwnd. Many Internet applications exhibit this behaviour,
including web browsing, http-based adaptive streaming, applications
that support query/response type protocols, network file sharing, and
live video transmission. Many such applications currently avoid
using long-lived (persistent) TCP connections (e.g. [RFC2616] servers
typically support persistent HTTP connections, but short server
timeouts often prevent using it). Such applications often instead
either use a succession of short TCP transfers or use UDP.
Standard TCP does not impose additional restrictions on the growth of Standard TCP does not impose additional restrictions on the growth of
the cwnd when a TCP sender is rate-limited. A rate-limited sender the congestion window when a TCP sender is unable to send at the
may therefore grow a cwnd far beyond that corresponding to the maximum rate allowed by the cwnd. In this case the rate-limited
current transmit rate, resulting in a value that does not reflect sender may grow a cwnd far beyond that corresponding to the current
current information about the state of the network path the flow is transmit rate, resulting in a value that does not reflect current
using. Use of such an invalid cwnd may result in reduced application information about the state of the network path the flow is using.
Use of such an invalid cwnd may result in reduced application
performance and/or could significantly contribute to network performance and/or could significantly contribute to network
congestion. congestion.
[RFC2861] proposed a solution to these issues in an experimental [RFC2861] proposed a solution to these issues in an experimental
method known as Congestion Window Validation (CWV). CWV was intended method known as Congestion Window Validation (CWV). CWV was intended
to help reduce cases where TCP accumulated an invalid cwnd. The use to help reduce cases where TCP accumulated an invalid cwnd. The use
and drawbacks of using the CWV algorithm in RFC 2861 with an and drawbacks of using the CWV algorithm in RFC 2861 with an
application are discussed in Section 2. application are discussed in Section 2.
Section 3 defines relevant terminology. Section 3 defines relevant terminology.
Section 4 specifies an alternative to CWV that seeks to address the Section 4 specifies an alternative to CWV that seeks to address the
same issues, but does this in a way that is expected to mitigate the same issues, but does this in a way that is expected to mitigate the
impact on an application that varies its sending rate. The method impact on an application that varies its sending rate. The updated
described applies to both a rate-limited and an idle condition. method applies to the rate-limited conditions (including both an
application-limited and idle sender).
The goals of this update are:
o To not change the behaviour of a TCP sender that performs bulk
transfers that consume the cwnd.
o To provide a method that co-exists with Standard TCP and other
flows that use this updated method.
o To reduce transfer latency for applications that change their rate
over short intervals of time.
o To avoid a TCP sender growing a large "non-validated" cwnd, when
it has not recently sent using this cwnd.
o To remove the incentive for ad-hoc application or network stack
methods (such as "padding") solely to maintain a large cwnd for
future transmission.
o To incentivise the use of long-lived connections, rather than a
succession of short-lived flows, benefiting both flows and network
when actual congestion is encountered.
Section 5 describes the rationale for selecting the safe period to Section 5 describes the rationale for selecting the safe period to
preserve the cwnd. preserve the cwnd.
1.1. Standards Status of this Document
This document was produced by the TCP Maintenance and Minor
Extensions (tcpm) working group.
The document updates and obsoletes the methods described in
[RFC2861]. It recommends a set of mechanisms, including the use of
pacing during a non-validated period. The updated mechanisms are
intended to have a less aggressive congestion impact than would be
exhibited by a standard TCP sender.
The specification in this draft is classified as "Experimental"
pending experience with deployed implementations of the methods.
2. Reviewing experience with TCP-CWV 2. Reviewing experience with TCP-CWV
RFC 2861 described a simple modification to the TCP congestion [RFC2861] described a simple modification to the TCP congestion
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 where a sender
session where a sender transmitted at a rate less than allowed by transmitted at a rate less than allowed by cwnd.
cwnd.
RFC 2861 has been implemented in some mainstream operating systems as [RFC2861] proposed two set of responses, one after an "application-
the default behaviour [Bis08]. Analysis (e.g. [Bis10] [Fai12]) has limited" and one after an "idle period". Although this distinction
shown that a TCP sender using CWV is able to use available capacity was argued, in practice differentiating the two conditions was found
on a shared path after an idle period. This can benefit some problematic in actual networks (e.g.[Bis10]). This offers
applications, especially over long delay paths, when compared to the predictable performance for long on-off periods (>>1 RTT), or slowly
slow-start restart specified by standard TCP. However, CWV would varying rate-based traffic, the performance could be unpredictable
only benefit an application if the idle period were less than several for variable-rate traffic and depended both upon whether an accurate
Retransmission Time Out (RTO) intervals [RFC6298], since the RTT had been obtained and the pattern of application traffic relative
behaviour would otherwise be the same as for standard TCP, which to the measured RTT.
resets the cwnd to the RTCP Restart Window (RW) after this period.
Experience with RFC 2861 suggests that although the CWV method Many applications can and often do vary their transmission over a
wide range rates. Using [RFC2861] such applications often
experienced varying performance, which made it hard for application
developers to predict the TCP latency even when using a path with
stable network characteristics. We argue that an attempt to classify
application behaviour as application-limited or idle is problematic
and also inappropriate. This document therefore explicitly avoids
trying to differentiate these two cases, instead treating all rate-
limited traffic uniformly.
[RFC2861] has been implemented in some mainstream operating systems
as the default behaviour [Bis08]. Analysis (e.g. [Bis10] [Fai12])
has shown that a TCP sender using CWV is able to use available
capacity on a shared path after an idle period. This can benefit
variable-rate applications, especially over long delay paths, when
compared to the slow-start restart specified by standard TCP.
However, CWV would only benefit an application if the idle period
were less than several Retransmission Time Out (RTO) intervals
[RFC6298], since the behaviour would otherwise be the same as for
standard TCP, which resets the cwnd to the TCP Restart Window after
this period.
To enable better performance for variable-rate applications with TCP,
some operating systems have chosen to support non-standard methods,
or applications have resorted to "padding" streams to maintain their
sending rate when they have no data to transmit. Although
transmitting redundant data across a network path provides good
evidence that the path can sustain data at the offered rate, padding
also consumes network capacity and reduces the opportunity for
congestion-free statistical multiplexing. For variable-rate flows,
the benefits of statistical multiplexing can be significant and it is
therefore a goal to find a viable alternative to padding streams.
Experience with [RFC2861] suggests that although the CWV method
benefited the network in a rate-limited scenario (reducing the benefited the network in a rate-limited scenario (reducing the
probability of network congestion), the behaviour was too probability of network congestion), the behaviour was too
conservative for many common rate-limited applications. This conservative for many common rate-limited applications. This
mechanism did not therefore offer the desirable increase in mechanism did not therefore offer the desirable increase in
application performance for rate-limited applications and it is application performance for rate-limited applications and it is
unclear whether applications actually use this mechanism in the unclear whether applications actually use this mechanism in the
general Internet. general Internet.
It is therefore concluded that CWV, as defined in RFC2681, was often It is therefore concluded that CWV, as defined in [RFC2861], was
a poor solution for many rate-limited applications. It had the often a poor solution for many rate-limited applications. It had the
correct motivation, but had the wrong approach to solving this correct motivation, but had the wrong approach to solving this
problem. problem.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The 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 terminology is used in this document:
cwnd-limited: A TCP flow that has sent the maximum number of segments cwnd-limited: A TCP flow that has sent the maximum number of segments
permitted by the cwnd, where the application utilises the allowed permitted by the cwnd, where the application utilises the allowed
sending rate (see section 4.5.2). sending rate (see Section 4.5.2).
pipeACK sample: A measure 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.
Non-validated period, NVP: The maximum period for which cwnd is Non-validated period, NVP: The maximum period for which cwnd is
preserved in the non-validated phase. preserved in the non-validated phase.
Rate-limited: A TCP flow that does not consume more than one half of Rate-limited: A TCP flow that does not consume more than one half of
cwnd, and hence operates in the non-validated phase. cwnd, and hence operates in the non-validated phase. This includes
periods when an application is either idle or chooses to send at a
rate less than the maximum permitted by the cwnd.
Validated phase: The phase where the cwnd reflects a current estimate Validated phase: The phase where the cwnd reflects a current estimate
of the available path capacity. of the available path capacity.
4. An updated TCP response to idle and application-limited periods 4. A New Congestion Window Validation method
This section proposes an update to the TCP congestion control This section proposes an update to the TCP congestion control
behaviour during a rate-limited period. The new method permits a TCP behaviour during a rate-limited interval. This new method
sender to preserve the cwnd when an application becomes idle or when intentionally does not differentiate between times when the sender
the sender is unable to send at the maximum rate permitted by the has become idle or chooses to send at a rate less than the maximum
cwnd (the non-validated period, NVP, see section 5). The period allowed by the cwnd.
where actual usage is less than allowed by cwnd, is named as the non-
validated phase. This method allows an application to resume The period where actual usage is less than allowed by cwnd, is named
transmission at a previous rate without incurring the delay of slow- as the non-validated phase. The update allows an application in the
start. However, if the TCP sender experiences congestion using the non-validated phase to resume transmission at a previous rate without
preserved cwnd, it is required to immediately reset the cwnd to an incurring the delay of slow-start. However, if the TCP sender
appropriate value specified by the method. If a sender does not take experiences congestion using the preserved cwnd, it is required to
advantage of the preserved cwnd within the NVP, the value of cwnd is immediately reset the cwnd to an appropriate value specified by the
reduced, ensuring the value better reflects the capacity that was method. If a sender does not take advantage of the preserved cwnd
recently actually used. within the NVP, the value of cwnd is reduced, ensuring the value
better reflects the capacity that was recently actually used.
It is expected that this update will satisfy the requirements of many It is expected that this update will satisfy the requirements of many
rate-limited applications and at the same time provide an appropriate rate-limited applications and at the same time provide an appropriate
method for use in the Internet. It also reduces the incentive for an method for use in the Internet. Some applications use dummy packets
(aka "padding") to maintain a sending rate when an application has
now data to send. Although this ensures the path continues to
support the rate permitted by the cwnd, it wastes network capacity
sending useless data. New-CWV reduces this incentive for an
application to send data simply to keep transport congestion state. application to send data simply to keep transport congestion state.
(This is sometimes known as "padding").
The new method does not differentiate between times when the sender The method is specified in following subsections and is expected to
has become idle or rate-limited. This is partly a response to encourage applications and TCP stacks to use standards-based
recognition that some applications wish to transmit at a rate less congestion control methods. It may also encourage the use of long-
than allowed by the sender cwnd, and that it can be hard to make a lived connections where this offers benefit (such as persistent
distinction between rate-limited and idle behaviour. This is
expected to encourage applications and TCP stacks to use standards-
based congestion control methods. It may also encourage the use of
long-lived connections where this offers benefit (such as persistent
http). http).
The method is specified in following subsections. 4.1. Initialisation
4.1. A method for preserving cwnd during the idle and application- A sender starts a TCP connection in the validated phase and
limited periods. initialises the pipeACK variable to the "undefined" value. This
value inhibits use of the value in cwnd calculations.
[RFC5681] defines a variable, FlightSize, that indicates the amount 4.2. Estimating the validated capacity supported by a path
of outstanding data in the network. This is assumed to be equal to
the value of Pipe calculated based on the pipe algorithm [RFC3517]. [RFC6675] defines a variable, FlightSize, that indicates the
In RFC5681 this value is used during loss recovery, whereas in this instantaneous amount of data that has been sent, but not cumulatively
method a new variable "pipeACK" is introduced to measure the acknowledged. In this method a new variable "pipeACK" is introduced
acknowledged size of the pipe, which is used to determine if the to measure the acknowledged size of the network pipe. This is used
sender has validated the cwnd. to determine if the sender has validated the cwnd. pipeACK differs
from FlightSize in that it is evaluated over a window of acknowledged
data, rather than reflecting the amount of data outstanding.
A sender determines a pipeACK sample by measuring the volume of data A sender determines a pipeACK sample by measuring the volume of data
that was acknowledged by the network over the period of a measured that was acknowledged by the network over the period of a measured
Round Trip Time (RTT). Using the variables defined in [RFC3517], a Round Trip Time (RTT). Using the variables defined in [RFC6675], a
value could be measured by caching the value of HighACK and after one value could be measured by caching the value of HighACK and after one
RTT measuring the difference between the cached HighACK value and the RTT measuring the difference between the cached HighACK value and the
current HighACK value. Other equivalent methods may be used. current HighACK value. Other equivalent methods may be used.
A sender is not required to continuously update the pipeACK variable A sender is not required to continuously update the pipeACK variable
after each received ACK, but SHOULD perform a pipeACK sample at least after each received ACK, but SHOULD perform a pipeACK sample at least
once per RTT when it has sent unacknowledged segments. once per RTT when it has sent unacknowledged segments.
The pipeACK variable MAY consider multiple pipeACK samples over the The pipeACK variable MAY consider multiple pipeACK samples over the
pipeACK Sampling Period. The value of the pipeACK variable MUST NOT pipeACK Sampling Period. The value of the pipeACK variable MUST NOT
exceed the maximum (highest value) within the sampling period. This exceed the maximum (highest value) within the sampling period. This
specification defines the pipeACK Sampling Period as Max(3*RTT, 1 specification defines the pipeACK Sampling Period as Max(3*RTT, 1
second). This period enables a sender to compensate for large second). This period enables a sender to compensate for large
fluctuations in the sending rate, where there may be pauses in fluctuations in the sending rate, where there may be pauses in
transmission, and allows the pipeACK variable to reflect the largest transmission, and allows the pipeACK variable to reflect the largest
recently measured pipeACK sample. recently measured pipeACK sample.
When no measurements are available, the pipeACK variable is set to When no measurements are available, the pipeACK variable is set to
the "undefined value". This value is used to inhibit entering the the "undefined value". This value is used to inhibit entering the
nonvalidated phase until the first new measurement of a pipeACK non-validated phase until the first new measurement of a pipeACK
sample. sample.
The method RECOMMENDS that the TCP SACK option [RFC3517] is enabled. The pipeACK variable MUST NOT be updated during TCP Fast Recovery.
This allows the sender to more accurately determine the number of That is, the sender stops collecting pipeACK samples during loss
missing bytes during the loss recovery phase, and using this method recovery. The method RECOMMENDS that the TCP SACK option [RFC2018]
will result in a higher cwnd following loss. is enabled and the method defined on [RFC6675]is used to recover
missing segments. This allows the sender to more accurately
4.2. Initialisation determine the number of missing bytes during the loss recovery phase,
and using this method will result in a more appropriate cwnd
A sender starts a TCP connection in the Validated phase and following loss.
initialises the pipeACK variable to the "undefined" value. This
value inhibits use of the value in cwv calculations.
4.3. The nonvalidated phase 4.3. Preserving cwnd during a rate-limited period.
The updated method creates a new TCP sender phase that captures The updated method creates a new TCP sender phase that captures
whether the cwnd reflects a validated or non-validated value. The whether the cwnd reflects a validated or non-validated value. The
phases are defined as: phases are defined as:
o Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined. o Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined.
This is the normal phase, where cwnd is expected to be an This is the normal phase, where cwnd is expected to be an
approximate indication of the capacity currently available along approximate indication of the capacity currently available along
the network path, and the standard methods are used to increase the network path, and the standard methods are used to increase
cwnd (currently [RFC5681]). The rule for transitioning to the cwnd (currently [RFC5681]).
non-validated phase is specified in section 4.4.
o Non-validated phase: pipeACK <(1/2)*cwnd. This is the phase where o Non-validated phase: pipeACK <(1/2)*cwnd. This is the phase where
the cwnd has a value based on a previous measurement of the the cwnd has a value based on a previous measurement of the
available capacity, and the usage of this capacity has not been available capacity, and the usage of this capacity has not been
validated in the pipeACK Sampling Period. That is, when it is not validated in the pipeACK Sampling Period. That is, when it is not
known whether the cwnd reflects the currently available capacity known whether the cwnd reflects the currently available capacity
along the network path. The mechanisms to be used in this phase along the network path. The mechanisms to be used in this phase
seek to determine a safe value for cwnd and an appropriate seek to determine a safe value for cwnd and an appropriate
reaction to congestion. These mechanisms are specified in section reaction to congestion.
4.4.
The value 1/2 was selected to reduce the effects of variations in the Note: A threshold is needed to determine whether a sender is in the
pipeACK variable, and to allow the sender some flexibility in when it validated or non-validated phase. We start by noting that a standard
sends data. TCP sender in slow-start is permitted to double its FlightSize from
one RTT to the next. This motivated the choice of a threshold value
of 1/2. This threshold ensures a sender does not further increase
the cwnd as long as the FlightSize is less than (1/2*cwnd).
Furthermore, a sender with a FlightSize less than (1/2*cwnd) may in
the next RTT be permitted by the cwnd to send at a rate that more
than doubles the FlightSize, and hence this case needs to be regarded
as non-validated and a sender therefore needs to employ additional
mechanisms while in this phase.
4.4. TCP congestion control during the nonvalidated phase 4.4. TCP congestion control during the non-validated 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 SHOULD 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.3) 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. the sender 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 sender determines whether to increase the cwnd based upon o A sender determines whether to increase the cwnd based upon
whether it is cwnd-limited (see section 4.5.2): whether it is cwnd-limited (see Section 4.5.2):
o o
* A sender that is cwnd-limited MAY use the standard TCP method * A sender that is cwnd-limited MAY use the standard TCP method
to increase cwnd (i.e. a TCP sender that fully utilises the to increase cwnd (i.e. a TCP sender that fully utilises the
cwnd is permitted to increase cwnd each received ACK using cwnd is permitted to increase cwnd each received ACK using
standard methods). standard methods).
* A sender that is not cwnd-limited MUST NOT increase the cwnd * A sender that is not cwnd-limited MUST NOT increase the cwnd
when ACK packets are received in this phase. 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.4.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].
resulting reduction of cwnd described in section 4.4.3 is
appropriate, since any accumulated path history is considered
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 The cwnd-limited behaviour may be triggered during a transient
condition that occurs when a sender is in the non-validated phase and condition that occurs when a sender is in the non-validated phase and
receives an ACK that acknowledges received data, the cwnd was fully receives an ACK that acknowledges received data, the cwnd was fully
utilised, and more data is awaiting transmission than may be sent utilised, and more data is awaiting transmission than may be sent
with the current cwnd. The sender is then allowed to use the with the current cwnd. The sender is then allowed to use the
standard method to increase the cwnd. (Note, if the sender suceeds standard method to increase the cwnd. (Note, if the sender succeeds
in sending these new segments, the updated cwnd and pipeACK variables in sending these new segments, the updated cwnd and pipeACK variables
will eventually result in a transition to the validated phase.) 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 non-validated 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
ECN marked packet, MUST record the current FlightSize in the variable ECN marked packet, MUST record the current FlightSize in the variable
LossFlightSize and MUST calculate a safe cwnd for loss recovery using LossFlightSize and MUST calculate a safe cwnd for loss recovery using
the method below: the method below:
cwnd = (Max(pipeACK,LossFlightSize))/2. cwnd = (Max(pipeACK,LossFlightSize))/2.
If there is a valid pipeACK value, the new cwnd is adjusted to The pipeACK value is not updated during loss recoverySection 4.2. If
reflect that a nonvalidated cwnd may be larger than the actual there is a valid pipeACK value, the new cwnd is adjusted to reflect
FlightSize, or recently used FlightSize (recorded in pipeACK). The that a non-validated cwnd may be larger than the actual FlightSize,
updated cwnd therefore prevents overshoot by a sender significantly or recently used FlightSize (recorded in pipeACK). The updated cwnd
increasing its transmission rate during the recovery period. therefore prevents overshoot by a sender significantly 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.
[Liu07]. The inclusion of the term R makes an adjustment more
conservative than standard TCP. (This is required, since the sender
may have sent more segments than a standard TCP sender would have
done. The additional reduction is beneficial when the LossFlightSize
significantly overshoots the available path capacity incurring
significant loss, for instance an intense traffic burst following a
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 After completing the loss recovery phase, the sender MUST re-
"undefined" value. This ensures that standard TCP methods are used initialise the pipeACK variable to the "undefined" value. This
immediately after completing loss recovery until a new pipeACK value ensures that standard TCP methods are used immediately after
can be determined. completing loss recovery until a new pipeACK value 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 Note: The adjustment by reducing cwnd by the volume of data not sent
(R) follows the method proposed for Jump Start [Liu07]. The
inclusion of the term R makes the adjustment more conservative than
standard TCP. This is required, since a sender in the non-validated
state may increase the rate more than a standard TCP would have done
relative to what was sent in the last RTT (i.e., more than doubled
the number of segments in flight relative to what it sent in the last
RTT). The additional reduction after congestion is beneficial when
the LossFlightSize has significantly overshot the available path
capacity incurring significant loss (e.g. following a change of path
characteristics or when additional traffic has taken a larger share
of the network bottleneck during a period when the sender transmits
less).
Note: The pipeACK value is only valid during a non-validated phase,
and therefore does not exceed cwnd/2. If LossFlightSize and R were
small, then this can result in the final cwnd after loss recovery
being not more than 1/4 of the cwnd on detection of congestion. This
reduction is conservative compared to standard TCP. pipeACK is reset
to undefined after completing loss recovery. Subsequent updates to
cwnd do not therefore reflect pipeACK history before any congestion
event.
4.4.2. Sender burst control during the non-validated 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 burst 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 burstiness 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 of segments it sends per received ACK. This is effective when a flow 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 interval 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
TCP/IP stack, speed of interface and whether hardware support (such TCP/IP stack, speed of interface and whether hardware support (such
as TCP Segment Offload, TSO) is used. The present document does not as TCP Segment Offload, TSO) is used. The present document does not
recommend any specific method. recommend any specific method.
4.4.3. Adjustment at the end of the nonvalidated phase 4.4.3. Adjustment at the end of the non-validated phase
An application that remains in the non-validated phase for a period An application that remains in the non-validated phase for a period
greater than the NVP is required to adjust its congestion control greater than the NVP is required to adjust its congestion control
state. If the sender exits the non-validated phase after this state. If the sender exits the non-validated phase after this
period, it MUST update the ssthresh: period, it MUST update the ssthresh:
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
skipping to change at page 11, line 8 skipping to change at page 13, line 27
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 Note: This adjustment ensures that the sender responds conservatively
end of the non-validated phase by reducing the cwnd to better reflect after remaining in the non-validated phase for more than the non-
the current rate of the sender. The cwnd update does not take into validated period. In this case, it reduces the cwnd by a factor of
account FlightSize or pipeACK value because these values only reflect two from the preserved value. This adjustment is helpful when flows
historical data and do not reflect the current sending rate.) accumulate but do not use a large cwnd, and seeks to mitigate the
impact when these flows later resume transmission. This could for
instance mitigate the impact if multiple high-rate application flows
were to become idle over an extended period of time and then were
simultaneously awakened by some external event.
4.5. Examples of Implementation 4.5. Examples of Implementation
This section provides informative examples of implementation methods. This section provides informative examples of implementation methods.
Implementations may choose to use other methods that comply with the Implementations may choose to use other methods that comply with the
normative requirements. normative requirements.
4.5.1. Implementing pipeACK 4.5.1. Implementing the pipeACK measurement
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 23 skipping to change at page 14, line 47
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 pipeACK Sampling Period and the NVP period do not Note that the pipeACK Sampling Period and the NVP period do not
necessarily require a new timer to be implemented. An alternative is necessarily require a new timer to be implemented. An alternative is
to record a timestamp when the sender enters the NVP. Each time a to record a timestamp when the sender enters the NVP. Each time a
sender transmits a new segment, this timestamp may be used to sender transmits a new segment, this timestamp may be used to
determine if the NVP period has expired. If the period expires, the determine if the NVP period has expired. If the period expires, the
sender may take into account how many units of the NVP period have sender may take into account how many units of the NVP period have
passed and make one reduction (as defined in section 4.4.3) for each passed and make one reduction (as defined in Section 4.4.3) for each
NVP period. NVP period.
4.5.2. Implementing detection of the cwnd-limited condition 4.5.2. Implementing detection of the cwnd-limited condition
A method is required to detect the cwnd-limited condition (see A method is required to detect the cwnd-limited condition (see
section 4.4). This is used to detect a condition where a sender in Section 4.4. This is used to detect a condition where a sender in
the non-validated phase receives an ACK, but the size of cwnd the non-validated phase receives an ACK, but the size of cwnd
prevents sending more new data. prevents sending more new data.
In simple terms this condition is true only when the TCP sender's In simple terms this condition is true only when the TCP sender's
FlightSize is equal to or larger than the cwnd. However, an FlightSize is equal to or larger than the cwnd. However, an
implementation must consider other constraints on the way in which implementation must consider other constraints on the way in which
cwnd variable is used, for instance the need to support methods such cwnd variable is used, for instance the need to support methods such
as the Nagle Algorithm and TCP Segment Offload (TSO). This can as the Nagle Algorithm and TCP Segment Offload (TSO). This can
result in a sender becoming cwnd-limited when the cwnd is nearly, result in a sender becoming cwnd-limited when the cwnd is nearly,
rather than completely, equal to the FlightSize. rather than completely, equal to the FlightSize.
skipping to change at page 14, line 15 skipping to change at page 16, line 39
7. IANA Considerations 7. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
8. Acknowledgments 8. Acknowledgments
The authors acknowledge the contributions of Dr I Biswas, Mr Ziaul The authors acknowledge the contributions of Dr I Biswas, Mr Ziaul
Hossain in supporting the evaluation of CWV and for their help in Hossain in supporting the evaluation of CWV and for their help in
developing the mechanisms proposed in this draft. We also developing the mechanisms proposed in this draft. We also
acknowledge comments received from the Internet Congestion Control acknowledge comments received from the Internet Congestion Control
Research Group, in particular Yuchung Cheng, Mirja Kuehlewind, and Research Group, in particular Yuchung Cheng, Mirja Kuehlewind, Joe
Joe Touch. This work was part-funded by the European Community under Touch, and Mark Allman. This work was part-funded by the European
its Seventh Framework Programme through the Reducing Internet Community under its Seventh Framework Programme through the Reducing
Transport Latency (RITE) project (ICT-317700). Internet Transport Latency (RITE) project (ICT-317700).
9. Author Notes 9. Author Notes
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
9.1. Other related work 9.1. Other related work
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
There are several issues to be discussed more widely: There are several issues to be discussed more widely:
skipping to change at page 16, line 26 skipping to change at page 18, line 44
significant. significant.
o There is potential interaction with TCP Control Block Sharing(M o There is potential interaction with TCP Control Block Sharing(M
Welzl) Welzl)
An application that is non-validated can accumulate a cwnd that An application that is non-validated can accumulate a cwnd that
is larger than the actual capacity. Is this a fair value to is larger than the actual capacity. Is this a fair value to
use in TCB sharing? use in TCB sharing?
We propose that TCB sharing should use the pipeACK in place of We propose that TCB sharing should use the pipeACK in place of
cwnd when a TCP sender is in the Nonvalidated phase. This cwnd when a TCP sender is in the Non-validated phase. This
value better reflects the capacity that the flow has utilised value better reflects the capacity that the flow has utilised
in the network path. in the network path.
9.2. Revision notes 9.2. Revision notes
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
Draft 03 was submitted to ICCRG to receive comments and feedback. Draft 03 was submitted to ICCRG to receive comments and feedback.
Draft 04 contained the first set of clarifications after feedback: Draft 04 contained the first set of clarifications after feedback:
skipping to change at page 17, line 41 skipping to change at page 20, line 15
o Added note on intended status still to be determined. o Added note on intended status still to be determined.
WG draft 01 contained: WG draft 01 contained:
o Added corrections from Richard Scheffenegger. o Added corrections from Richard Scheffenegger.
o Raffaello Secchi added to the mechanism, based on implementation o Raffaello Secchi added to the mechanism, based on implementation
experience. experience.
o Removed that the requirement for the method to use TCP SACK option o Removed that the requirement for the method to use TCP SACK option
[RFC3517] to be enabled - Although it may be desirable to use
SACK, this is not essential to the algorithm. o Although it may be desirable to use SACK, this is not essential to
the algorithm.
o Added the notion of the sampling period to accommodate large rate o Added the notion of the sampling period to accommodate large rate
variations and ensure that the method is stable. This algorithm variations and ensure that the method is stable. This algorithm
to be validated through implementation. to be validated through implementation.
WG draft 02 contained: WG draft 02 contained:
o Clarified language around pipeACK variable and pipeACK sample - o Clarified language around pipeACK variable and pipeACK sample -
Feedback from Aris Angelogiannopoulos. Feedback from Aris Angelogiannopoulos.
WG draft 03 contained: WG draft 03 contained:
o Editorial corrections - Feedback from Anna Brunstrom. o Editorial corrections - Feedback from Anna Brunstrom.
o An adjustment to the procedure at the start and end of loss o An adjustment to the procedure at the start and end of Reoloss
recovery to align the two equations. recovery to align the two equations.
o Further clarification of the "undefined" value of the pipeACK o Further clarification of the "undefined" value of the pipeACK
variable. variable.
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 eratically. It pathologies in which pipeACK increases slowly and erratically. 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 burstiness. New section added. the NVP to control burstiness. New section added.
WG draft 05 contained: WG draft 05 contained:
o Clarification to first two bullets in section 4.4 describing cwnd- o Clarification to first two bullets in Section 4.4 describing cwnd-
limited, to explain these are really alternates to the same case. limited, to explain these are really alternates to the same case.
o Section giving implementation examples was restructured to clarify o Section giving implementation examples was restructured to clarify
there are two methods described. there are two methods described.
o Cross References to sections updated - thanks to comments from o Cross References to sections updated - thanks to comments from
Martin Winbjoerk and Tim Wicinski. Martin Winbjoerk and Tim Wicinski.
WG draft 06 contained:
o The section giving implementation examples was restructured to
clarify there are two methods described.
o Justification of design decisions.
o Re-organised text to improve clarity of argument.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[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", RFC of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001. 3168, September 2001.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss
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, [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
"Computing TCP's Retransmission Timer", RFC 6298, June and Y. Nishida, "A Conservative Loss Recovery Algorithm
2011. Based on Selective Acknowledgment (SACK) for TCP", RFC
6675, August 2012.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, April 2013.
10.2. Informative References 10.2. Informative References
[All05] and , "Notes on burst mitigation for transport protocols", [All05] Allman, M. and E. Blanton, "Notes on burst mitigation for
March 2005. transport protocols", March 2005.
[Bis08] Biswas, and Fairhurst, "A Practical Evaluation of [Bis08] Biswas, I. and G. 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, [Bis10] Biswas, I., Sathiaseelan, A., Secchi, R., and G.
"Analysing TCP for Bursty Traffic, Int'l J. of Fairhurst, "Analysing TCP for Bursty Traffic, Int'l J. of
Communications, Network and System Sciences, 7(3)", June Communications, Network and System Sciences, 7(3)", June
2010. 2010.
[Bis11] Biswas, , "PhD Thesis, Internet congestion control for [Bis11] Biswas, I., "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, [Fai12] Sathiaseelan, A., Secchi, R., Fairhurst, G., and I.
"Enhancing TCP Performance to support Variable-Rate Biswas, "Enhancing TCP Performance to support Variable-
Traffic, 2nd Capacity Sharing Workshop, ACM CoNEXT, Nice, Rate Traffic, 2nd Capacity Sharing Workshop, ACM CoNEXT,
France, 10th December 2012.", June 2008. Nice, France, 10th December 2012.", June 2008.
[Hug01] Hughes, , Touch, , and Heidemann, "Issues in TCP Slow- [Hug01] Hughes, A., Touch, J., and J. Heidemann, "Issues in TCP
Start Restart After Idle (Work-in-Progress)", December Slow-Start Restart After Idle (Work-in-Progress)",
2001. December 2001.
[Liu07] Liu, , Allman, , Jiny, , and Wang, "Congestion Control [Liu07] Liu, D., Allman, M., Jiny, S., and L. Wang, "Congestion
without a Startup Phase, 5th International Workshop on Control without a Startup Phase, 5th International
Protocols for Fast Long-Distance Networks (PFLDnet), Los Workshop on Protocols for Fast Long-Distance Networks
Angeles, California, USA", February 2007. (PFLDnet), Los Angeles, California, USA", February 2007.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, June
2011.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, April 2013.
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. 71 change blocks. 
208 lines changed or deleted 335 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/