One document matched: draft-khademi-tcpm-alternativebackoff-ecn-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.tools.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!-- http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml-->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2309 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2481 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2481.xml">
<!ENTITY RFC3168 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3649 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml">
<!ENTITY RFC3742 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3742.xml">
<!ENTITY RFC3758 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml">
<!ENTITY RFC4340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4774 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml">
<!ENTITY RFC5562 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5562.xml">
<!ENTITY RFC5670 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5670.xml">
<!ENTITY RFC5681 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY RFC5696 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5696.xml">
<!ENTITY RFC6040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml">
<!ENTITY RFC6679 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<!ENTITY RFC6789 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6789.xml">
<!ENTITY RFC7713 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml">
<!ENTITY RFC7567 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.ietf-tcpm-accurate-ecn SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tcpm-accurate-ecn-01.xml">
<!ENTITY I-D.ietf-tcpm-dctcp SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tcpm-dctcp-02.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml2rfc.tools.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc category="exp" docName="draft-khademi-tcpm-alternativebackoff-ecn-01"
ipr="trust200902">
<!-- noModificationTrust200902 noDerivativesTrust200902 pre5378Trust200902">-->
<!-- updates="6298"> -->
<!-- ipr="full3978"> -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<!-- <title abbrev="Abbreviated Title">Coupled congestion control</title> -->
<title abbrev="ABE">TCP Alternative Backoff with ECN (ABE)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Naeem Khademi" initials="N." surname="Khademi">
<organization>University of Oslo</organization>
<address>
<postal>
<street>PO Box 1080 Blindern</street>
<!-- Reorder these if your country does things differently -->
<code>N-0316</code>
<city>Oslo</city>
<region></region>
<country>Norway</country>
</postal>
<email>naeemk@ifi.uio.no</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Michael Welzl" initials="M." surname="Welzl">
<organization>University of Oslo</organization>
<address>
<postal>
<street>PO Box 1080 Blindern</street>
<!-- Reorder these if your country does things differently -->
<code>N-0316</code>
<city>Oslo</city>
<region></region>
<country>Norway</country>
</postal>
<email>michawe@ifi.uio.no</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization abbrev="Swinburne University of Technology">Centre for
Advanced Internet Architectures</organization>
<address>
<postal>
<street>Swinburne University of Technology</street>
<street>PO Box 218</street>
<street>John Street, Hawthorn</street>
<!-- Reorder these if your country does things differently -->
<code>3122</code>
<city>Victoria</city>
<region></region>
<country>Australia</country>
</postal>
<email>garmitage@swin.edu.au</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>School of Engineering, Fraser Noble Building</street>
<!-- Reorder these if your country does things differently -->
<code>AB24 3UE</code>
<city>Aberdeen</city>
<region></region>
<country>UK</country>
</postal>
<email>gorry@erg.abdn.ac.uk</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2016" />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup></workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>ecn, aqm, sctp, tcp</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This memo updates the TCP sender-side reaction to a congestion
notification received via Explicit Congestion Notification (ECN). The
updated method reduces FlightSize in Congestion Avoidance by a smaller
amount than the TCP reaction to loss. The intention is to achieve good
throughput when the queue at the bottleneck is smaller than the
bandwidth-delay-product of the connection. This is more likely when an
Active Queue Management (AQM) mechanism has used ECN to CE-mark a
packet, than when a packet was lost. Future versions of this document
will also describe a corresponding method for SCTP.</t>
</abstract>
</front>
<middle>
<section anchor="sec-def" title="Definitions">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<!--
<t><list style="hanging" hangIndent="6">
<t hangText="Wha'ever:">
<vspace />
Wha'ever is short for Whatever.</t>
</list></t>
-->
</section>
<section anchor="sec-intro" title="Introduction">
<t>Complementing <xref target="I-D.AQM-ECN-benefits"></xref>, <xref
target="I-D.ECN-exp"></xref> enables wider ECN deployment by
updating rules in <xref target="RFC3168"/> that prohibited certain experiments.
Specifically, <xref target="I-D.ECN-exp"/> allows for experiments to specify a congestion control
response to a CE-marked packet that differs from the response to a dropped packet.
This memo defines such a different congestion control response, called "ABE" (Alternative
Backoff with ECN). ABE is thus an Experiment in accordance with <xref
target="I-D.ECN-exp"></xref>.</t>
<t><xref target="RFC5681"></xref> stipulates that TCP
congestion control sets "ssthresh" to max(FlightSize / 2, 2*SMSS) in
response to packet loss. This corresponds to a backoff multiplier of 0.5
(halving cwnd and sshthresh after packet loss). Consequently, a standard
TCP flow using this reaction needs significant network queue space: it
can only fully utilise a bottleneck when the length of the link queue
(or the AQM dropping threshold) is at least the bandwidth-delay product
(BDP) of the flow.</t>
<t>A backoff multiplier of 0.5 is not the only available strategy. As
defined in <xref target="I-D.CUBIC"></xref>, CUBIC multiplies the
current cwnd by 0.7 in response to loss (the Linux implementation of
CUBIC has used a multiplier of 0.7 since kernel version 2.6.25 released
in 2008). Consequently, CUBIC utilises paths well even when the
bottleneck queue is shorter than the bandwidth-delay product of the
flow. However, in the case of a DropTail (FIFO) queue without AQM, such
less-aggressive backoff increases the risk of creating a standing queue
<xref target="CODEL2012"></xref>.</t>
<t>The standard TCP backoff behaviour
defined in <xref target="RFC5681"></xref> entails reduced link
utilisation in situations with short queues and low statistical
multiplexing. This memo proposes a concrete sender-side-only congestion
control response that remedies this problem.</t>
<t>Devices implementing AQM are likely to be the dominant (and possibly
only) source of ECN CE-marking for packets from ECN-capable senders. AQM
mechanisms typically strive to maintain a small average queue length, regardless
of the bandwidth-delay product of flows passing through them. Receipt of
an ECN CE-mark might therefore reasonably be taken to indicate that a
small bottleneck queue exists in the path, and hence the TCP flow would
benefit from using a less aggressive backoff multiplier.</t>
<t>Much of the background to this proposal can be found in <xref
target="ABE2015"></xref>. Using a mix of experiments, theory and
simulations with standard NewReno and CUBIC, <xref
target="ABE2015"></xref> recommends enabling ECN and letting individual
TCP senders use a larger multiplicative decrease factor as a reaction to
the receiver reporting ECN CE-marks from AQM-enabled bottlenecks. Such a
change is noted to result in "...significant performance gains in
lightly-multiplexed scenarios, without losing the delay-reduction
benefits of deploying CoDel or PIE" <xref target="I-D.CoDel"></xref>
<xref target="I-D.PIE"></xref>. This is achieved when reacting to
ECN-Echo in Congestion Avoidance by multiplying cwnd and sstthresh with
a value in the range [0.7..0.85].</t>
</section>
<section anchor="sec-rationale" title="Discussion">
<section anchor="sec-rationale-why"
title="Why Use ECN to Vary the Degree of Backoff?">
<t>The classic rule-of-thumb dictates that a transport provides a BDP of
bottleneck buffering if a TCP connection wishes to optimise path
utilisation. A single TCP connection running through such a bottleneck
will have opened cwnd up to 2*BDP by the time packet loss occurs.
<xref target="RFC5681"></xref>'s halving of cwnd and ssthresh pushes
the TCP connection back to allowing only a BDP of packets in flight --
just sufficient to maintain 100% utilisation of the network path.</t>
<t>AQM schemes like CoDel <xref target="I-D.CoDel"></xref> and PIE
<xref target="I-D.PIE"></xref> use congestion notifications to
constrain the queuing delays experienced by packets, rather than in
response to impending or actual bottleneck buffer exhaustion. With
current default delay targets, CoDel and PIE both effectively emulate
a shallow buffered bottleneck (section II, <xref
target="ABE2015"></xref>) while allowing short traffic bursts into the
queue. This interacts acceptably for TCP connections over low BDP
paths, or highly multiplexed scenarios (many concurrent TCP
connections). However, it interacts badly with lightly-multiplexed
cases (few concurrent connections) over a high BDP path. Conventional
TCP backoff in such cases leads to gaps in packet transmission and
under-utilisation of the path.</t>
<t>The idea to react differently to loss upon detecting an ECN CE-mark
pre-dates <xref target="ABE2015"></xref>. <xref
target="ICC2002"></xref> also proposed using ECN CE-marks to modify
TCP congestion control behaviour, using a larger multiplicative
decrease factor in conjunction with a smaller additive increase factor
to work with RED-based bottlenecks that were not necessarily
configured to emulate a shallow queue.</t>
</section>
<section anchor="sec-rationale-scope"
title="Focus on ECN as Defined in RFC3168">
<t>Some mechanisms rely on ECN semantics that differ from the
definitions in <xref target="RFC3168"></xref> -- for example,
Congestion Exposure (ConEx) <xref target="RFC7713"></xref> and DCTCP
<xref target="I-D.ietf-tcpm-dctcp"></xref> need more accurate ECN
information than the feedback mechanism in <xref
target="RFC3168"></xref> offers (defined in <xref
target="I-D.ietf-tcpm-accurate-ecn"></xref>). Such mechanisms allow a
sending rate adjustment more frequent than each RTT. These mechanisms
are out of the scope of the current document.</t>
</section>
<section anchor="sec-rationale-multiplier" title="Discussion: Choice of ABE Multiplier">
<t>Alternative Backoff with ECN (ABE) decouples a TCP sender's reaction
to loss and ECN CE-marks in Congestion Avoidance. The description
respectively uses beta_{loss} and beta_{ecn} to refer to the
multiplicative decrease factors applied in response to packet loss, and
also in response to a receiver indicating that an ECN CE-mark was
received on an ECN-enabled TCP connection (based on the terms used in
<xref target="ABE2015"></xref>). For non-ECN-enabled TCP connections, no
ECN CE-marks are received and only beta_{loss} applies.</t>
<t>In other words, in response to detected loss: <list>
<t>FlightSize_(n+1) = FlightSize_n * beta_{loss}</t>
</list> and in response to an indication of a received ECN CE-mark:
<list>
<t>FlightSize_(n+1) = FlightSize_n * beta_{ecn}</t>
</list> where, as in <xref target="RFC5681"></xref>, FlightSize is the
amount of outstanding data in the network, upper-bounded by the sender's
congestion window (cwnd) and the receiver's advertised window (rwnd).
The higher the values of beta_{loss} and beta_{ecn}, the less aggressive
the response of any individual backoff event.</t>
<t>The appropriate choice for beta_{loss} and beta_{ecn} values is a
balancing act between path utilisation and draining the bottleneck
queue. More aggressive backoff (smaller beta_*) risks underutilising the
path, while less aggressive backoff (larger beta_*) can result in slower
draining of the bottleneck queue.</t>
<t>The Internet has already been running with at least two different
beta_{loss} values for several years: the value in <xref
target="RFC5681"></xref> is 0.5, and Linux CUBIC uses 0.7. ABE proposes
no change to beta_{loss} used by any current TCP implementations.</t>
<t>beta_{ecn} depends on how the response of a TCP connection to shallow
AQM marking thresholds is optimised. beta_{loss} reflects the preferred
response of each TCP algorithm when faced with exhaustion of buffers (of
unknown depth) signalled by packet loss. Consequently, for any given TCP
algorithm the choice of beta_{ecn} is likely to be algorithm-specific,
rather than a constant multiple of the algorithm's existing
beta_{loss}.</t>
<t>A range of experiments (section IV, <xref target="ABE2015"></xref>)
with NewReno and CUBIC over CoDel and PIE in lightly-multiplexed
scenarios have explored this choice of parameter. These experiments
indicate that CUBIC connections benefit from beta_{ecn} of 0.85 (cf.
beta_{loss} = 0.7), and NewReno connections see improvements with
beta_{ecn} in the range 0.7 to 0.85 (cf. beta_{loss} = 0.5).</t>
</section>
</section>
<section title="Specification">
<t>This document RECOMMENDS that experimental deployments multiply the
FlightSize by 0.8 and reduce the slow start threshold 'ssthresh' in
Congestion Avoidance in response to reception of a TCP segment that sets
the ECN-Echo flag.</t>
</section>
<section title="Status of the Update">
<t><!--
Statement on why EXP
-->This update is a sender-side only change. Like other
changes to congestion-control algorithms it does not require any change
to the TCP receiver or to network devices (except to enable an
ECN-marking algorithm <xref target="RFC3168"></xref> <xref
target="RFC7567"></xref>). If the method is only deployed by some TCP
senders, and not by others, the senders that use this method can gain
advantage, possibly at the expense of other flows that do not use this
updated method. This advantage applies only to ECN-marked packets and
not to loss indications. Hence, the new method can not lead to
congestion collapse.</t>
<t>The present specification has been assigned an Experimental status,
to provide Internet deployment experience before being proposed as a
Standards-Track update.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Authors N. Khademi, M. Welzl and G. Fairhurst were part-funded by the
European Community under its Seventh Framework Programme through the
Reducing Internet Transport Latency (RITE) project (ICT-317700). The
views expressed are solely those of the authors.</t>
<t>The authors would like to thank the following people for their
contributions to <xref target="ABE2015"></xref>: Chamil Kulatunga, David
Ros, Stein Gjessing, Sebastian Zander. Thanks to (in alphabetical order)
Bob Briscoe, Markku Kojo, John Leslie, Dave Taht and the TCPM WG for providing
valuable feedback on this document.</t>
<t>The authors would like to thank feedback on the congestion control
behaviour specified in this update received from the IRTF Internet
Congestion Control Research Group (ICCRG).</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>XX RFC ED - PLEASE REMOVE THIS SECTION XXX</t>
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Implementation" title="Implementation Status">
<t>
ABE is implemented as a patch for Linux and FreeBSD.
It is meant for research and available for
download from http://heim.ifi.uio.no/naeemk/research/ABE/
This code was used
to produce the test results that are reported in <xref target="ABE2015" />.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The described method is a sender-side only transport change, and does
not change the protocol messages exchanged. The security considerations
of <xref target="RFC3168"></xref> therefore still apply.</t>
<t>This document describes a change to TCP congestion control with ECN
that will typically lead to a change in the capacity achieved when flows
share a network bottleneck. Similar unfairness in the way that capacity
is shared is also exhibited by other congestion control mechanisms that
have been in use in the Internet for many years (e.g., CUBIC <xref
target="I-D.CUBIC"></xref>). Unfairness may also be a result of other
factors, including the round trip time experienced by a flow. This
advantage applies only to ECN-marked packets and not to loss
indications, and will therefore not lead to congestion collapse.</t>
</section>
<section title="Revision Information">
<t>XX RFC ED - PLEASE REMOVE THIS SECTION XXX</t>
<t>-01. This I-D now refers to draft-black-tsvwg-ecn-experimentation-02, which
replaces draft-khademi-tsvwg-ecn-response-00 to make a broader update to
RFC3168 for the sake of allowing experiments. As a result, some of the motivating
and discussing text that was moved from draft-khademi-alternativebackoff-ecn-03
to draft-khademi-tsvwg-ecn-response-00 has now been re-inserted here.
</t>
<t>-00. draft-khademi-tsvwg-ecn-response-00 and
draft-khademi-tcpm-alternativebackoff-ecn-00 replace
draft-khademi-alternativebackoff-ecn-03, following discussion in the
TSVWG and TCPM working groups. </t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<reference anchor="I-D.ECN-exp">
<front>
<title>Explicit Congestion Notification (ECN) Experimentation</title>
<author fullname="D. Black" initials="D." surname="Black"></author>
<date month="October" year="2016" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-black-tsvwg-ecn-experimentation-02" />
</reference>
&RFC2119;
&RFC3168;
&RFC5681;
&RFC7567;
</references>
<references title="Informative References">
<reference anchor="ABE2015"
target="http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf">
<front>
<title>Alternative Backoff: Achieving Low Latency and High
Throughput with ECN and AQM</title>
<author fullname="N. Khademi" initials="N." surname="Khademi"></author>
<author fullname="M. Welzl" initials="M." surname="Welzl"></author>
<author fullname="G. Armitage" initials="G." surname="Armitage"></author>
<author fullname="C. Kulatunga" initials="C." surname="Kulatunga"></author>
<author fullname="D. Ros" initials="D." surname="Ros"></author>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"></author>
<author fullname="S. Gjessing" initials="S." surname="Gjessing"></author>
<author fullname="S. Zander" initials="S." surname="Zander"></author>
<date month="July" year="2015" />
</front>
<seriesInfo name="CAIA Technical Report CAIA-TR-150710A,"
value="Swinburne University of Technology" />
</reference>
<reference anchor="I-D.CUBIC">
<front>
<title>CUBIC for Fast Long-Distance Networks</title>
<author fullname="I. Rhee" initials="I." surname="Rhee"></author>
<author fullname="L. Xu" initials="L." surname="Xu"></author>
<author fullname="S. Ha" initials="S." surname="Ha"></author>
<author fullname="A. Zimmermann" initials="A." surname="Zimmermann"></author>
<author fullname="L. Eggert" initials="L." surname="Eggert"></author>
<author fullname="R. Scheffenegger" initials="R."
surname="Scheffenegger"></author>
<date month="August" year="2016" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-tcpm-cubic-02" />
</reference>
<reference anchor="I-D.AQM-ECN-benefits">
<front>
<title>The Benefits of using Explicit Congestion Notification
(ECN)</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"></author>
<author fullname="M. Welzl" initials="M." surname="Welzl"></author>
<date month="November" year="2015" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-aqm-ecn-benefits-08" />
</reference>
<reference anchor="I-D.CoDel">
<front>
<title>Controlled Delay Active Queue Management</title>
<author fullname="K. Nichols" initials="K." surname="Nichols"></author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson"></author>
<author fullname="A. McGregor" initials="V." surname="McGregor"></author>
<author fullname="J. Iyengar" initials="J." surname="Iyengar"></author>
<date month="June" year="2016" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-aqm-codel-04" />
</reference>
<reference anchor="I-D.PIE">
<front>
<title>PIE: A Lightweight Control Scheme To Address the Bufferbloat
Problem</title>
<author fullname="R. Pan" initials="R." surname="Pan"></author>
<author fullname="P. Natarajan" initials="P." surname="Natarajan"></author>
<author fullname="F. Baker" initials="F." surname="Baker"></author>
<author fullname="G. White" initials="G." surname="White"></author>
<date month="September" year="2016" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-aqm-pie-10" />
</reference>
<reference anchor="ICC2002"
target="http://dx.doi.org/10.1109/ICC.2002.997262">
<front>
<title>TCP Increase/Decrease Behavior with Explicit Congestion
Notification (ECN)</title>
<author fullname="M. Kwon" initials="M." surname="Kwon"></author>
<author fullname="S. Fahmy" initials="S." surname="Fahmy"></author>
<date month="May" year="2002" />
</front>
<seriesInfo name="IEEE ICC" value="2002, New York, New York, USA" />
</reference>
<reference anchor="CODEL2012"
target="http://queue.acm.org/detail.cfm?id=2209336">
<front>
<title>Controlling Queue Delay</title>
<author fullname="Kathleen Nichols" initials="K" surname="Nichols">
<organization></organization>
</author>
<author fullname="Van Jacobson" initials="V" surname="Jacobson">
<organization>Google, Inc</organization>
</author>
<!--<workgroup>Communications of the ACM Vol. 55 No. 11, July, 2012, pp. 42-50.</workgroup>-->
<date month="July" year="2012" />
<abstract>
<t></t>
</abstract>
</front>
<format octets="" target="http://queue.acm.org/detail.cfm?id=2209336"
type="PDF" />
</reference>
&RFC7713;
&I-D.ietf-tcpm-dctcp;
&I-D.ietf-tcpm-accurate-ecn;
</references>
<!--
<section anchor="sec-internal" title="Internal comments">
<t>This is a place for taking notes.</t>
<t>It's interesting that our document proposes almost exactly what RFC3168 mentions in sec. 20.2: " A second possible use for the fourth ECN codepoint would have been to
give the router two separate codepoints for the indication of
congestion, CE(0) and CE(1), for mild and severe congestion
respectively. While this could be useful in some cases, this
certainly does not seem a compelling requirement at this point. If
there was judged to be a compelling need for this, the complications
of incremental deployment would most likely necessitate more that
just one codepoint for this function.".</t>
</section>
-->
<!-- Change Log
v00 2006-03-15 EBD Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:33:50 |