draft-ietf-tcpm-alternativebackoff-ecn-05.txt   draft-ietf-tcpm-alternativebackoff-ecn-06.txt 
Network Working Group N. Khademi Network Working Group N. Khademi
Internet-Draft M. Welzl Internet-Draft M. Welzl
Intended status: Experimental University of Oslo Intended status: Experimental University of Oslo
Expires: June 14, 2018 G. Armitage Expires: August 18, 2018 G. Armitage
Swinburne University of Technology Swinburne University of Technology
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
December 11, 2017 February 14, 2018
TCP Alternative Backoff with ECN (ABE) TCP Alternative Backoff with ECN (ABE)
draft-ietf-tcpm-alternativebackoff-ecn-05 draft-ietf-tcpm-alternativebackoff-ecn-06
Abstract Abstract
Recent Active Queue Management (AQM) mechanisms allow for burst Active Queue Management (AQM) mechanisms allow for burst tolerance
tolerance while enforcing short queues to minimise the time that while enforcing short queues to minimise the time that packets spend
packets spend enqueued at a bottleneck. This can cause noticeable enqueued at a bottleneck. This can cause noticeable performance
performance degradation for TCP connections traversing such a degradation for TCP connections traversing such a bottleneck,
bottleneck, especially if there are only a few flows or their especially if there are only a few flows or their bandwidth-delay-
bandwidth-delay-product is large. An Explicit Congestion product is large. An Explicit Congestion Notification (ECN) signal
Notification (ECN) signal indicates that an AQM mechanism is used at indicates that an AQM mechanism is used at the bottleneck, and
the bottleneck, and therefore the bottleneck network queue is likely therefore the bottleneck network queue is likely to be short. This
to be short. This document therefore proposes an update to RFC3168, document therefore proposes an update to RFC3168, which changes the
which changes the TCP sender-side ECN reaction in congestion TCP sender-side ECN reaction in congestion avoidance to reduce the
avoidance to reduce the Congestion Window (cwnd) by a smaller amount Congestion Window (cwnd) by a smaller amount than the congestion
than the congestion control algorithm's reaction to inferred packet control algorithm's reaction to inferred packet loss.
loss.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 14, 2018. This Internet-Draft will expire on August 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Why Use ECN to Vary the Degree of Backoff? . . . . . . . 4 4.1. Why Use ECN to Vary the Degree of Backoff? . . . . . . . 4
4.2. Focus on ECN as Defined in RFC3168 . . . . . . . . . . . 5 4.2. Focus on ECN as Defined in RFC3168 . . . . . . . . . . . 5
4.3. Choice of ABE Multiplier . . . . . . . . . . . . . . . . 5 4.3. Choice of ABE Multiplier . . . . . . . . . . . . . . . . 5
5. ABE Requirements . . . . . . . . . . . . . . . . . . . . . . 7 5. ABE Deployment Requirements . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Revision Information . . . . . . . . . . . . . . . . . . . . 9 10. Revision Information . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Definitions 1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction
Explicit Congestion Notification (ECN) [RFC3168] makes it possible Explicit Congestion Notification (ECN) [RFC3168] makes it possible
for an Active Queue Management (AQM) mechanism to signal the presence for an Active Queue Management (AQM) mechanism to signal the presence
of incipient congestion without incurring packet loss. This lets the of incipient congestion without incurring packet loss. This lets the
network deliver some packets to an application that would have been network deliver some packets to an application that would have been
dropped if the application or transport did not support ECN. This dropped if the application or transport did not support ECN. This
packet loss reduction is the most obvious benefit of ECN, but it is packet loss reduction is the most obvious benefit of ECN, but it is
often relatively modest. Other benefits of deploying ECN have been often relatively modest. Other benefits of deploying ECN have been
documented in RFC8087 [RFC8087]. documented in RFC8087 [RFC8087].
skipping to change at page 3, line 47 skipping to change at page 3, line 41
measured response when an early-warning signal of congestion is measured response when an early-warning signal of congestion is
received in the form of an ECN CE-marked packet. Recognizing these received in the form of an ECN CE-marked packet. Recognizing these
changes in modern AQM practices, more recent rules have relaxed the changes in modern AQM practices, more recent rules have relaxed the
strict requirement that ECN signals be treated identically to strict requirement that ECN signals be treated identically to
inferred packet loss [I-D.ECN-exp]. Following these newer, more inferred packet loss [I-D.ECN-exp]. Following these newer, more
flexible rules, this document defines a new sender-side-only flexible rules, this document defines a new sender-side-only
congestion control response, called "ABE" (Alternative Backoff with congestion control response, called "ABE" (Alternative Backoff with
ECN). ABE improves TCP's average throughput when routers use AQM ECN). ABE improves TCP's average throughput when routers use AQM
controlled buffers that allow for short queues only. controlled buffers that allow for short queues only.
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Specification 3. Specification
This specification updates the congestion control algorithm of an This specification updates the congestion control algorithm of an
ECN-Capable TCP transport protocol by changing the TCP sender ECN-Capable TCP transport protocol by changing the TCP sender
response to feedback from the TCP receiver that indicates reception response to feedback from the TCP receiver that indicates reception
of a CE-marked packet, i.e., receipt of a packet with the ECN-Echo of a CE-marked packet, i.e., receipt of a packet with the ECN-Echo
flag (defined in [RFC3168]) set. flag (defined in [RFC3168]) set.
It updates the following text in section 6.1.2 of the ECN It updates the following text in section 6.1.2 of the ECN
specification [RFC3168] : specification [RFC3168] :
skipping to change at page 4, line 20 skipping to change at page 4, line 20
The indication of congestion should be treated just as a The indication of congestion should be treated just as a
congestion loss in non-ECN-Capable TCP. That is, the TCP source congestion loss in non-ECN-Capable TCP. That is, the TCP source
halves the congestion window "cwnd" and reduces the slow start halves the congestion window "cwnd" and reduces the slow start
threshold "ssthresh". threshold "ssthresh".
Replacing this with: Replacing this with:
Receipt of a packet with the ECN-Echo flag SHOULD trigger the TCP Receipt of a packet with the ECN-Echo flag SHOULD trigger the TCP
source to set the slow start threshold (ssthresh) to 0.8 times the source to set the slow start threshold (ssthresh) to 0.8 times the
FlightSize, with a lower bound of 2 * SMSS applied to the result. FlightSize, with a lower bound of 2 * SMSS applied to the result.
As in [RFC5681], the TCP sender also reduces the cwnd value to As in [RFC5681], the TCP sender also reduces the cwnd value to no
that new ssthresh value. more than the new ssthresh value.
4. Discussion 4. Discussion
Much of the technical background to ABE can be found in a research Much of the technical background to ABE can be found in a research
paper [ABE2017]. This paper used a mix of experiments, theory and paper [ABE2017]. This paper used a mix of experiments, theory and
simulations with NewReno [RFC5681] and CUBIC [I-D.CUBIC] to evaluate simulations with NewReno [RFC5681] and CUBIC [I-D.CUBIC] to evaluate
the technique. The technique was shown to present "...significant the technique. The technique was shown to present "...significant
performance gains in lightly-multiplexed [few concurrent flows] performance gains in lightly-multiplexed [few concurrent flows]
scenarios, without losing the delay-reduction benefits of deploying scenarios, without losing the delay-reduction benefits of deploying
CoDel or PIE". The performance improvement is achieved when reacting CoDel or PIE". The performance improvement is achieved when reacting
to ECN-Echo in congestion avoidance by multiplying cwnd and ssthresh to ECN-Echo in congestion avoidance by multiplying cwnd and ssthresh
with a value in the range [0.7,0.85]. with a value in the range [0.7,0.85].
4.1. Why Use ECN to Vary the Degree of Backoff? 4.1. Why Use ECN to Vary the Degree of Backoff?
The classic rule-of-thumb dictates that a network path needs to The classic rule-of-thumb dictates that a network path needs to
provide a BDP of bottleneck buffering if a TCP connection wishes to provide a BDP of bottleneck buffering if a TCP connection wishes to
optimise path utilisation. A single TCP bulk transfer running optimise path utilisation. A single TCP bulk transfer running
through such a bottleneck will have increased its congestion window through such a bottleneck will have increased its congestion window
(cwnd) up to 2*BDP by the time that packet loss occurs. When packet (cwnd) up to 2*BDP by the time that packet loss occurs. According to
loss is inferred using the retransmission timer and the given packet [RFC5681], when a TCP sender detects segment loss using the
has not yet been resent by way of the retransmission timer (regarded retransmission timer and the given segment has not yet been resent by
as a notification of congestion), Standard TCP sets the ssthresh to way of the retransmission timer, the value of ssthresh must be set to
the maximum of half of the FlightSize and 2*SMSS [RFC5681], which no more of the maximum of half of the FlightSize and 2*SMSS. The
causes the TCP congestion control to go back to allowing only a BDP same equation is also used during Fast Retransmit/Fast Recovery
of packets in flight -- just sufficient to maintain 100% utilisation [RFC5681]. As a result, the TCP congestion control only allows one
of the bottleneck on the network path. BDP of packets in flight. This is just sufficient to maintain 100%
utilisation of the bottleneck on the network path.
AQM mechanisms such as CoDel [I-D.CoDel] and PIE [RFC8033] set a AQM mechanisms such as CoDel [I-D.CoDel] and PIE [RFC8033] set a
delay target in routers and use congestion notifications to constrain delay target in routers and use congestion notifications to constrain
the queuing delays experienced by packets, rather than in response to the queuing delays experienced by packets, rather than in response to
impending or actual bottleneck buffer exhaustion. With current impending or actual bottleneck buffer exhaustion. With current
default delay targets, CoDel and PIE both effectively emulate a default delay targets, CoDel and PIE both effectively emulate a
bottleneck with a short queue (section II, [ABE2017]) while also bottleneck with a short queue (section II, [ABE2017]) while also
allowing short traffic bursts into the queue. This provides allowing short traffic bursts into the queue. This provides
acceptable performance for TCP connections over a path with a low acceptable performance for TCP connections over a path with a low
BDP, or in highly multiplexed scenarios (many concurrent transport BDP, or in highly multiplexed scenarios (many concurrent transport
skipping to change at page 5, line 38 skipping to change at page 5, line 41
to modify TCP congestion control behaviour via a larger to modify TCP congestion control behaviour via a larger
multiplicative decrease factor in conjunction with a smaller additive multiplicative decrease factor in conjunction with a smaller additive
increase factor [ICC2002]. The goal of this former work was to increase factor [ICC2002]. The goal of this former work was to
operate across AQM bottlenecks using Random Early Detection (RED) operate across AQM bottlenecks using Random Early Detection (RED)
that were not necessarily configured to emulate a short queue (The that were not necessarily configured to emulate a short queue (The
current usage of RED as an Internet AQM method is limited [RFC7567]). current usage of RED as an Internet AQM method is limited [RFC7567]).
4.2. Focus on ECN as Defined in RFC3168 4.2. Focus on ECN as Defined in RFC3168
Some transport protocol mechanisms rely on ECN semantics that differ Some transport protocol mechanisms rely on ECN semantics that differ
from the original ECN definition [RFC3168] -- for example, Congestion from the original ECN definition [RFC3168]. For instance, Accurate
Exposure (ConEx) [RFC7713] and Datacenter TCP (DCTCP) ECN [I-D.ietf-tcpm-accurate-ecn] permits more frequent and detailed
[I-D.ietf-tcpm-dctcp] need more accurate ECN information than that feedback. Use of mechanisms (such as Accurate ECN, Datacenter TCP
offered by the original feedback method. Other mechanisms (e.g., (DCTCP) [RFC8257], or Congestion Exposure (ConEx) [RFC7713]) is out
[I-D.ietf-tcpm-accurate-ecn]) allow the sender to adjust the rate of scope for this document. This specification focuses on ECN as
more frequently than once each path RTT. Use of these mechanisms is defined in [RFC3168].
out of scope for this document.
4.3. Choice of ABE Multiplier 4.3. Choice of ABE Multiplier
ABE decouples the reaction of a TCP sender to inferred packet loss ABE decouples the reaction of a TCP sender to inferred packet loss
and ECN-signalled congestion when in the congestion avoidance phase and ECN-signalled congestion in the congestion avoidance phase. To
by differentiating the scaling factor used in Equation 4 in achieve this, ABE uses different the scaling factor in Equation 4 in
Section 3.1 of [RFC5681]. The description respectively uses Section 3.1 of [RFC5681]. The description respectively uses
beta_{loss} and beta_{ecn} to refer to the multiplicative decrease beta_{loss} and beta_{ecn} to refer to the multiplicative decrease
factors applied in response to inferred packet loss, and in response factors applied in response to inferred packet loss, and in response
to a receiver indicating ECN-signalled congestion. For non-ECN- to a receiver indicating ECN-signalled congestion. For non-ECN-
enabled TCP connections, only beta_{loss} applies. enabled TCP connections, only beta_{loss} applies.
In other words, in response to inferred packet loss: In other words, in response to inferred packet loss:
ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS) ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS)
skipping to change at page 6, line 40 skipping to change at page 6, line 41
the path, while less aggressive backoff (larger beta_*) can result in the path, while less aggressive backoff (larger beta_*) can result in
slower draining of the bottleneck queue. slower draining of the bottleneck queue.
The Internet has already been running with at least two different The Internet has already been running with at least two different
beta_{loss} values for several years: the standard value is 0.5 beta_{loss} values for several years: the standard value is 0.5
[RFC5681], and the Linux implementation of CUBIC [I-D.CUBIC] has used [RFC5681], and the Linux implementation of CUBIC [I-D.CUBIC] has used
a multiplier of 0.7 since kernel version 2.6.25 released in 2008. a multiplier of 0.7 since kernel version 2.6.25 released in 2008.
ABE proposes no change to beta_{loss} used by current TCP ABE proposes no change to beta_{loss} used by current TCP
implementations. implementations.
beta_{ecn} depends on how the response of a TCP connection to shallow The recommendation in Section 3 in this document corresponds to a
AQM marking thresholds is optimised. beta_{loss} reflects the value of beta_{ecn}=0.8. This recommended beta_{ecn} value is only
preferred response of each congestion control algorithm when faced applicable for the standard TCP congestion control [RFC5681]. The
with exhaustion of buffers (of unknown depth) signalled by packet selection of beta_{ecn} enables tuning the response of a TCP
loss. Consequently, for any given TCP congestion control algorithm connection to shallow AQM marking thresholds. beta_{loss}
the choice of beta_{ecn} is likely to be algorithm-specific, rather characterizes the response of a congestion control algorithm to
than a constant multiple of the algorithm's existing beta_{loss}. The packet loss, i.e., exhaustion of buffers (of unknown depth).
recommended beta_{ecn} value in this document is only applicable for Different values for beta_{loss} have been suggested for TCP
Standard TCP congestion control. congestion control algorithms. Consequently, beta_{ecn} is likely to
be an algorithm-specific parameter rather than a constant multiple of
the algorithm's existing beta_{loss}.
A range of tests (section IV, [ABE2017]) with NewReno and CUBIC over A range of tests (section IV, [ABE2017]) with NewReno and CUBIC over
CoDel and PIE in lightly-multiplexed scenarios have explored this CoDel and PIE in lightly-multiplexed scenarios have explored this
choice of parameter. The results of these tests indicate that CUBIC choice of parameter. The results of these tests indicate that CUBIC
connections benefit from beta_{ecn} of 0.85 (cf. beta_{loss} = 0.7), connections benefit from beta_{ecn} of 0.85 (cf. beta_{loss} = 0.7),
and NewReno connections see improvements with beta_{ecn} in the range and NewReno connections see improvements with beta_{ecn} in the range
0.7 to 0.85 (cf. beta_{loss} = 0.5). 0.7 to 0.85 (cf. beta_{loss} = 0.5).
5. ABE Requirements 5. ABE Deployment Requirements
This update is a sender-side only change. Like other changes to This update is a sender-side only change. Like other changes to
congestion control algorithms, it does not require any change to the congestion control algorithms, it does not require any change to the
TCP receiver or to network devices. It does not require any ABE- TCP receiver or to network devices. It does not require any ABE-
specific changes in routers or the use of Accurate ECN feedback specific changes in routers or the use of Accurate ECN feedback
[I-D.ietf-tcpm-accurate-ecn] by a receiver. [I-D.ietf-tcpm-accurate-ecn] by a receiver.
RFC3168 states that the congestion control response to an ECN- RFC3168 states that the congestion control response to an ECN-
signalled congestion is the same as the response to a dropped packet signalled congestion is the same as the response to a dropped packet
[RFC3168]. [I-D.ECN-exp] updates this specification to allow systems [RFC3168]. [I-D.ECN-exp] updates this specification to allow systems
skipping to change at page 7, line 40 skipping to change at page 7, line 43
specification does not modify the transport protocol. specification does not modify the transport protocol.
To evaluate the benefit, this experiment therefore requires support To evaluate the benefit, this experiment therefore requires support
in AQM routers for ECN-marking of packets carrying the ECN-Capable in AQM routers for ECN-marking of packets carrying the ECN-Capable
Transport, ECT(0), codepoint [RFC3168]. Transport, ECT(0), codepoint [RFC3168].
If the method is only deployed by some senders, and not by others, If the method is only deployed by some senders, and not by others,
the senders that use this method can gain some advantage, possibly at the senders that use this method can gain some advantage, possibly at
the expense of other flows that do not use this updated method. the expense of other flows that do not use this updated method.
Because this advantage applies only to ECN-marked packets and not to Because this advantage applies only to ECN-marked packets and not to
packet loss indications, in the worst case (e.g., an ABE-compliant packet loss indications, an ECN-Capable bottleneck will still fall
TCP sender using beta_{ecn} = 1.0) the ECN-Capable bottleneck will back to dropping packets if an TCP sender using ABE is too
still fall back to dropping packets, and the result is no different aggressive, and the result is no different than if the TCP sender was
than if the TCP sender was using traditional loss-based congestion using traditional loss-based congestion control.
control.
A TCP sender reacts to loss or ECN marks only once per round-trip A TCP sender reacts to loss or ECN marks only once per round-trip
time. Hence, if a sender would first be notified of an ECN mark and time. Hence, if a sender would first be notified of an ECN mark and
then learn about loss in the same round-trip, it would only react to then learn about loss in the same round-trip, it would only react to
the first notification (ECN) but not to the second (loss). RFC3168 the first notification (ECN) but not to the second (loss). RFC3168
specified a reaction to ECN that was equal to the reaction to loss specified a reaction to ECN that was equal to the reaction to loss
[RFC3168]. [RFC3168].
ABE also makes one congestion-response each RTT that congestion is ABE also responds to congestion once per RTT, and therefore it does
signalled, and therefore there is no response to loss within the same not respond to further loss within the same RTT, since ABE has
round-trip time, since ABE has already made a reduction of the already reduced the congestion window. If congestion persists after
congestion window. ABE will however respond for each round-trip time such reduction, ABE continues to reduce the congestion window in each
that congestion continues to be signaled. This consecutive reduction consecutive RTT. This consecutive reduction can protect the network
can protect the network against long-standing unfairness in the case against long-standing unfairness in the case of AQM algorithms that
of AQM algorithms that do not keep a small average queue length. do not keep a small average queue length.
The result of this Internet experiment will include an investigation The result of this Internet experiment ought to include an
of cases such as the ones listed above, and be reported by investigation of the implications of experiencing an ECN-CE mark
presentation to the TCPM WG (or IESG) or an implementation report at followed by loss within the same RTT. At the end of the experiment,
the end of the experiment. this will be reported to the TCPM WG (or IESG).
6. Acknowledgements 6. Acknowledgements
Authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by Authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by
the European Community under its Seventh Framework Programme through the European Community under its Seventh Framework Programme through
the Reducing Internet Transport Latency (RITE) project (ICT-317700). the Reducing Internet Transport Latency (RITE) project (ICT-317700).
The views expressed are solely those of the authors. The views expressed are solely those of the authors.
The authors would like to thank Stuart Cheshire for many suggestions The authors would like to thank Stuart Cheshire for many suggestions
when revising the draft, and the following people for their when revising the draft, and the following people for their
skipping to change at page 9, line 26 skipping to change at page 9, line 28
mechanisms that have been in use in the Internet for many years mechanisms that have been in use in the Internet for many years
(e.g., CUBIC [I-D.CUBIC]). Unfairness may also be a result of other (e.g., CUBIC [I-D.CUBIC]). Unfairness may also be a result of other
factors, including the round trip time experienced by a flow. ABE factors, including the round trip time experienced by a flow. ABE
applies only when ECN-marked packets are received, not when packets applies only when ECN-marked packets are received, not when packets
are lost, hence use of ABE cannot lead to congestion collapse. are lost, hence use of ABE cannot lead to congestion collapse.
10. Revision Information 10. Revision Information
XX RFC ED - PLEASE REMOVE THIS SECTION XXX XX RFC ED - PLEASE REMOVE THIS SECTION XXX
-06. Addressed Michael Scharf's comments.
-05. Refined the description of the experiment based on feedback at -05. Refined the description of the experiment based on feedback at
IETF-100. Incorporated comments from David Black. IETF-100. Incorporated comments from David Black.
-04. Incorporates review comments from Lawrence Stewart and the -04. Incorporates review comments from Lawrence Stewart and the
remaining comments from Roland Bless. References are updated. remaining comments from Roland Bless. References are updated.
-03. Several review comments from Roland Bless are addressed. -03. Several review comments from Roland Bless are addressed.
Consistent terminology and equations. Clarification on the scope of Consistent terminology and equations. Clarification on the scope of
recommended beta_{ecn} value. recommended beta_{ecn} value.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
11.2. Informative References 11.2. Informative References
[ABE-FreeBSD] [ABE-FreeBSD]
"ABE patch review in FreeBSD", "ABE patch review in FreeBSD",
<https://reviews.freebsd.org/D11616>. <https://reviews.freebsd.org/D11616>.
[ABE2017] Khademi, N., Armitage, G., Welzl, M., Fairhurst, G., [ABE2017] Khademi, N., Armitage, G., Welzl, M., Fairhurst, G.,
Zander, S., and D. Ros, "Alternative Backoff: Achieving Zander, S., and D. Ros, "Alternative Backoff: Achieving
Low Latency and High Throughput with ECN and AQM", IFIP Low Latency and High Throughput with ECN and AQM", IFIP
NETWORKING 2017, Stockholm, Sweden, June 2017. NETWORKING 2017, Stockholm, Sweden, June 2017.
skipping to change at page 11, line 41 skipping to change at page 11, line 46
Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
Internet-draft, IETF work-in-progress draft-ietf-tcpm- Internet-draft, IETF work-in-progress draft-ietf-tcpm-
cubic-07, November 2017. cubic-07, November 2017.
[I-D.ietf-tcpm-accurate-ecn] [I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-
ecn-03 (work in progress), May 2017. ecn-03 (work in progress), May 2017.
[I-D.ietf-tcpm-dctcp]
Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
Control for Datacenters", draft-ietf-tcpm-dctcp-10 (work
in progress), August 2017.
[ICC2002] Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior [ICC2002] Kwon, M. and S. Fahmy, "TCP Increase/Decrease Behavior
with Explicit Congestion Notification (ECN)", IEEE with Explicit Congestion Notification (ECN)", IEEE
ICC 2002, New York, New York, USA, May 2002, ICC 2002, New York, New York, USA, May 2002,
<http://dx.doi.org/10.1109/ICC.2002.997262>. <http://dx.doi.org/10.1109/ICC.2002.997262>.
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713, Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015, DOI 10.17487/RFC7713, December 2015,
<https://www.rfc-editor.org/info/rfc7713>. <https://www.rfc-editor.org/info/rfc7713>.
 End of changes. 22 change blocks. 
79 lines changed or deleted 80 lines changed or added

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