One document matched: draft-khademi-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. -->
<!--<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
-->
<!-- 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 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-alternativebackoff-ecn-00"
ipr="trust200902" updates="3168">
<!-- 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 month="June" year="2015" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- 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 is less conservative than the TCP reaction in response 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 ECN-marked a packet than when a packet was lost. Future
versions of this document will discuss SCTP as well as other transports
using ECN.</t>
</abstract>
</front>
<middle>
<!-- <section title="Definitions" anchor='sec-def'>
<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>Explicit Congestion Notification (ECN) is specified in <xref
target="RFC3168"></xref>. This allows a network device that uses Active
Queue Management (AQM) to CE-mark rather than drop ECN-capable packets
when incipient congestion is detected.</t>
<t>When an ECN-capable transport is used over a path that supports ECN,
it provides the opportunity for flows to improves their performance in
the presence of incipient congestion <xref
target="I-D.AQM-ECN-benefits"></xref>.</t>
<t><xref target="RFC3168"></xref> not only specifies the router use of the ECN field, it also
specifies a TCP procedure for using ECN. This states that a TCP
sender should treat the ECN indication of congestion in the same way
as that of a non-ECN-Capable TCP flow experiencing loss, by halving
the congestion window "cwnd" and by reducing the slow start threshold
"ssthresh". <xref target="RFC5681"></xref> stipulates that TCP congestion control sets
"ssthresh" to max(FlightSize / 2, 2*SMSS) in response to packet loss.
Consequently, a non-ECN enabled standard TCP flow using this reaction needs significant
queue space: it can only fully utilize
a bottleneck when the length of the link queue (or the AQM dropping threshold) is at least
the bandwidth-delay product of the flow.
CUBIC can fully utilize a link with a smaller queue because it multiplies
the current cwnd with 0.8 in response to packet loss <xref target="ID.CUBIC"/>
(since kernel version 2.6.25 (2008), the Linux implementation uses a value of 0.7).
In case of a DropTail (FIFO) queue without AQM, this
increases the risk of creating a standing queue <xref target="CODEL2012"/>.
</t>
<t>Devices implementing AQM should be the only source of marking
for packets from ECN-capable senders. AQM mechanisms typically strive to
maintain a small queue length, regardless of the bandwidth-delay product
of a flows passing through them. Receipt of a CE-mark therefore indicates
that reacting less conservatively would be appropriate.</t>
<t>Results reported in <xref target="ABE-paper"></xref> show significant
benefits (improved throughput, resulting in reduced completion times for
short flows) when reacting to ECN-Echo by multiplying cwnd and sstthresh
with a value in the range [0.7..0.85] rather than 0.5.</t>
</section>
<section anchor="sec-update3168"
title="Updating the Sender-side ECN Reaction">
<t>This document specifies an updated TCP reaction to the receipt of
CE-marked packets.</t>
<t>The first paragraph of Section 6.1.2, "The TCP Sender", in <xref
target="RFC3168"></xref> contains the following text:</t>
<t>"If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK
packet with the ECN-Echo flag set in the TCP header), then the sender
knows that congestion was encountered in the network on the path from
the sender to the receiver. The indication of congestion should be
treated just as a congestion loss in non- ECN-Capable TCP. That is, the
TCP source halves the congestion window 'cwnd' and reduces the slow
start threshold 'ssthresh'."</t>
<t>This memo updates this text to:</t>
<t>"If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK
packet with the ECN-Echo flag set in the TCP header), then the sender
knows that congestion was encountered in the network on the path from
the sender to the receiver. The indication of congestion should induce a
less conservative reaction than loss: the TCP source multiplies the
congestion window 'cwnd' with 0.8 and reduces the slow start threshold
'ssthresh'."</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors 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="ABE-paper"></xref>: Chamil Kulatunga,
David Ros, Stein Gjessing, Sebastian Zander.</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>This document describes a change to TCP congestion control that can
make a TCP sender more aggressive than flows using RFC 3819. This could
lead to an unfair allocation in rates at a bottleneck. Similar
unfairness is also exhibited by other congestion control mechanisms that
have been in use in the Internet for many years (e.g. Cubic <xref
target="ID.CUBIC"></xref>).</t>
<t>XXX This section to be completed XXX.</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">
<!-- &RFC2119;
-->
&RFC3168;
&RFC5681;
</references>
<references title="Informative References">
<reference anchor="ABE-paper">
<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>
</front>
<seriesInfo name="CAIA technical report CAIA-TR-150710A, July 2015"
value="http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf" />
<seriesInfo name="NOTE:"
value="this document may not be available at draft submission date. We will do our best to make it available as soon as possible, and definitely before IETF-93" />
</reference>
<reference anchor="ID.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="June" year="2015" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-tcpm-cubic-00" />
</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="June" year="2015" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-aqm-ecn-benefits-05" />
</reference>
<reference anchor="CODEL2012" target="http://queue.acm.org/detail.cfm?id=2209336"><front><title>Controlling Queue Delay</title><author initials="K" surname="Nichols" fullname="Kathleen Nichols"><organization/></author><author initials="V" surname="Jacobson" fullname="Van Jacobson"><organization>Google, Inc</organization></author><!--<workgroup>Communications of the ACM Vol. 55 No. 11, July, 2012, pp. 42-50.</workgroup>--><date year="2012" month="July"/><abstract><t></t></abstract></front><format type="PDF" octets="" target="http://queue.acm.org/detail.cfm?id=2209336"/></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:29:13 |