One document matched: draft-khademi-tsvwg-ecn-response-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 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">
]>
<?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-00"
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) Congestion Control Response</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>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.</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>. It 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>
<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>
<section anchor="sec-update3168"
title="Updating the Sender-side ECN Reaction">
<t>This section specifies an update to <xref target="RFC3168"></xref>
(and corresponding text in <xref target="RFC4774"></xref>) and refers to an
experiment that is 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 title="Update to RFCs 3168 and 4774">
<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
packet, the congestion control algorithms followed at the end-systems
MUST make a congestion control response as specified in [RFC3168] or
its updates. For example, for ECN-Capable TCP the source TCP 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 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. 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
TCP mechanisms following loss, as required in <xref
target="RFC3168"></xref>.</t>
</section>
<section title="ABE: An Experiment That Follows the New Rule">
<t>This update to <xref target="RFC3168"></xref> enables
experimentation with a different backoff behavior in response to a
CE-mark than in response to packet loss. One experiment, called
"Alternative Backoff with ECN" (ABE), is based upon <xref
target="ABE2015"></xref> and defined in <xref
target="I-D.ABE"></xref>.</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>
</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">
&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;
</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:44:51 |