One document matched: draft-khademi-tcpm-alternativebackoff-ecn-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.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.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml-->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2309 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2481 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2481.xml">
<!ENTITY RFC3168 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3649 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml">
<!ENTITY RFC3742 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3742.xml">
<!ENTITY RFC3758 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml">
<!ENTITY RFC4340 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4774 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml">
<!ENTITY RFC5562 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5562.xml">
<!ENTITY RFC5670 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5670.xml">
<!ENTITY RFC5681 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY RFC5696 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5696.xml">
<!ENTITY RFC6040 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml">
<!ENTITY RFC6679 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<!ENTITY RFC6789 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6789.xml">
<!ENTITY RFC7567 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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.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-00"
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 day="31" month="May" 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-response"></xref> encourages wider ECN deployment by
relaxing a rule that prohibited certain experiments. This rule, from
<xref target="RFC3168"></xref>, required the congestion control response
to an ECN CE-mark to be similar to the response to packet loss. Without
this rule, it is possible to define a new sender reaction to being
notified of a CE-mark that differs from the reaction to the detection of
loss. <xref target="I-D.ECN-response"></xref> provides the rationale for
such a different behaviour; in brief, a CE-mark is likely to indicate a
shorter queue than packet loss, and 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>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-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 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="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>-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-response">
<front>
<title>Updating the ECN Congestion Control Response</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="G. Fairhurst" initials="G." surname="Fairhurst"></author>
<date month="May" year="2016" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-khademi-tsvwg-ecn-response-00" />
</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="January" year="2016" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-tcpm-cubic-01" />
</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>The Benefits of using Explicit Congestion Notification
(ECN)</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="December" year="2015" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-aqm-codel-02" />
</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>
<author fullname="B. VerSteeg" initials="B." surname="VerSteeg"></author>
<author fullname="M.S. Prabhu" initials="M.S." surname="Prabhu"></author>
<author fullname="C. Piglione" initials="C." surname="Piglione"></author>
<author fullname="V. Subramanian" initials="V."
surname="Subramanian"></author>
<date month="November" year="2015" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-aqm-pie-03" />
</reference>
</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:40:42 |