draft-ietf-tcpm-newcwv-11.txt   draft-ietf-tcpm-newcwv-12.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
Intended status: Experimental University of Aberdeen Intended status: Experimental University of Aberdeen
Expires: November 23, 2015 May 22, 2015 Expires: December 13, 2015 June 11, 2015
Updating TCP to support Rate-Limited Traffic Updating TCP to support Rate-Limited Traffic
draft-ietf-tcpm-newcwv-11 draft-ietf-tcpm-newcwv-12
Abstract Abstract
This document provides a mechanism to address issues that arise when This document provides a mechanism to address issues that arise when
TCP is used to support traffic that exhibits periods where the TCP is used to support traffic that exhibits periods where the
sending rate is limited by the application rather than the congestion sending rate is limited by the application rather than the congestion
window. It provides an experimental update to TCP that allows a TCP window. It provides an experimental update to TCP that allows a TCP
sender to restart quickly following a rate-limited interval. This sender to restart quickly following a rate-limited interval. This
method is expected to benefit applications that send rate-limited method is expected to benefit applications that send rate-limited
traffic using TCP, while also providing an appropriate response if traffic using TCP, while also providing an appropriate response if
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 November 23, 2015. This Internet-Draft will expire on December 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Implementation of new CWV . . . . . . . . . . . . . . . . 5 1.1. Implementation of new CWV . . . . . . . . . . . . . . . . 5
1.2. Standards Status of this Document . . . . . . . . . . . . 5 1.2. Standards Status of this Document . . . . . . . . . . . . 5
2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 5 2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Initialisation . . . . . . . . . . . . . . . . . . . . . 8 4.1. Initialisation . . . . . . . . . . . . . . . . . . . . . 8
4.2. Estimating the validated capacity supported by a path . . 8 4.2. Estimating the validated capacity supported by a path . . 8
4.3. Preserving cwnd during a rate-limited period. . . . . . . 9 4.3. Preserving cwnd during a rate-limited period. . . . . . . 10
4.4. TCP congestion control during the non-validated phase . . 10 4.4. TCP congestion control during the non-validated phase . . 11
4.4.1. Response to congestion in the non-validated phase . . 11 4.4.1. Response to congestion in the non-validated phase . . 12
4.4.2. Sender burst control during the non-validated phase . 13 4.4.2. Sender burst control during the non-validated phase . 13
4.4.3. Adjustment at the end of the Non-Validated Period 4.4.3. Adjustment at the end of the Non-Validated Period
(NVP) . . . . . . . . . . . . . . . . . . . . . . . . 13 (NVP) . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Examples of Implementation . . . . . . . . . . . . . . . 14 4.5. Examples of Implementation . . . . . . . . . . . . . . . 15
4.5.1. Implementing the pipeACK measurement . . . . . . . . 14 4.5.1. Implementing the pipeACK measurement . . . . . . . . 15
4.5.2. Implementing detection of the cwnd-limited condition 15 4.5.2. Measurement of the NVP and pipeACK samples . . . . . 16
5. Determining a safe period to preserve cwnd . . . . . . . . . 16 4.5.3. Implementing detection of the cwnd-limited condition 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Determining a safe period to preserve cwnd . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Other related work . . . . . . . . . . . . . . . . . . . 17 9. Author Notes . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Other related work . . . . . . . . . . . . . . . . . . . 18
10. Revision notes . . . . . . . . . . . . . . . . . . . . . . . 20 10. Revision notes . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
TCP is used for traffic with a range of application behaviours. The TCP is used for traffic with a range of application behaviours. The
TCP congestion window (cwnd) controls the number of unacknowledged TCP 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]. FlightSize is a measure of value known as the FlightSize [RFC5681]. FlightSize is a measure of
the volume of data that is in flight. A bulk application will always the volume of data that is in flight. A bulk application will always
have data available to transmit. The rate at which it sends is have data available to transmit. The rate at which it sends is
therefore limited by the maximum permitted by the receiver advertised therefore limited by the maximum permitted by the receiver advertised
skipping to change at page 5, line 25 skipping to change at page 5, line 25
entry and exit from this state Section 4.3. It defines how a TCP entry and exit from this state Section 4.3. It defines how a TCP
sender manages the growth of the cwnd using the set of rules defined sender manages the growth of the cwnd using the set of rules defined
in Section 4. in Section 4.
Implementation of this specification requires an implementor to Implementation of this specification requires an implementor to
define a method to measure the available capacity using the pipeACK define a method to measure the available capacity using the pipeACK
samples. The details of this measurement are implementation- samples. The details of this measurement are implementation-
specific. An example is provided in Section 4.5.1, but other methods specific. An example is provided in Section 4.5.1, but other methods
are permitted. A sender also needs to provide a method to determine are permitted. A sender also needs to provide a method to determine
when it becomes cwnd-limited. Implementation of this may require when it becomes cwnd-limited. Implementation of this may require
consideration of other TCP methods (see Section 4.5.2). consideration of other TCP methods (see Section 4.5.3).
A sender is also recommended to provide a method that controls the A sender is also recommended to provide a method that controls the
maximum burst size, Section 4.4.2. However, implementors are allowed maximum burst size, Section 4.4.2. However, implementors are allowed
flexibility in how this method is implemented and the choice of an flexibility in how this method is implemented and the choice of an
appropriate method is expected to depend on the way in which the appropriate method is expected to depend on the way in which the
sender stack implements other TCP methods (such as TCP Segment sender stack implements other TCP methods (such as TCP Segment
Offload, TSO). Offload, TSO).
1.2. Standards Status of this Document 1.2. Standards Status of this Document
skipping to change at page 7, line 32 skipping to change at page 7, line 32
"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 additional terminology is used in this document: The following additional 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.3).
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.
skipping to change at page 9, line 29 skipping to change at page 9, line 29
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 (e.g., a sender that has been idle When no measurements are available (e.g., a sender that has just
will have sent no data and received no ACKs), the pipeACK variable is started transmission or immediately after loss recovery), the pipeACK
set to the "undefined value". This value is used to inhibit entering variable is set to the "undefined value". This value is used to
the non-validated phase until the first new measurement of a pipeACK inhibit entering the non-validated phase until the first new
sample. (Section 4.5 provides examples of implementation.) measurement of a pipeACK sample. (Section 4.5 provides examples of
implementation.)
The pipeACK variable MUST NOT be updated during TCP Fast Recovery. The pipeACK variable MUST NOT be updated during TCP Fast Recovery.
That is, the sender stops collecting pipeACK samples during loss That is, the sender stops collecting pipeACK samples during loss
recovery. The method RECOMMENDS that the TCP SACK option [RFC2018] recovery. The method RECOMMENDS that the TCP SACK option [RFC2018]
is enabled and the method defined in [RFC6675] is used to recover is enabled and the method defined in [RFC6675] is used to recover
missing segments. This allows the sender to more accurately missing segments. This allows the sender to more accurately
determine the number of missing bytes during the loss recovery phase, determine the number of missing bytes during the loss recovery phase,
and using this method will result in a more appropriate cwnd and using this method will result in a more appropriate cwnd
following loss. following loss.
NOTE: The use of pipeACK rather than FlightSize can change the
behaviour of a TCP when a sender does not always have data available
to send. One example arises when there is a pause in transmission
after sending a sequence of many packets, and the sender experiences
loss at or near the end of its transmission sequence. In this case,
the TCP flow may have used a significant amount of capacity just
prior to the loss (which would be reflected in the volume of data
acknowledged, recorded in the pipeACK variable), but at the actual
time of loss the number of unacknowledged packets in flight (at the
end of the sequence) may be small, i.e., there is a small FlightSize.
After loss recovery, the sender resets its congestion control state.
[Fai12] explored the benefits of different responses to congestion
for application-limited streams. If the response is based only on
the Loss FlightSize, the sender would assign a small cwnd and
ssthresh, based only on the volume of data sent after the loss. When
the sender next starts to transmit it can incur may RTTs of delay in
slow start before it reacquires its previous rate. When the pipeACK
value is also usedto calculate the cwnd and ssthresh (as specified in
this update in Section 4.4.1), the sender can use a value that also
reflects the recently used capacity before the loss. This prevents a
variable-rate application from being unduly penalised. When the
sender resumes, it starts at one half its previous rate, similar to
the behaviour of a bulk TCP flow [Hos15]. To ensure an appropriate
reaction to on-going congestion, this method requires that the
pipeACK variable is reset after it is used in this way.
4.3. Preserving cwnd during a rate-limited period. 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 (i.e., at the start or directly after loss recovery). This is the
approximate indication of the capacity currently available along normal phase, where cwnd is expected to be an approximate
the network path, and the standard methods are used to increase indication of the capacity currently available along the network
cwnd (currently [RFC5681]). path, and the standard methods are used to increase cwnd
(currently [RFC5681]).
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. reaction to congestion.
skipping to change at page 10, line 49 skipping to change at page 11, line 30
when the sender receives an indication of congestion. when the sender receives an indication of congestion.
After a fixed period of time (the non-validated period, NVP), the After a fixed period of time (the non-validated period, NVP), the
sender adjusts the cwnd Section 4.4.3). The NVP SHOULD NOT exceed 5 sender adjusts the cwnd Section 4.4.3). The NVP SHOULD NOT exceed 5
minutes.Section 5 discusses the rationale for choosing a safe value minutes.Section 5 discusses the rationale for choosing a safe value
for this period. for this period.
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.3):
* 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 (i.e., needs to when ACK packets are received in this phase (i.e., needs to
avoid growing the cwnd when it has not recently sent using the avoid growing the cwnd when it has not recently sent using the
current size of cwnd). current size of cwnd).
skipping to change at page 12, line 36 skipping to change at page 13, line 18
is halved. is halved.
The calculated cwnd value MUST NOT be reduced below 1 TCP Maximum The calculated cwnd value MUST NOT be reduced below 1 TCP Maximum
Segment Size (MSS). Segment Size (MSS).
After completing the loss recovery phase, the sender MUST re- After completing the loss recovery phase, the sender MUST re-
initialise the pipeACK variable to the "undefined" value. This initialise the pipeACK variable to the "undefined" value. This
ensures that standard TCP methods are used immediately after ensures that standard TCP methods are used immediately after
completing loss recovery until a new pipeACK value can be determined. completing loss recovery until a new pipeACK value can be determined.
ssthresh is adjusted using the standard TCP method. The ssthresh is adjusted using the standard TCP method (Step 6 in
Section 3.2 of RFC 5681 assigns the ssthresh a value equal to cwnd at
the end of the loss recovery).
Note: The adjustment by reducing cwnd by the volume of data not sent Note: The adjustment by reducing cwnd by the volume of data not sent
(R) follows the method proposed for Jump Start [Liu07]. The (R) follows the method proposed for Jump Start [Liu07]. The
inclusion of the term R makes the adjustment more conservative than inclusion of the term R makes the adjustment more conservative than
standard TCP. This is required, since a sender in the non-validated 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 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 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 the number of segments in flight relative to what it sent in the last
RTT). The additional reduction after congestion is beneficial when RTT). The additional reduction after congestion is beneficial when
the LossFlightSize has significantly overshot the available path the LossFlightSize has significantly overshot the available path
skipping to change at page 14, line 4 skipping to change at page 14, line 37
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
rate-limited flows that encounter occasional congestion, and could rate-limited flows that encounter occasional congestion, and could
otherwise suffer an unwanted additional delay in recovering the otherwise suffer an unwanted additional delay in recovering the
sending rate.) sending rate.)
The sender MUST then update cwnd to be not greater than: The sender MUST then update cwnd to be not greater than:
cwnd = max((1/2)*cwnd, IW). cwnd = max((1/2)*cwnd, IW).
Where IW is the appropriate TCP initial window, used by the TCP Where IW is the appropriate TCP initial window, used by the TCP
sender (e.g., [RFC5681]). sender (e.g., [RFC5681]).
Note: This adjustment ensures that the sender responds conservatively Note: These cwnd and ssthresh adjustments cause the sender to enter
after remaining in the non-validated phase for more than the non- slow-start (since ssthresh > cwnd). This adjustment ensures that the
validated period. In this case, it reduces the cwnd by a factor of sender responds conservatively after remaining in the non-validated
two from the preserved value. This adjustment is helpful when flows phase for more than the non-validated period. In this case, it
accumulate but do not use a large cwnd, and seeks to mitigate the reduces the cwnd by a factor of two from the preserved value. This
impact when these flows later resume transmission. This could for adjustment is helpful when flows accumulate but do not use a large
instance mitigate the impact if multiple high-rate application flows cwnd, and seeks to mitigate the impact when these flows later resume
were to become idle over an extended period of time and then were transmission. This could for instance mitigate the impact if
simultaneously awakened by an external event. multiple high-rate application flows were to become idle over an
extended period of time and then were simultaneously awakened by an
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 the pipeACK measurement 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
skipping to change at page 15, line 21 skipping to change at page 16, line 4
| | | | | | | /\ 4 | | | | | | | | /\ 4 |
| | | | | |\ 3 | | | \ | | | | | | |\ 3 | | | \ |
| | | \ | | \--- | | / \ | /| 2 | | | \ | | \--- | | / \ | /| 2
| |/ \------| - | | / \------/ \... | |/ \------| - | | / \------/ \...
+//-+----------+---------\+----/ /----+/---------+-------------> Time +//-+----------+---------\+----/ /----+/---------+-------------> Time
<------------------------------------------------| <------------------------------------------------|
Sampling Period Current Time Sampling Period Current Time
Figure 1: Example of measuring pipeACK samples Figure 1: Example of measuring pipeACK samples
Figure 1 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 (because no new data segments were measurements were taken (because no new data segments were
acknowledged). The current value of the pipeACK variable will be 5, acknowledged). The current value of the pipeACK variable will be 5,
the maximum across all samples. the maximum across all samples. During this period, the pipeACK
samples may be regarded as zero, and hence do not contribute to the
calculated pipeACK value.
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: the pipeACK Sampling Period and the NVP do not necessarily 4.5.2. Measurement of the NVP and pipeACK samples
require a new timer to be implemented. An alternative is to record a
timestamp when the sender enters the non-validated phase. Each time
a sender transmits a new segment, this timestamp may be used to
determine if the NVP has expired. If the period expires, the sender
takes into account how many units of the NVP have passed and make one
reduction (as defined in Section 4.4.3) for each NVP.
4.5.2. Implementing detection of the cwnd-limited condition The mechanism requires a number of measurements of time. These
measurements could be implemented using protocol timers, but do not
necessarily require a new timer to be implemented. Avoiding the use
of dedicated timers can save operating system resources, especially
when there may be large numbers of TCP flows.
The NVP could be measured by recording a timestamp when the sender
enters the non-validated phase. Each time a sender transmits a new
segment, this timestamp can be used to determine if the NVP has
expired. If the measured period exceeds the NVP, the sender can then
take into account how many units of the NVP have passed and make one
reduction (defined in Section 4.4.3) for each NVP.
Similarly, the time measurements for collecting pipeACK samples and
determining the Sampling Period could be derived by using a timestamp
to record when each sample was measured, and to use this to calculate
how much time has passed when each new ACK is received.
4.5.3. Implementing detection of the cwnd-limited condition
A sender needs to implement a method that detects the cwnd-limited A sender needs to implement a method that detects the cwnd-limited
condition (see Section 4.4). This detects a condition where a sender condition (see Section 4.4). This detects a condition where a sender
in the non-validated phase receives an ACK, but the size of cwnd in 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 FlightSize of a In simple terms, this condition is true only when the FlightSize of a
TCP sender is equal to or larger than the current cwnd. However, an TCP sender is equal to or larger than the current cwnd. However, an
implementation also needs to consider constraints on the way in which implementation also needs to consider constraints on the way in which
the cwnd variable can be used, for instance implementations need to the cwnd variable can be used, for instance implementations need to
skipping to change at page 23, line 23 skipping to change at page 24, line 11
o Section 4.5.2: rewritten section text. o Section 4.5.2: rewritten section text.
WG draft 11 contained edits following IETF LC: WG draft 11 contained edits following IETF LC:
o Updated text in section 1.1. o Updated text in section 1.1.
o Updated text in response to AD, Gen-ART, & Sec reviews. o Updated text in response to AD, Gen-ART, & Sec reviews.
o LC call comments from Mirja Kuehlewind o LC call comments from Mirja Kuehlewind
WG draft 12 contained edits following IETF LC (Mirja Kuehlewind):
o Additional text (based on text in annexe notes) to clarify use of
pipeACK rather than FlightSize.
o Corrected text on undefined pipeACK - to be consistent.
o Added text on standard TCP method (reference to RFC 5681).
o Separated text on implementation experience of "timers" into a new
implementation subsection (4.5.2), to avoid this common
implementation method being overlooked.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", September [RFC0793] Postel, J., "Transmission Control Protocol", September
1981. 1981.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
skipping to change at page 24, line 30 skipping to change at page 25, line 30
[Bis11] Biswas, I., "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, A., Secchi, R., Fairhurst, G., and I. [Fai12] Sathiaseelan, A., Secchi, R., Fairhurst, G., and I.
Biswas, "Enhancing TCP Performance to support Variable- Biswas, "Enhancing TCP Performance to support Variable-
Rate Traffic, 2nd Capacity Sharing Workshop, ACM CoNEXT, Rate Traffic, 2nd Capacity Sharing Workshop, ACM CoNEXT,
Nice, France, 10th December 2012.", June 2008. Nice, France, 10th December 2012.", June 2008.
[Hos15] Hossain, Z., "PhD Thesis, A Study of Mechanisms to Support
Variable-rate Internet Applications over a Multi-service
Satellite Platform, School of Engineering, University of
Aberdeen", January 2015.
[Hug01] Hughes, A., Touch, J., and J. Heidemann, "Issues in TCP [Hug01] Hughes, A., Touch, J., and J. Heidemann, "Issues in TCP
Slow-Start Restart After Idle (Work-in-Progress)", Slow-Start Restart After Idle (Work-in-Progress)",
December 2001. December 2001.
[Liu07] Liu, D., Allman, M., Jiny, S., and L. Wang, "Congestion [Liu07] Liu, D., Allman, M., Jiny, S., and L. Wang, "Congestion
Control without a Startup Phase, 5th International Control without a Startup Phase, 5th International
Workshop on Protocols for Fast Long-Distance Networks Workshop on Protocols for Fast Long-Distance Networks
(PFLDnet), Los Angeles, California, USA", February 2007. (PFLDnet), Los Angeles, California, USA", February 2007.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
 End of changes. 21 change blocks. 
53 lines changed or deleted 119 lines changed or added

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