One document matched: draft-khademi-alternativebackoff-ecn-03.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-alternativebackoff-ecn-03"
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 day="03" month="April" 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 provides an experimental update to RFC3168. It updates the
TCP sender-side reaction to a congestion notification received via
Explicit Congestion Notification (ECN). The updated method reduces cwnd
by a smaller amount than TCP does in 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 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>. 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 drop ECN-capable
packets when incipient congestion is detected. When an ECN-capable
transport is used over a path that supports ECN, it 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. 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 multipler of 0.5 (halving cwnd and sshthresh after packet
loss) is not the only available strategy. As defined in <xref
target="ID.CUBIC"></xref>, CUBIC multiplies the current cwnd by 0.8 in
response to loss (although the Linux implementation of CUBIC has used a
multiplier of 0.7 since kernel version 2.6.25 released in 2008).
Consequently, CUBIC utilise 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 queue length, regardless
of the bandwidth-delay product of flows passing through them. Receipt of
an ECN CE-mark might therefore reasonably be taken to indicate that a
small bottleneck queue exists in the path, and hence the TCP flow would
benefit from using a less aggressive backoff multiplier.</t>
<t>Results reported in <xref target="ABE2015"></xref> show significant
benefits (improved throughput) when reacting to ECN-Echo by multiplying
cwnd and sstthresh with a value in the range [0.7..0.85]. <xref
target="sec-rationale"></xref> describes the rationale for this change.
<xref target="sec-update3168"></xref> specifies a change to the TCP
sender backoff behaviour in response to an indication that CE-marks have
been received by the receiver.</t>
</section>
<section anchor="sec-rationale" title="Discussion">
<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 in
reaction to 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."</t>
<section anchor="sec-rationale-context"
title="Why use ECN to vary the degree of backoff?">
<t>The classic rule-of-thumb dictates 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
enough 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 (lmany concurrent TCP
connections). However, it interacts badly with lightly-multiplexed
cases (few concurrent connections) over high BDP paths. Conventional
TCP backoff in such cases leads to gaps in packet transmission and
under-utilisation of the path.</t>
<t>In an ideal world, the TCP sender would adapt its backoff strategy
to match the effective depth at which a bottleneck begins indicating
congestion. In the practical world, <xref target="ABE2015"></xref>
proposes using the existence of ECN CE-marks to infer whether a path's
bottleneck is AQM-enabled (shallow queue) or classic DropTail (deep
queue), and adjust backoff accordingly. This results in a change to
<xref target="RFC3168"></xref>, which recommended that TCP senders
respond in the same way following indication of a received ECN CE-mark
and a packet loss, making these equivalent signals of congestion. (The
idea to change this behaviour pre-dates ABE. <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 deal with RED-based bottlenecks that were not necessarily
configured to emulate a shallow queue.)</t>
<t><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.
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.</t>
</section>
<section anchor="sec-rationale-multiplier"
title="Choice of ABE multiplier">
<t>ABE decouples a TCP sender's reaction to loss and ECN CE-marks. The
description respectively uses beta_{loss} and beta_{ecn} to refer to
the multiplicative decrease factors applied in response to packet loss
and in response to an indication of a received CN CE-mark 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_*, 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 we want to optimise the reponse of a TCP
connection to shallow AQM marking thresholds. 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 (c.f., beta_{loss} = 0.5).</t>
</section>
</section>
<section anchor="sec-update3168"
title="NEW: Updating the Sender-side ECN Reaction">
<t>This section specifies an experimental update to <xref
target="RFC3168"></xref>.</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 RFC 3168">
<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>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 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. This indication of congestion
could be treated in the same way as a congestion loss, however
reception of the ECN-Echo flag SHOULD produce a reduction in
FlightSize that is less than the reduction had the flow experienced
loss. The reduction needs to be sufficient to allow flows sharing a
bottleneck to increase their share of the capacity. This reduction
MUST be less than 0.85 (at least a 15% reduction).</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 loss,
because a drop may 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 explicitly does not update this behaviour.</t>
<t>In addition, this document RECOMMENDS that experimental deployments
method multiply the FlightSize by 0.8 and reduce the slow start
threshold 'ssthresh' 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>
<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, 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 RFC 3819 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="ID.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>
</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;
&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="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="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>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:24:31 |