One document matched: draft-khademi-tsvwg-ecn-response-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.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 RFC7713 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.ietf-tcpm-accurate-ecn SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tcpm-accurate-ecn-00.xml">
<!ENTITY I-D.ietf-tcpm-dctcp SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tcpm-dctcp-01.xml">
<!ENTITY I-D.briscoe-tsvwg-ecn-l4s-id SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-briscoe-tsvwg-ecn-l4s-id-01.xml">
<!ENTITY I-D.bagnulo-tsvwg-generalized-ecn SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-bagnulo-tsvwg-generalized-ecn-01.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="std" docName="draft-khademi-tsvwg-ecn-response-01"
ipr="trust200902" updates="3168,4774">
<!-- 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="ECN-response">Updating the Explicit Congestion Notification
(ECN) Specification to Allow IETF Experimentation</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 document relaxes recommendations and prescriptions from RFC3168
and RFC4774 that get in the way of experimentation with different ECN
strategies. First, RFC3168 and RFC4774 state that, upon the receipt by
an ECN-Capable transport of a single CE packet, the congestion control
algorithms followed at the end-systems MUST be essentially the same as
the congestion control response to a single dropped packet. This
document relaxes this rule in order to encourage experimentation with
different backoff strategies. <!-- This sender-side update makes it possible to achieve
greater benefits with ECN, encouraging wider ECN deployment. -->
Second, this document allows future IETF specifications to use the
ECT(1) codepoint in ways that are currently prohibited by RFC3168.
Third, this document allows future IETF experiments to use the ECT(0) or
ECT(1) codepoint on any TCP segment.</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>This document relaxes three limitations that are due to specific text
in <xref target="RFC3168"></xref> and, in one case, also <xref
target="RFC4774"></xref>.</t>
<section anchor="sec-rule1"
title="Differently reacting to ECN-marks and loss">
<t>Explicit Congestion Notification (ECN) as specified in <xref
target="RFC3168"></xref> allows a network device that uses Active
Queue Management (AQM) to set the Congestion Experienced (CE)
codepoint in the ECN field of the IP packet header, rather than to
drop ECN-capable packets when incipient congestion is detected. When
an ECN-capable transport is used over a path that supports ECN, this
provides the opportunity for flows to improve 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. 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>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. Such behavior is however prohibited by
the rules in <xref target="RFC3168"></xref>.</t>
<t>ECN has seen little deployment so far. Apple recently announced
their intention to enable ECN in iOS 9 and OS X 10.11 devices <xref
target="WWDC2015"></xref>. By 2014, server-side ECN negotiation was
observed to be provided by the majority of the top million web servers
<xref target="PAM2015"></xref>, and only 0.5% of websites incurred
additional connection setup latency using RFC3168-compliant
ECN-fallback mechanisms. <xref target="RFC7567"></xref> states that
"deployed AQM algorithms SHOULD support Explicit Congestion
Notification (ECN) as well as loss to signal congestion to endpoints"
and <xref target="I-D.AQM-ECN-benefits"></xref> encourages this
deployment. However, the limitation of <xref target="RFC3168"></xref>
restricts a sender to react to notification of a CE-mark in the same
way as if a packet was lost. This prohibits experimentation with ECN
mechanisms that could yield greater benefits. This specification
therefore relaxes this constraint.</t>
<section anchor="sec-rationale"
title="Discussion: 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>
<t>This update to <xref target="RFC3168"></xref> that enables the
IETF to specify experiments with a different backoff behavior in
response to a CE-mark than in response to packet loss is utilized by
an experiment called "Alternative Backoff with ECN" (ABE). ABE is
based upon <xref target="ABE2015"></xref> and defined in <xref
target="I-D.ABE"></xref>.</t>
</section>
</section>
<section anchor="sec-rule2" title="Senders setting the ECT(1) codepoint">
<t>Future IETF experiments may require setting the ECT(0) or ECT(1)
codepoints differently from what <xref target="RFC3168"></xref>
recommends or requires.</t>
<t>[NOTE: This usage was also specified in ECN-NONCE.]</t>
<t>This update may also allow the iETF to specify future mechanisms
that associate alternate ECN semantics with this codepoint. An
experiment called "L4S" proposes to use the ECT(1) codepoint to
indicate in which of two queues a packet should be placed <xref
target="I-D.briscoe-tsvwg-ecn-l4s-id"></xref>.</t>
</section>
<section anchor="sec-rule3" title="ECT(0) and ECT(1) on control packets">
<t>Diverging from recommendations or requirements in <xref
target="RFC3168"></xref>, future IETF experiments may be specified to
use the ECT(0) or ECT(1) codepoint. This choice of codepoint can be
used to signal alternative ECN semantics. This supersedes the
rationale in Section 20 of <xref target="RFC3168"></xref> that argued
against the use of ECT(1) to specify alternate ECN semantics, instead
arguing for attaching specific ECN semantics to a Differentiated
Services Code Point (DSCP).</t>
<t>This update may also allow the iETF to specify future updates to
transport protocol use of ECN. A proposal,<xref
target="I-D.bagnulo-tsvwg-generalized-ecn"> </xref>, provides
arguments for using the ECT(0) or ECT(1) codepoint on a broader range
of TCP packets for which such usage is precluded by <xref
target="RFC3168"></xref>: SYNs, pure ACKs, retransmitted packets and
window probe packets.</t>
</section>
</section>
<section anchor="sec-update3168" title="Updating RFC3168 and RFC4774">
<t>This section specifies updates to <xref target="RFC3168"></xref> (and
corresponding text in <xref target="RFC4774"></xref>) and refers to
experiments that are possible within the framework provided by the
update.</t>
<section title="RFC 2119">
<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"></xref>.</t>
</section>
<section anchor="sec-rationale-scope" title="Scope of this update">
<t>Internet deployment of new mechanisms enabled by this update
REQUIRE IETF specification in an Experimental or a Standards Track RFC
approved by the IESG.</t>
<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>
<t>The remainder of this section lists a set of changes to <xref
target="RFC3168"></xref> that are not specific replacements of text
passages.</t>
</section>
<section title="Changes to the meaning of a CE-Mark codepoint">
<t>This document specifies an update to the TCP sender reaction that
follows when the TCP receiver signals that ECN CE-marked packets have
been received.</t>
<t><xref target="RFC3168"></xref> and <xref target="RFC4774"></xref>
contain the following text:</t>
<t>"Upon the receipt by an ECN-Capable transport of a single CE
packet, the congestion control algorithms followed at the end-systems
MUST be essentially the same as the congestion control response to a
*single* dropped packet. For example, for ECN-Capable TCP the source
TCP is required to halve its congestion window for any window of data
containing either a packet drop or an ECN indication."</t>
<t>This memo updates the preceding text by replacing it with the
following text:</t>
<t>"Upon the receipt by an ECN-Capable transport of a single CE-Marked
packet, the congestion control algorithms followed at the endpoints
MUST make a congestion control response as specified in <xref
target="RFC3168"></xref> or its updates. For example, an ECN-Capable
TCP sender could halve its congestion window for any window of data
containing either a packet drop or an ECN indication."</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 the preceding text by replacing it with the
following text:</t>
<t>"If a TCP sender receives an indication of a receibed 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. An
indication of congestion, signalled by reception of the ECN-Echo flag
(with the semantics defined in <xref target="RFC3168"></xref>) MUST
produce a rate reduction of at least 15%, so that flows sharing the
same bottleneck can increase their share of the capacity. The
indication of congestion could be treated in the same way as if the
flow had experienced loss, but future congestion control methods are
allowed to specify a reduction that is<!--(roughly the reduction achieved by multiplying FlightSize with 0.85).-->
less than the reduction for congestion loss.</t>
<t><!--Statement on loss, because RFC3168 doesn't say much about loss when using ECN-->An
ECN-capable network device cannot eliminate the possibility of packet
loss. A drop may still occur due to a traffic burst exceeding the
instantaneous available capacity of a network buffer or as a result of
the AQM algorithm (overload protection mechanisms, etc <xref
target="RFC7567"></xref>). Whatever the cause of loss, detection of a
missing packet needs to trigger the standard loss-based congestion
control response". This update explicitly does not change the use of
standard protocol mechanisms following loss, as required in <xref
target="RFC3168"></xref>.</t>
</section>
<section title="Setting ECT(0) and ECT(1) Codepoints">
<t>New IETF specifications MAY permit a sender to set the ECT(0) or
ECT(1) codepoint on a protocol control packet (including TCP segments
for which <xref target="RFC3168"></xref> does not allow or recommend
setting these codepoints.) </t>
<t> [AUTHORS' NOTE: Future versions of this document may take the form
of such explicit text replacements.]</t>
</section>
<section title="Clarification to the usage of the ECT(1) Codepoint">
<t><xref target="RFC3168"></xref> notes that a router may treat and
mark/drop packets differently depending on whether they observe the
ECT(0) or ECT(1) codepoint. This specification permits new IETF
specifications to set or read the ECT(1) codepeoint. It clarifies that
these specifications do not necessarily treat ECT(1) as equivalent to
ECT(0).</t>
<t>Network devices using IETF-defined DSCPs MUST NOT re-mark packets
to the ECT(1) codepoint. Specifically, the methods described in
earlier ECN implementations using this codepoint as a congestion mark
(described in Section 11.2.1 of <xref target="RFC3168"></xref>) are
NOT RECOMMENDED for deployment in the current Internet. </t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The 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>
</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>A congestion control backoff that is less in response to ECN than the
response to a packet loss can lead to a change in the capacity achieved
when flows share a network bottleneck. This can result in redistribution
of capacity between sharing flows, potentially resulting in unfairness
in the way that capacity is shared. This potential gain applies only to
ECN-marked packets using the updated method (and not to detected packet
loss). Similar unfairness can be exhibited by congestion control
mechanisms that have been used 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.</t>
<t>Packet loss can be expected from an AQM algorithm experiencing
persistent queuing, but could also imply the presence of faulty
equipment or media in a path, or it may imply the presence of congestion
<xref target="RFC7567"></xref>. The update does not change the
congestion control response to packet loss, and will therefore not lead
to congestion collapse.</t>
<t>[AUTHORS' NOTE: Security considerations of the more relaxed rules of
using ECT(0) vs. ECT(1) and usage of these ECT codepoints on any TCP
segments will be included in the next version of this document.]</t>
</section>
<section title="Revision Information">
<t>XX RFC ED - PLEASE REMOVE THIS SECTION XXX</t>
<t>-01. Broadened the scope to also cover ECT(0) vs. ECT(1) usage and
using ECT(0) or ECT(1) codepoints on any TCP segments.</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">
&RFC2119;
&RFC3168;
&RFC4774;
&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="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>
<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="PAM2015" target="http://ecn.ethz.ch/ecn-pam15.pdf">
<front>
<title>Enabling Internet-wide Deployment of Explicit Congestion
Notification</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell"></author>
<author fullname="Mirja Kuhlewind" initials="M." surname="Kuhlewind"></author>
<author fullname="Damiano Boppart" initials="D." surname="Boppart"></author>
<author fullname="Iain Learmonth" initials="I." surname="Learmonth"></author>
<author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"></author>
<author fullname="Richard Scheffenegger" initials="R."
surname="Scheffenegger"></author>
<date month="March" year="2015" />
</front>
<seriesInfo name="Proceedings of the"
value="2015 Passive and Active Measurement Conference, New York" />
</reference>
<reference anchor="WWDC2015"
target="https://developer.apple.com/videos/wwdc/2015/?id=719">
<front>
<title>Your App and Next Generation Networks</title>
<author fullname="Prabhakar Lakhera" initials="P." surname="Lakhera"></author>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire"></author>
<date month="June" year="2015" />
</front>
<seriesInfo name="Apple Worldwide Developers Conference"
value="2015, San Francisco, USA" />
</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="March" year="2016" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-aqm-codel-03" />
</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="April" year="2016" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-aqm-pie-07" />
</reference>
<reference anchor="I-D.ABE">
<front>
<title>TCP Alternative Backoff with ECN (ABE)</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-tcpm-alternativebackoff-ecn-00" />
</reference>
&RFC7713;
&I-D.ietf-tcpm-dctcp;
&I-D.ietf-tcpm-accurate-ecn;
&I-D.briscoe-tsvwg-ecn-l4s-id;
&I-D.bagnulo-tsvwg-generalized-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:36:51 |