draft-ietf-tcpm-newcwv-02.txt   draft-ietf-tcpm-newcwv-03.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 July 01, 2013 Intended status: Standards Track October 10, 2013
Expires: January 2, 2014 Expires: April 13, 2014
Updating TCP to support Rate-Limited Traffic Updating TCP to support Rate-Limited Traffic
draft-ietf-tcpm-newcwv-02 draft-ietf-tcpm-newcwv-03
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 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2014. This Internet-Draft will expire on April 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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. Adjustment at the end of the nonvalidated phase . . . 10 4.4.2. Adjustment at the end of the nonvalidated phase . . . 10
4.4.3. Examples of Implementation . . . . . . . . . . . . . . 11 4.4.3. Examples of Implementation . . . . . . . . . . . . . . 11
5. Determining a safe period to preserve cwnd . . . . . . . . . . 12 5. Determining a safe period to preserve cwnd . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Other related work . . . . . . . . . . . . . . . . . . . . 14 9.1. Other related work . . . . . . . . . . . . . . . . . . . . 14
9.2. Revision notes . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Revision notes . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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 [RFC3517], 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 sample 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 maximum (undefined) value. This value is used to inhibit the "undefined value". This value is used to inhibit entering the
entering the nonvalidated phase until the first new measurement of a nonvalidated phase until the first new measurement of a pipeACK
pipeACK sample. sample.
The method RECOMMENDS that the TCP SACK option [RFC3517] is enabled. The method RECOMMENDS that the TCP SACK option [RFC3517] is enabled.
This allows the sender to more accurately determine the number of This allows the sender to more accurately determine the number of
missing bytes during the loss recovery phase, and using this method missing bytes during the loss recovery phase, and using this method
will result in a higher cwnd following loss. will result in a higher cwnd following loss.
4.2. Initialisation 4.2. Initialisation
A sender starts a TCP connection in the Validated phase and A sender starts a TCP connection in the Validated phase and
initialises the pipeACK variable to the maximum (undefined) value. initialises the pipeACK variable to the "undefined" value. This
value inhibts use of the value in cwv calculations.
4.3. The nonvalidated phase 4.3. The nonvalidated phase
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. This is the normal phase, o Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined.
where cwnd is expected to be an approximate indication of the This is the normal phase, where cwnd is expected to be an
capacity currently available along the network path, and the approximate indication of the capacity currently available along
standard methods are used to increase cwnd (currently [RFC5681]). the network path, and the standard methods are used to increase
The rule for transitioning to the non-validated phase is specified cwnd (currently [RFC5681]). The rule for transitioning to the
in section 4.3. 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. These mechanisms are specified in section
4.3. 4.4.
The value 1/2 was selected to reduce the effects of variations in the The value 1/2 was selected to reduce the effects of variations in the
pipeACK variable, and to allow the sender some flexibility in when it pipeACK variable, and to allow the sender some flexibility in when it
sends data. sends data.
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.3.2) or when fixed period of time (the NVP, as explained in section 4.4.2) 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 The cwnd is not increased when ACK packets are received in this o The cwnd is not increased when ACK packets are received in this
phase. 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
skipping to change at page 9, line 37 skipping to change at page 9, line 37
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 ECN marked packet A sender that detects a packet-drop, or receives an indication of an
MUST record the current FlightSize in the variable LossFlightSize and ECN marked packet, MUST record the current FlightSize in the variable
calculate a safe cwnd, by setting it to the value specified in LossFlightSize and MUST calculate a safe cwnd for loss recovery using
Section 3.2 of [RFC5681]. the method below:
cwnd = (Max(pipeACK,LossFlightSize))/2.
A TCP sender MUST calculate a safe cwnd to use for loss recovery
using the method below:
cwnd = Min(cwnd/2,Max(pipeACK,LossFlightSize)).
This new cwnd is set to reflect that a nonvalidated cwnd may be much This new cwnd is set to reflect that a nonvalidated cwnd may be
larger than the actual FlightSize, or recently used FlightSize larger than the actual FlightSize, or recently used FlightSize
(recorded in pipeACK). The updated cwnd therefore prevents overshoot (recorded in pipeACK). The updated cwnd therefore prevents overshoot
by a sender significantly increasing its transmission rate during the by a sender significantly increasing its transmission rate during the
recovery period. 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 = ((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 this 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
maximum (undefined) value. This ensures that standard TCP methods "undefined" value. This ensures that standard TCP methods are used
are used immediately after completing loss recovery. immediately after completing loss recovery until a new pipeACK value
can be determined.
4.4.2. Adjustment at the end of the nonvalidated phase 4.4.2. Adjustment at the end of the nonvalidated phase
During the non-validated phase, a sender can produce bursts of data During the non-validated phase, a sender can produce bursts of data
of up to the cwnd in size. While this is no different to standard of up to the cwnd in size. While this is no different to standard
TCP, it is desirable to control the maximum burst size, e.g. by TCP, it is desirable to control the maximum burst size, e.g. by
setting a burst size limit, using a pacing algorithm, or some other setting a burst size limit, using a pacing algorithm, or some other
method [Hug01]. method [Hug01].
An application that remains in the non-validated phase for a period An application that remains in the non-validated phase for a period
skipping to change at page 12, line 20 skipping to change at page 12, line 16
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.
The NVP period does not necessarily require a new timer to be Note that the NVP period does not necessarily require a new timer to
implemented. An alternative is to record a timestamp when the sender be implemented. An alternative is to record a timestamp when the
enters the NVP. Each time a sender transmits a new segment, this sender enters the NVP. Each time a sender transmits a new segment,
timestamp may be used to determine if the NVP period has expired. If this timestamp may be used to determine if the NVP period has
the period expires, the sender may take into account how many units expired. If the period expires, the sender may take into account how
of the NVP period have passed and make one reduction (as defined in many units of the NVP period have passed and make one reduction (as
section 4.3.2) for each NVP period. defined in section 4.3.2) for each NVP period.
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 17, line 46 skipping to change at page 17, line 42
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:
o Editorial corrections - Feedback from Anna Brunstrom.
o An adjustment to the procedure at the start and end of loss
recovery to align the two equations.
o Further clarification of the "undefined" value of the pipeACK
variable.
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 793, September 1981. RFC 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.
 End of changes. 17 change blocks. 
39 lines changed or deleted 48 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/