draft-ietf-tcpm-newcwv-03.txt   draft-ietf-tcpm-newcwv-04.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 October 10, 2013 Intended status: Standards Track December 16, 2013
Expires: April 13, 2014 Expires: June 19, 2014
Updating TCP to support Rate-Limited Traffic Updating TCP to support Rate-Limited Traffic
draft-ietf-tcpm-newcwv-03 draft-ietf-tcpm-newcwv-04
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 April 13, 2014. This Internet-Draft will expire on June 19, 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 18 skipping to change at page 3, line 18
2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 5 2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. An updated TCP response to idle and application-limited 4. An updated TCP response to idle and application-limited
periods . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 periods . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
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. . . . . . . . . . . . . . . . 7
4.2. Initialisation . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Initialisation . . . . . . . . . . . . . . . . . . . . . . 8
4.3. The nonvalidated phase . . . . . . . . . . . . . . . . . . 8 4.3. The nonvalidated phase . . . . . . . . . . . . . . . . . . 8
4.4. TCP congestion control during the nonvalidated phase . . . 8 4.4. TCP congestion control during the nonvalidated phase . . . 8
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. Sender burst control during the nonvalidated phase . . 10
4.4.3. Examples of Implementation . . . . . . . . . . . . . . 11 4.4.3. Adjustment at the end of the nonvalidated phase . . . 11
5. Determining a safe period to preserve cwnd . . . . . . . . . . 12 4.4.4. Examples of Implementation . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Determining a safe period to preserve cwnd . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 6, line 5 skipping to change at page 6, 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
by the cwnd, where the application utilises the allowed sending rate.
pipeACK sample: A meaure of the volume of data acknowledged by the pipeACK sample: A meaure 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
skipping to change at page 6, line 29 skipping to change at page 6, line 32
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.
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. An updated TCP response to idle and application-limited periods
This section proposes an update to the TCP congestion control This section proposes an update to the TCP congestion control
behaviour during an idle or rate-limited period. The new method behaviour during a rate-limited period. The new method permits a TCP
permits a TCP sender to preserve the cwnd when an application becomes sender to preserve the cwnd when an application becomes idle or when
idle for a period of time (the non-validated period, NVP, see section the sender is unable to send at the maximum rate permitted by the
5). The period where actual usage is less than allowed by cwnd, is cwnd (the non-validated period, NVP, see section 5). The period
named as the non-validated phase. This method allows an application where actual usage is less than allowed by cwnd, is named as the non-
to resume transmission at a previous rate without incurring the delay validated phase. This method allows an application to resume
of slow-start. However, if the TCP sender experiences congestion transmission at a previous rate without incurring the delay of slow-
using the preserved cwnd, it is required to immediately reset the start. However, if the TCP sender experiences congestion using the
cwnd to an appropriate value specified by the method. If a sender preserved cwnd, it is required to immediately reset the cwnd to an
does not take advantage of the preserved cwnd within the NVP, the appropriate value specified by the method. If a sender does not take
value of cwnd is reduced, ensuring the value better reflects the advantage of the preserved cwnd within the NVP, the value of cwnd is
capacity that was recently actually used. 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. It also reduces the 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"). (This is sometimes known as "padding").
The new method does not differentiate between times when the sender The new method does not differentiate between times when the sender
has become idle or rate-limited. This is partly a response to has become idle or rate-limited. This is partly a response to
recognition that some applications wish to transmit at a rate less recognition that some applications wish to transmit at a rate less
skipping to change at page 8, line 9 skipping to change at page 8, line 14
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 "undefined" value. This initialises the pipeACK variable to the "undefined" value. This
value inhibts use of the value in cwv calculations. value inhibits 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, 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
skipping to change at page 9, line 5 skipping to change at page 9, line 10
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.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 A cwnd-limited sender uses the standard TCP method to increase
phase. cwnd (i.e. a TCP sender that fully utilises the cwnd is permitted
to increase cwnd each received ACK).
o 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.3.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.3.2 is
skipping to change at page 9, line 43 skipping to change at page 10, line 5
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.
This new cwnd is set to reflect that a nonvalidated cwnd may be If there is a valid pipeACK value, the new cwnd is adjusted to
larger than the actual FlightSize, or recently used FlightSize reflect that a nonvalidated cwnd may be larger than the actual
(recorded in pipeACK). The updated cwnd therefore prevents overshoot FlightSize, or recently used FlightSize (recorded in pipeACK). The
by a sender significantly increasing its transmission rate during the updated cwnd therefore prevents overshoot by a sender significantly
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
skipping to change at page 10, line 25 skipping to change at page 10, line 35
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.
4.4.2. Adjustment at the end of the nonvalidated phase ssthresh is adjusted using the standard TCP method.
During the non-validated phase, a sender can produce bursts of data 4.4.2. Sender burst control during the nonvalidated phase
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 congestion control allows a sender to accumulate a cwnd that
setting a burst size limit, using a pacing algorithm, or some other would allow it to send a bursts of segments with a total size up to
method [Hug01]. the difference between the FlightsSize and cwnd. Such bursts can
impact other flows that share a network bottleneck and/or may induce
congestion when buffering is limited.
Various methods have been proposed to control the sender bustiness
[Hug01], [All05]. For example, TCP can limit the number of new
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
not send appreciable data in the previous RTT [All05].
This document recommends using a method to avoid line-rate bursts
after an idle or rate-limited period when there is less reliable
information about the capacity of the network path: A TCP sender in
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
cwnd over its estimate of the RTT, or some other method, to prevent
many segments being transmitted contiguously at line-rate. The most
appropriate method(s) to implement pacing depend on the design of the
TCP/IP stack, speed of interface and whether hardware support (such
as TCP Segment Offload, TSO) is used. The present document does not
recommend any specific method.
4.4.3. Adjustment at the end of the nonvalidated 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 11 skipping to change at page 11, line 42
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.3. Examples of Implementation 4.4.4. Examples of Implementation
This section is intended to provide informative examples of This section is intended to provide informative examples of
implementation methods. Implementations may choose to use other implementation methods. Implementations may choose to use other
methods that comply with the normative requirements. methods that comply with the normative requirements.
XXX This section is work in progress - discussion is welcome to help
complete this section XXX
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
(e.g. 5) equal length measurement periods. The sender then records (e.g. 5) equal length measurement periods. The sender then records
skipping to change at page 11, line 49 skipping to change at page 12, line 30
| |\ 5 | | | | | |\ 5 | | | |
| | | | | | /\ 4 | | | | | | | /\ 4 |
| | | | |\ 3 | | | \ | | | | | |\ 3 | | | \ |
| | \ | | \--- | | / \ | /| 2 | | \ | | \--- | | / \ | /| 2
|/ \------| - | | / \------/ \... |/ \------| - | | / \------/ \...
+----------+---------\+----/ /----+/---------+-------------> Time +----------+---------\+----/ /----+/---------+-------------> Time
<------------------------------------------------| <------------------------------------------------|
Sampling Period Current Time Sampling Period Current Time
Figure XX: Example of measuring pipeACK samples Figure 1: Example of measuring pipeACK samples
Figure XX shows an example of how measurement samples may be Figure 1 shows an example of how measurement samples may be
collected. At the time represented by the figure new samples are collected. At the time represented by the figure new samples are
being accumulated into sample D. Three previous samples also fall being accumulated into sample D. Three previous samples also fall
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 NVP period does not necessarily require a new timer to
be implemented. An alternative is to record a timestamp when the be implemented. An alternative is to record a timestamp when the
sender enters the NVP. Each time a sender transmits a new segment, sender enters the NVP. Each time a sender transmits a new segment,
this timestamp may be used to determine if the NVP period has this timestamp may be used to determine if the NVP period has
expired. If the period expires, the sender may take into account how expired. If the period expires, the sender may take into account how
many units of the NVP period have passed and make one reduction (as many units of the NVP period have passed and make one reduction (as
defined in section 4.3.2) for each NVP period. defined in section 4.3.2) for each NVP period.
A method is required to detect the cwnd-limited condition. In simple
terms this method 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
sender may safely preserve the cwnd, is a function of the period that sender may safely preserve the cwnd, is a function of the period that
skipping to change at page 14, line 7 skipping to change at page 14, line 41
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, and
Joe Touch. This work was part-funded by the European Community under Joe Touch. This work was part-funded by the European Community under
its Seventh Framework Programme through the Reducing Internet its Seventh Framework Programme through the Reducing Internet
Transport Latency (RITE) project (ICT-317700). Transport Latency (RITE) project (ICT-317700).
9. Author Notes 9. Author Notes
9.1. Other related work RFC-Editor note: please remove this section prior to publication.
There are several issues to be discussed more widely: 9.1. Other related work
o Should the method explicitly state a procedure for limiting RFC-Editor note: please remove this section prior to publication.
burstiness or pacing?
This is often regarded as good practice, but is not presently a There are several issues to be discussed more widely:
formal part of TCP. draft-hughes-restart-00.txt provides some
discussion of this topic.
o There are potential interactions with the Experimental update in o There are potential interactions with the Experimental update in
[RFC6928] that raises the TCP initial Window to ten segments, do [RFC6928] that raises the TCP initial Window to ten segments, do
these cases need to be elaborated? these cases need to be elaborated?
This relates to the Experimental specification for increasing This relates to the Experimental specification for increasing
the TCP IW defined in RFC 6928. the TCP IW defined in RFC 6928.
The two methods have different functions and different response The two methods have different functions and different response
to loss/congestion. to loss/congestion.
skipping to change at page 18, line 5 skipping to change at page 18, line 37
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 loss
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:
o Editorial corrections.
o Introduced the "cwnd-limited" term.
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
unnecessarily more conservative than standard TCP when the flow is
cwnd-limited. This resolves two issues: first it prevents
pathologies in which pipeACK increases slowly and eraticaly. It
also ensures that performance of bulk applications is not
significantly impacted when using the method.
o Clearly identifies that pacing (or equivalent) is requiring during
the NVP to control bustiness. New section added.
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.
skipping to change at page 18, line 38 skipping to change at page 19, line 38
[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 2011. June 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",
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, "Analysing
TCP for Bursty Traffic, Int'l J. of Communications, TCP for Bursty Traffic, Int'l J. of Communications,
Network and System Sciences, 7(3)", June 2010. 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] Fairhurst, Biswas, Biswas, and Biswas, "Enhancing TCP [Fai12] Sathiaseelan, Secchi, Fairhurst, and Biswas, "Enhancing
Performance to support Variable-Rate Traffic, 2nd Capacity TCP Performance to support Variable-Rate Traffic, 2nd
Sharing Workshop, ACM CoNEXT, Nice, France, 10th December Capacity Sharing Workshop, ACM CoNEXT, Nice, France, 10th
2012.", June 2008. December 2012.", June 2008.
[Hug01] Hughes, Touch, and Heidemann, "&#8730;&#8730;Issues in TCP [Hug01] Hughes, Touch, and Heidemann, "Issues in TCP Slow-Start
Slow-Start Restart After Idle (Work-in-Progress)", Restart After Idle (Work-in-Progress)", December 2001.
December 2001.
[Liu07] Liu, Allman, Jiny, and Wang, "Congestion Control without a [Liu07] Liu, Allman, Jiny, and Wang, "Congestion Control without a
Startup Phase, 5th International Workshop on Protocols for Startup Phase, 5th International Workshop on Protocols for
Fast Long-Distance Networks (PFLDnet), Los Angeles, Fast Long-Distance Networks (PFLDnet), Los Angeles,
California, USA", February 2007. California, USA", February 2007.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
 End of changes. 25 change blocks. 
61 lines changed or deleted 114 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/