draft-ietf-tcpm-newcwv-01.txt   draft-ietf-tcpm-newcwv-02.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 June 20, 2013 Intended status: Standards Track July 01, 2013
Expires: December 22, 2013 Expires: January 2, 2014
Updating TCP to support Rate-Limited Traffic Updating TCP to support Rate-Limited Traffic
draft-ietf-tcpm-newcwv-01 draft-ietf-tcpm-newcwv-02
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 December 22, 2013. This Internet-Draft will expire on January 2, 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 30 skipping to change at page 3, line 30
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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
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:
pipeACK: A variable that records the volume of data acknowledged by pipeACK sample: A meaure of the volume of data acknowledged by the
the network within an RTT. network within an RTT.
pipeACK Sampling Period: The maximum period that a measured sample of pipeACK variable: A variable that measures the available capacity
the pipeACK may influence the pipeACK variable. using the set of pipeACK samples.
pipeACK Sampling Period: The maximum period that a measured pipeACK
sample may influence the pipeACK variable.
Non-validated phase: The phase where the cwnd reflects a previous Non-validated phase: The phase where the cwnd reflects a previous
measurement of the available path capacity. measurement of the available path capacity.
Non-validated period, NVP: The maximum period for which cwnd is Non-validated period, NVP: The maximum period for which cwnd is
preserved in the non-validated phase. preserved in the non-validated phase.
Rate-limited: A TCP flow that does not consume more than one half of Rate-limited: A TCP flow that does not consume more than one half of
cwnd, and hence operates in the non-validated phase. cwnd, and hence operates in the non-validated phase.
skipping to change at page 7, line 20 skipping to change at page 7, line 23
limited periods. limited periods.
[RFC5681] defines a variable, FlightSize, that indicates the amount [RFC5681] defines a variable, FlightSize, that indicates the amount
of outstanding data in the network. This is assumed to be equal to of outstanding data in the network. This is assumed to be equal to
the value of Pipe calculated based on the pipe algorithm [RFC3517]. the value of Pipe calculated based on the pipe algorithm [RFC3517].
In RFC5681 this value is used during loss recovery, whereas in this In RFC5681 this value is used during loss recovery, whereas in this
method a new variable "pipeACK" is introduced to measure the method a new variable "pipeACK" is introduced to measure the
acknowledged size of the pipe, which is used to determine if the acknowledged size of the pipe, which is used to determine if the
sender has validated the cwnd. sender has validated the cwnd.
A sender determines a value for pipeACK by measuring the volume of A sender determines a pipeACK sample by measuring the volume of data
data that was acknowledged by the network over the period of a that was acknowledged by the network over the period of a measured
measured Round Trip Time (RTT). Using the variables defined in Round Trip Time (RTT). Using the variables defined in [RFC3517], a
[RFC3517], a value could be measured by caching the value of HighACK value could be measured by caching the value of HighACK and after one
and after one RTT measuring the difference between the cached HighACK RTT measuring the difference between the cached HighACK value and the
value and the current HighACK value. Other equivalent methods may be current HighACK value. Other equivalent methods may be used.
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 MUST make a measurement at least once after each received ACK, but SHOULD perform a pipeACK sample at least
per RTT when it has sent unacknowledged segments. The pipeACK value once per RTT when it has sent unacknowledged segments.
used by the algorithm MAY consider multiple pipeACK measurements over
the pipeACK Sampling Period. The calculated pipeACK value MUST NOT The pipeACK variable MAY consider multiple pipeACK sample over the
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 degiones 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 pipeACK to reflect the largest recently transmission, and allows the pipeACK variable to reflect the largest
measured size of "pipeACK". 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 maximum (undefined) value. This value is used to inhibit
entering the nonvalidated phase until the first measurement of entering the nonvalidated phase until the first new measurement of a
pipeACK completes. pipeACK 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 maximum (undefined) value.
skipping to change at page 8, line 34 skipping to change at page 8, line 34
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.3.
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
measured pipeACK, 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 measured A TCP sender MUST enter the non-validated phase when the pipeACK is
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.3.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).
skipping to change at page 9, line 20 skipping to change at page 9, line 20
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
appropriate, since any accumulated path history is considered appropriate, since any accumulated path history is considered
unreliable). unreliable).
o A sender that measures a pipeACK greater than (1/2)*cwnd SHOULD o A sender with a pipeACK variable greater than (1/2)*cwnd SHOULD
enter the validated phase. (A rate-limited sender will not enter the validated phase. (A rate-limited sender will not
normally be impacted by whether it is in a validated or non- normally be impacted by whether it is in a validated or non-
validate phase, since it will normally not consume the entire validated phase, since it will normally not consume the entire
cwnd. However a change to the validated phase will release the cwnd. However a change to the validated phase will release the
sender from constraints on the growth of cwnd, and restore the use sender from constraints on the growth of cwnd, and restore the use
of the standard congestion response.) of the standard congestion response.)
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
skipping to change at page 9, line 47 skipping to change at page 9, line 47
A sender that detects a packet-drop or receives an ECN marked packet A sender that detects a packet-drop or receives an ECN marked packet
MUST record the current FlightSize in the variable LossFlightSize and MUST record the current FlightSize in the variable LossFlightSize and
calculate a safe cwnd, by setting it to the value specified in calculate a safe cwnd, by setting it to the value specified in
Section 3.2 of [RFC5681]. Section 3.2 of [RFC5681].
A TCP sender MUST calculate a safe cwnd to use for loss recovery A TCP sender MUST calculate a safe cwnd to use for loss recovery
using the method below: using the method below:
cwnd = Min(cwnd/2,Max(pipeACK,LossFlightSize)). 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 much
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 = ((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
skipping to change at page 11, line 11 skipping to change at page 11, line 11
The sender MUST then update cwnd to be not greater than: The sender MUST then update cwnd to be not greater than:
cwnd = max(1/2*cwnd, IW). cwnd = max(1/2*cwnd, IW).
Where IW is the appropriate TCP initial window, used by the TCP Where IW is the appropriate TCP initial window, used by the TCP
sender (e.g. [RFC5681]). sender (e.g. [RFC5681]).
(This adjustment ensures that sender responds conservatively at the (This adjustment ensures that sender responds conservatively at the
end of the non-validated phase by reducing the cwnd to better reflect end of the non-validated phase by reducing the cwnd to better reflect
the current rate of the sender. The cwnd update does not take into the current rate of the sender. The cwnd update does not take into
account FlightSize or pipeACK because these values only reflect data account FlightSize or pipeACK value because these values only reflect
during the last RTT and do not reflect the average or maximum sending historical data and do not reflect the current sending rate.)
rate.)
4.4.3. Examples of Implementation 4.4.3. 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 XXX This section is work in progress - discussion is welcome to help
complete this section XXX complete this section XXX
The pipeACK value may be sampled 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 value within values so that the pipeACK variable records the largest pipeACK
the pipeACK Sampling Period. One simple way to implement this is to sample within the pipeACK Sampling Period. One simple way to
divide the pipeACK Sampling Period into several (e.g. 5) equal length implement this is to divide the pipeACK Sampling Period into several
measurement periods. The sender then records the start time for each (e.g. 5) equal length measurement periods. The sender then records
measurement period and the highest measured pipeACK value. At the the start time for each measurement period and the highest measured
end of the measurement period, any measurement(s) that are older than pipeACK sample. At the end of the measurement period, any
the pipeACK Sampling Period are discarded. The pipeACK variable is measurement(s) that are older than the pipeACK Sampling Period are
then assigned the largest of the set of the highest measured values. discarded. The pipeACK variable is then assigned the largest of the
set of the highest measured values.
+----------+----------+ +----------+---...... +----------+----------+ +----------+---......
| Sample A | Sample B | No | Sample C | Sample D | Sample A | Sample B | No | Sample C | Sample D
| | | Sample | | | | | Sample | |
| |\ 5 | | | | | |\ 5 | | | |
| | | | | | /\ 4 | | | | | | | /\ 4 |
| | | | |\ 3 | | | \ | | | | | |\ 3 | | | \ |
| | \ | | \--- | | / \ | /| 2 | | \ | | \--- | | / \ | /| 2
|/ \------| - | | / \------/ \... |/ \------| - | | / \------/ \...
+----------+---------\---/ /-----//--------+-------------> Time +----------+---------\+----/ /----+/---------+-------------> Time
<------------------------------------------------| <------------------------------------------------|
Sampling Period Current Time Sampling Period Current Time
Figure XX: Example of sampling pipeACK values Figure XX: Example of measuring pipeACK samples
Figure XX shows an example of how measurement samples may be Figure XX 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,
skipping to change at page 13, line 48 skipping to change at page 13, line 48
There are no IANA considerations. There are no IANA considerations.
8. Acknowledgments 8. Acknowledgments
The authors acknowledge the contributions of Dr I Biswas, Mr Ziaul The authors acknowledge the contributions of Dr I Biswas, Mr Ziaul
Hossain in supporting the evaluation of CWV and for their help in Hossain in supporting the evaluation of CWV and for their help in
developing the mechanisms proposed in this draft. We also developing the mechanisms proposed in this draft. We also
acknowledge comments received from the Internet Congestion Control acknowledge comments received from the Internet Congestion Control
Research Group, in particular Yuchung Cheng, Mirja Kuehlewind, and Research Group, in particular Yuchung Cheng, Mirja Kuehlewind, and
Joe Touch. trhis 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 9.1. Other related work
There are several issues to be discussed more widely: There are several issues to be discussed more widely:
o Should the method explicitly state a procedure for limiting o Should the method explicitly state a procedure for limiting
skipping to change at page 15, line 43 skipping to change at page 15, line 43
a possibility of a single method. a possibility of a single method.
o There is potential performance loss in loss of a short burst o There is potential performance loss in loss of a short burst
(off list with M Allman) (off list with M Allman)
A sender can transmit several segments then become idle. If A sender can transmit several segments then become idle. If
the first segments are all ACK'ed the ssthresh collapses to a the first segments are all ACK'ed the ssthresh collapses to a
small value (no new data is sent by the idle sender). Loss of small value (no new data is sent by the idle sender). Loss of
the later data results in congestion (e.g. maybe a RED drop or the later data results in congestion (e.g. maybe a RED drop or
some other cause, rather than the maximum rate of this flow). some other cause, rather than the maximum rate of this flow).
When performs loss recovery it may have an appreciable pipeACK When the sender performs loss recovery it may have an
and cwnd, but a very low flight size - the Standard algorithm appreciable pipeACK and cwnd, but a very low FlightSize - the
results in an unusually low cwnd (1/2 Flight size). Standard algorithm results in an unusually low cwnd (1/2
FlightSize).
A constant rate flow would have maintained a flight size A constant rate flow would have maintained a FlightSize
appropriate to pipeACK (cwnd if it is a bulk flow). appropriate to pipeACK (cwnd if it is a bulk flow).
This could be fixed by adding a new state variable? It could This could be fixed by adding a new state variable? It could
also be argued this is a corner case (e.g. loss of only the also be argued this is a corner case (e.g. loss of only the
last segments would have resulted in RTO), the impact could be last segments would have resulted in RTO), the impact could be
significant. significant.
o There is potential interaction with TCP Control Block Sharing(M o There is potential interaction with TCP Control Block Sharing(M
Welzl) Welzl)
An application that is non-validated can accumulate a cwnd that An application that is non-validated can accumulate a cwnd that
is larger than the actual capacity. Is this a fair value to is larger than the actual capacity. Is this a fair value to
use in TCB sharing? use in TCB sharing?
We propose that TCB sharing should use the pipeACK in place of
cwnd when a TCP sender is in the Nonvalidated phase. This
value better reflects the capacity that the flow has utilised
in the network path.
9.2. Revision notes 9.2. Revision notes
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
Draft 03 was submitted to ICCRG to receive comments and feedback. Draft 03 was submitted to ICCRG to receive comments and feedback.
Draft 04 contained the first set of clarifications after feedback: Draft 04 contained the first set of clarifications after feedback:
o Changed name to application limited and used the term rate-limited o Changed name to application limited and used the term rate-limited
in all places. in all places.
skipping to change at page 17, line 35 skipping to change at page 17, line 41
experience. experience.
o Removed that the requirement for the method to use TCP SACK option o Removed that the requirement for the method to use TCP SACK option
[RFC3517] to be enabled - Although it may be desirable to use [RFC3517] to be enabled - Although it may be desirable to use
SACK, this is not essential to the algorithm. SACK, this is not essential to the algorithm.
o Added the notion of the sampling period to accommodate large rate o Added the notion of the sampling period to accommodate large rate
variations and ensure that the method is stable. This algorithm variations and ensure that the method is stable. This algorithm
to be validated through implementation. to be validated through implementation.
WG draft 02 contained:
o Clarified language around pipeACK variable and pipeACK sample -
Feedback from Aris Angelogiannopoulos.
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. 26 change blocks. 
58 lines changed or deleted 72 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/