One document matched: draft-ietf-aqm-ecn-benefits-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!--<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
-->
<!-- http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml-->
<!ENTITY RFC2309 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2481 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2481.xml">
<!ENTITY RFC3168 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3649 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml">
<!ENTITY RFC3742 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3742.xml">
<!ENTITY RFC3758 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml">
<!ENTITY RFC4340 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4774 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml">
<!ENTITY RFC5562 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5562.xml">
<!ENTITY RFC5670 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5670.xml">
<!ENTITY RFC5681 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY RFC5696 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5696.xml">
<!ENTITY RFC6040 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml">
<!ENTITY RFC6679 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<!ENTITY RFC6789 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6789.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml2rfc.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc category="info" docName="draft-ietf-aqm-ecn-benefits-04"
ipr="trust200902">
<!-- noModificationTrust200902 noDerivativesTrust200902 pre5378Trust200902">-->
<!-- updates="6298"> -->
<!-- ipr="full3978"> -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<!-- <title abbrev="Abbreviated Title">Coupled congestion control</title> -->
<title abbrev="Benefits of ECN">The Benefits of using Explicit Congestion
Notification (ECN)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<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>
<phone></phone>
<email>gorry@erg.abdn.ac.uk</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>
<phone>+47 22 85 24 20</phone>
<email>michawe@ifi.uio.no</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="05" month="May" year="2015" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup></workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>ecn, aqm, sctp, tcp</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>The goal of this document is to describe the potential benefits when
applications use a transport that enables Explicit Congestion
Notification (ECN). The document outlines the principal gains in terms
of increased throughput, reduced delay and other benefits when ECN is
used over network paths that include equipment that supports
ECN-marking. It also describes methods that can help successful
deployment of ECN. It does not propose new algorithms to use ECN, nor
does it describe the details of implementation of ECN in endpoint
devices (Internet hosts), routers or other network devices.</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>Internet Transports (such as TCP and SCTP) are implemented in
endpoints (Internet hosts) and have two ways to detect network
congestion: the loss of an IP packet or, if Explicit Congestion
Notification (ECN) <xref target="RFC3168"></xref> is enabled, the
reception of a packet with a Congestion Experienced (CE)-marking in the
IP header. Both of these are treated by transports as indications of
congestion. ECN may also be enabled by other transports: UDP
applications that provide congestion control may enable ECN when they
are able to correctly process the ECN signals <xref
target="ID.RFC5405.bis"></xref> (e.g., ECN with RTP <xref
target="RFC6679"></xref>).</t>
<t>Active Queue Management (AQM) <xref target="ID.RFC2309.bis"></xref> is a
class of techniques that can be used by network devices (a router,
middlebox, or other device that forwards packets through the network) to
manage the size of queues in network buffers. A network device that does
not support AQM typically uses a drop-tail policy to drop excess IP
packets when its queue becomes full. The discard of packets serves as a
signal to the end-to-end transport that there may be congestion on the
network path being used. This results in a congestion control reaction
by the transport to reduce the maximum rate permitted by the sending
endpoint.</t>
<t>When an application uses a transport that enables use of ECN <xref
target="RFC3168"></xref>, the transport layer sets the ECT(0) or ECT(1)
codepoint in the IP header of packets that it sends. This indicates to
network devices that they may mark, rather than drop the ECN-capable IP
packets. A network device can then signal incipient congestion (network
queueing) at a point before a transport experiences congestion loss or
additional queuing delay. The marking is generally performed as the
result of various AQM algorithms, where the exact combination of AQM/ECN
algorithms does not need to be known by the transport endpoints.</t>
<t>Since ECN makes it possible for the network to signal the presence of
incipient congestion without incurring packet loss, it lets the network
deliver some packets to an application that would otherwise have been
dropped if the application or transport did not support ECN. This packet
loss reduction is the most obvious benefit of ECN, but it is often
relatively modest. However, enabling ECN can also result in a number of
beneficial side-effects, some of which may be much more significant than
the immediate packet loss reduction from ECN-marking instead of dropping
packets. Several benefits reduce latency (e.g., reduced Head-of-Line
Blocking). The remainder of this document discusses the potential for
ECN to positively benefit an application without making specific
assumptions about configuration or implementation.</t>
<t><xref target="RFC3168"></xref> describes a method in which a network
device sets the CE codepoint of an ECN-Capable packet at the time that
the network device would otherwise have dropped the packet. While it has
often been assumed that network devices should CE-mark packets at the
same level of congestion at which they would otherwise have dropped
them, <xref target="ID.RFC2309.bis"></xref> recommends that network devices
allow independent configuration of the settings for AQM dropping and ECN
marking. Such separate configuration of the drop and mark policies is
supported in some network devices.</t>
<t>The focus of this document is on usage of ECN by transport and
application layer flows, not its implementation in endpoint hosts, or in
routers and other network devices.</t>
<section title="Terminology">
<t>The following terms are used:</t>
<t>Network device: A router, middlebox, or other device that forwards
IP packets through the network.</t>
<t>Endpoint: An Internet host that terminates a transport protocol
connection across an Intenet path.</t>
<t>non-ECN Capable: An IP packet with a zero value codepoint. A
non-ECN capable packet may be forwarded, dropped or queued by a
network device.</t>
<t>Incipient Congestion: The detection of congestion when it is
starting, perhaps by noting that the arrival rate exceeds the
forwarding rate.</t>
<t>CE: Congestion Experienced codepoint, a value marked in the IP
packet header.</t>
<t>ECN-Capable: An IP packet with a header marked with a non-zero ECN
value (i.e., with a ECT(0), ECT(1), or CE codepoint). An ECN-capable
network device may forward, drop or queue a packet and may choose to
CE-mark an ECN-capable packet when there is incipient congestion.</t>
</section>
</section>
<section title="Benefit of using ECN to avoid Congestion Loss">
<t>When a non-ECN capable packet would need to queue or discard as a
result of incipient congestion, an ECN-enabled router may be expected to
CE-mark, rather than drop an ECN-enabled IP packet <xref
target="ID.RFC2309.bis"></xref>. An application can benefit from this
marking in several ways:</t>
<section anchor="throughput" title="Improved Throughput">
<t>ECN can improve the throughput of an application, although this
increase in throughput offered by ECN is often not the most
significant gain.</t>
<t>When an application uses a light to moderately loaded network path,
the number of packets that are dropped due to congestion is small.
Using an example from Table 1 of <xref target="RFC3649"></xref>, for a
standard TCP sender with a Round Trip Time, RTT, of 0.1 seconds, a
packet size of 1500 bytes and an average throughput of 1 Mbps, the
average packet drop ratio is 0.02 (i.e., 1 in 50 packets). This
translates into an approximate 2% throughput gain if ECN is enabled.
In heavy congestion, packet loss may be unavoidable with, or without,
ECN.</t>
<t>ECN avoids the inefficiency of dropping data that has already made
it across at least part of the network path.</t>
</section>
<section anchor="sec-hol" title="Reduced Head-of-Line Blocking">
<t>Many transports provide in-order delivery of received data segments
to the applications they support. When an AQM scheme drops a packet as
a signal of incipient congestion, this triggers loss recovery and a
congestion control response. For a transport providing in-order
delivery, this requires that the transport receiver stalls (or waits)
for all data that was sent ahead of a particular segment to be
correctly received before it can forward any later data to the
application. This is the usual requirement for TCP and SCTP. PR-SCTP
<xref target="RFC3758"></xref>, UDP <xref
target="RFC0768"></xref><xref target="ID.RFC5405.bis"></xref>, and
DCCP <xref target="RFC4340"></xref> provide a transport that does not
have this requirement. A congestive loss therefore creates a delay of
at least one RTT after a loss event before data can be delivered to an
application. We call this Head-of-Line (HOL) blocking.</t>
<t>Using ECN, an application continues to receive data when there is
incipient congestion. Use of ECN avoids the additional reordering
delay in a reliable transport. (When a transport receives a CE-marked
packet, it still requests the sender to make an appropriate
congestion-response to reduce the maximum transmission rate for future
traffic <xref target="ID.RFC5405.bis"></xref>.)</t>
</section>
<section title="Reduced Probability of RTO Expiry">
<t>A reduction in the possibility of packet loss can be significant
for a reliable transport for a class of applications that send a burst
of segments and then becomes idle (either because the application has
no further data to send or the network prevents sending further data -
e.g., flow or congestion control at the transport layer).</t>
<t>Standard transport recovery methods (such as Fast Recovery <xref
target="RFC5681">(</xref>) are often not able to recover from the loss
of the last segment (or last few segments) of a traffic burst (also
known as a "tail loss"). This is because the receiver is unaware that
the lost segments were actually sent, and therefore generates no
feedback <xref target="Fla13"></xref>. Retransmission of these
segments therefore relies on expiry of a transport retransmission
timer (e.g., expiry of the TCP or SCTP retransmission timeout, RTO
<xref target="RFC5681"></xref>).</t>
<t>A timer expiry results in the consequent loss of state about the
network path being used. This typically includes resetting path
estimates such as the RTT, re-initialising the congestion window, and
possibly updates to other transport state. This can reduce the
performance of the transport until it again adapts to the path.</t>
<t>When incipient congestion occurs at the tail of a burst, an
ECN-capable network device can CE-mark the packet(s), rather than
triggering drop. This allows the transport to avoid the retransmission
timeout, which can reduce application level latency and improve the
throughput for applications that send intermittent bursts of data and
rely upon timer-based recovery of packet loss. The benefit is expected
to be especially significant when ECN is used on TCP SYN/ACK packets
<xref target="RFC5562"></xref> where the RTO interval may be large
because in this case TCP cannot base the timeout period on prior RTT
measurements from the same connection.</t>
</section>
<section title="Applications that do not Retransmit Lost Packets">
<t>Some latency-critical applications do not retransmit lost packets,
yet may be able to adjust the sending rate in the presence of
incipient congestion. Examples of such applications include UDP-based
services that carry Voice over IP (VoIP), interactive video or
real-time data. The performance of many such applications degrades
rapidly with increasing packet loss, and many therefore employ
mechanisms (e.g., packet forward error correction, data duplication,
or media codec error concealment) to mitigate the effect of congestion
loss on the application. However, relying on such mechanisms adds
complexity and consumes additional network capacity, reducing the
available capacity for application data and contributing to the path
latency when congestion is experienced.</t>
<t>By decoupling congestion control from loss, ECN can allow the
transports supporting these applications to reduce their rate before
the application experiences loss from congestion. Because this reduces
the negative impact of using loss-hiding mechanisms, ECN can have a
direct positive impact on the quality experienced by the users of
these applications.</t>
</section>
<section anchor="sec-visibility"
title="Making Incipient Congestion Visible">
<t>A characteristic of using ECN is that it exposes the presence of
congestion on a network path to the transport and network layers. This
information can be used for monitoring the level of congestion along
the path by a transport/application or a network operator. Metering
packet loss is harder. ECN measurements are used by Congestion
Exposure (ConEx) <xref target="RFC6789"></xref>.</t>
<t>A network flow that only experiences CE-marking and no loss implies
that the sending endpoint is experiencing only congestion and not
other sources of packet loss (e.g., link corruption or loss in
middleboxes). The converse is not true - a flow may experience a
mixture of ECN-marking and loss when there is only congestion, or when
there is a combination of packet loss and congestion <xref
target="ID.RFC2309.bis"></xref>. Recording the presence of CE-marked
packets can therefore provide information about the current congestion
level experienced on a network path. However, it is important to note
that any Internet path may also experience congestive loss (e.g., due
to queue overflow, AQM methods that protect other flows, middlebox
behaviours), so an absence of CE-marks does not indicate a path has
not experienced congestion.</t>
</section>
<section title="Opportunities for new Transport Mechanisms">
<t>Loss is regarded as the standard signal from a network device
experiencing congestion. In contrast, CE-marked packets carry an
indication that network queues are filling, without incurring loss.
This introduces the possibility to provide richer feedback (more
frequent and fine-grained indications) to transports. This could
utilise new thresholds and algorithms for ECN-marking. ECN therefore
provides a mechanism that can benefit evolution of transport
protocols.</t>
<section title="Benefits from other forms of ECN-Marking/Reactions">
<t>ECN requires a definition of both how network devices CE-mark
packets and how applications/transports react to reception of these
CE-marked packets. ECN-capable receiving endpoints therefore need to
provide feedback indicating that CE-marks were received.<xref
target="RFC3168"> </xref>provides a method that signals once each
round trip time that CE-marked packets have been received. An
endpoint may provide more detailed feedback describing the set of
received ECN codepoints using Accurate ECN Feedback <xref
target="ID.Acc.ECN"></xref>. This can provide more information to a
congestion control mechanism at the sending endpoint.</t>
<t>Loss and CE-marking are both used as an indication for
congestion. However, while the amount of feedback that is provided
by loss ought naturally to be minimized, this is not the case for
ECN. With ECN, a network device could provide richer and more
frequent feedback on its congestion state. This could be used by the
control mechanisms in the transport to make a more appropriate
decision on how to react to congestion, allowing it to react faster
to changes in congestion state.</t>
<t>Precise feedback about the number of packet marks encountered is
supported by the Real Time Protocol (RTP) when used over UDP <xref
target="RFC6679"></xref> and proposed for SCTP <xref
target="ST14"></xref> and TCP <xref target="ID.Acc.ECN"></xref>.</t>
<t>Benefit has been noted when packets are CE-marked earlier using
an instantaneous queue, and if the receiver provides feedback about
the number of packet marks encountered, an improved sender behavior
has been shown to be possible (e.g, Datacenter TCP (DCTCP) <xref
target="AL10"></xref>). DCTCP is targeted at confined environments
such as a datacenter. It is currently unknown whether or how such
behaviour could be safely introduced into the Internet.</t>
</section>
</section>
</section>
<section title="Network Support for ECN">
<t>For an application to use ECN requires that the endpoint first
enables ECN within the transport.</t>
<t>The ability to use ECN requires network devices along the path to at
least forward IP packets with any ECN codepoint (i.e., packets with
ECT(0), ECT(1), or with a CE-mark), see also <xref target="Bleaching">
</xref>.</t>
<t>For an application to gain benefit from using a transport that
enables ECN, network devices need to enable ECN. However, not all
network devices along the path need to enable ECN. Any network device
that does not CE-mark an ECN-enabled packet can be expected to drop
packets under congestion. Applications that experience congestion in
these network devices do not see any benefit from using ECN, but would
see benefit if the congestion were to occur within a network device that
did support ECN.</t>
<t>There is opportunity to design an AQM method for ECN that differs
from one designed to drop packets (e.g., Random Early Detection uses a
smoothed queue length because it was designed for loss and a congestion
control that halves its sending rate on congestion) <xref
target="ID.RFC2309.bis"></xref>. IETF-specified AQM algorithms also need to
be designed to work with network paths that may contain multiple
bottlenecks. Transports can therefore experience dropped or CE-marked
packets from more than one network device related to the same network
flow <xref target="ID.AQM.eval"></xref>.</t>
<t>ECN can be deployed both in the general Internet and in controlled
environments:</t>
<t><list style="symbols">
<t>ECN can be incrementally deployed in the general Internet. The
IETF has provided guidance on configuration and usage in <xref
target="ID.RFC2309.bis"></xref>. A recent survey reported a growing
support for network paths to pass ECN codepoints <xref
target="TR15"></xref>.</t>
<t>ECN may also be deployed within a controlled environment, for
example within a data centre or within a well-managed private
network. In this case, the use of ECN may be tuned to the specific
use-case. An example is Datacenter TCP (DCTCP) <xref
target="AL10"></xref> <xref target="ID.DCTCP"></xref>.</t>
</list>Some mechanisms can assist in using ECN across a path that only
partially supports ECN. These are noted in <xref
target="mechanisms"></xref>. Applications and transports (such as TCP or
SCTP) can be designed to fall-back to not using ECN when they discover
they are using a path that does not allow use of ECN (e.g., a firewall
or other network device configured to drop the ECN codepoint) <xref
target="Verification"></xref>.</t>
<section title="Enabling ECN in Network Devices">
<t>All network devices need to be configured not to drop packets
solely because the ECT(0) or ECT(1) codepoints are used.</t>
<t>The ECN behaviour of a network device should be configurable <xref
target="ID.RFC2309.bis"></xref>. An AQM algorithm that supports ECN needs
to define the threshold and algorithm for ECN-marking.</t>
<t>A network device must not set the CE-mark in a packet, except to
signal incipient congestion, since this will be interpreted as
incipient congestion by the transport endpoints.</t>
</section>
<section title="Tunneling ECN and the use of ECN by Lower Layer Networks">
<t>Some networks may use ECN internally or tunnel ECN (e.g., for
traffic engineering or security). Guidance on the correct use of ECN
in this case is provided in <xref target="RFC6040"></xref>.</t>
<t>Further guidance on the encapsulation and use of ECN by non-IP
network devices is provided in <xref
target="ID.ECN-Encap"></xref>.</t>
</section>
<section anchor="Bleaching"
title="Bleaching and Middlebox Requirements to deploy ECN">
<t>Cases have been noted where a sending endpoint marks a packet with
a non-zero ECN mark, but the packet is received with a zero ECN
codepoint by the remote endpoint <xref target="TR15"></xref>. This
could be a result of a policy that erases or "bleaches" the ECN
codepoint values at a network edge (resetting the codepoint to
zero).</t>
<t>Bleaching may occur for various reasons (including normalising
packets to hide which equipment supports ECN). The current IPv4 and
IPv6 specifications assign usage of 2 bits in the IP header to carry
the ECN codepoint. This 2-bit field was reserved in <xref
target="RFC2474"></xref> and assigned in <xref
target="RFC3168"></xref>. A previous usage assigned these bits as a
part of the now deprecated Type of Service (ToS) field <xref
target="RFC1349"></xref>. A network device that conforms to this older
specification may remark or erase the ECN codepoints, and such
equipment needs to be updated to the current specifications to support
ECN.</t>
<t>This policy prevents use of ECN by applications. A network device
should therefore not remark an ECT(0) or ECT(1) mark to zero. This can
result in IP packets that were originally marked as ECN-capable being
dropped by ECN-capable network devices further along the path, and
eliminates the advantage of using of ECN.</t>
<t>A network device must not change a packet with a CE mark to a zero
codepoint (if the CE marking is not propagated, a CE-marked packet
must be discarded) <xref target="ID.RFC2309.bis"></xref>. A CE-marked
packet should be expected to have already received ECN treatment in
the network, and remarking it would then hide the congestion signal
from the receiving endpoint. This eliminates the benefits of ECN. It
can also slow down the response to congestion compared to using AQM,
because the transport will only react if it later discovers congestion
by some other mechanism. (Note that ECN-enabled network devices need
to drop excessive traffic <xref target="ID.RFC2309.bis"></xref>, even
when this is marked as ECN-capable.)</t>
</section>
<section title="Impact on non-ECN flows">
<t>A simple AQM scheme could place ECN-capable and non-ECN capable
flows withing the same queue. Since an ECN AQM scheme would normally
CE-mark packets during incipient congestion, these packets would not
be removed from a queue, in contrast to discarding the IP packet in a
drop-based AQM scheme. Design of an appropriate queue management
system needs to therefore consider when packets are dropped due to
incipient congestion, and seek to provide appropriate fairness between
ECN and non-ECN traffic, e.g. using more advanced AQM methods or
including flow isolation using scheduling <xref
target="ID.RFC2309.bis"></xref>.</t>
</section>
</section>
<section anchor="mechanisms" title="Using ECN across the Internet">
<t>This section describes partial deployment of ECN.</t>
<t>Early use of ECN by transports/applications encountered a number of
operational difficulties when the network path either failed to transfer
ECN-capable packets or the remote endpoint did not fully support use of
ECN. The remainder of the section describes transport mechanisms that
allow ECN-enabled endpoints to continue to work effectively over a path
with misbehaving network devices or to detect and react to
non-conformant paths.</t>
<section title="Partial Deployment">
<t>ECN has been designed to allow incremental partial deployment <xref
target="RFC3168"></xref>. Any network device may choose to use either
ECN or some other loss-based policy to manage its traffic. Similarly,
negotiation allows senders and receivers at the transport layer to
choose whether ECN is to be used to manage congestion for a particular
network flow.</t>
<t>Usability problems were reported in early deployment of ECN and
have been observed to diminish with time, but may still be encountered
on some Internet paths <xref target="TR15"></xref>.</t>
</section>
<section anchor="Verification"
title="Verifying whether a Path Really Supports ECN">
<t>ECN transport and applications need to implement mechanisms to
verify ECN support on the entire path that they use (including the
remote endpoint) and fall back to not using ECN when it would not
work. This is expected to be a normal feature of IETF-defined
transports supporting ECN.</t>
<t>Before a transport relies on the presence or absence of CE-marked
packets, it may need to verify that any ECN marks applied to packets
passed by the path are indeed delivered to the remote endpoint. This
could be achieved by the sender setting known ECN codepoints into
specific packets in a network flow and then verifying that these reach
the remote endpoint <xref target="ID.Fallback"></xref>, <xref
target="TR15"></xref>.</t>
<t>The design of any transport/application also needs to be robust to
path changes. A change in the set of network devices along a path
could impact the ability to effectively signal or use ECN across the
path, e.g., when a path changes to use a middlebox that bleaches ECN
codepoints. As a necessary, but short term fix, transports could
implement mechanisms that detect this and fall-back to disabling use
of ECN <xref target="BA11"></xref>.</t>
</section>
<section anchor="Cheating"
title="Detecting ECN Receiver Feedback Cheating">
<t>It is important that receiving endpoints accurately report the loss
they experience when using a transport that uses loss-based congestion
control. So also, when using ECN, a receiver must correctly report the
congestion marking that it receives by providing a mechanism to feed
this congestion information back to the sending endpoint.</t>
<t>The transport at endpoint receivers must not try to conceal
reception of CE-marked packets in the ECN feedback information that
they provide to the sending endpoint <xref
target="ID.RFC2309.bis"></xref>. Transport protocols are actively
encouraged to include mechanisms that can detect and appropriately
respond to such misbehavior (e.g., disabling use of ECN, and relying
on loss-based congestion detection <xref target="TR15"></xref>).</t>
</section>
</section>
<section title="Summary: Enabling ECN in Network Devices and Hosts">
<t>This section provides a list of key requirements to achieve ECN
deployment. It also summarises the benefits of deploying and using ECN
within the Internet.</t>
<t>Network devices should enable ECN and people configuring host stacks
should also enable ECN <xref target="ID.RFC2309.bis"></xref>.</t>
<t>Prerequisites for network devices (including IP routers) to enable
use of ECN include:<list style="symbols">
<t>must not change a packet with a CE mark to a zero codepoint (if
the CE marking is not propagated, the packet must be discarded).</t>
<t>should not reset the ECN codepoint to zero by default (see <xref
target="Bleaching"></xref>).</t>
<t>should correctly update the ECN codepoint in the presence of
congestion <xref target="ID.RFC2309.bis"></xref>.</t>
<t>may support alternate ECN semantics <xref
target="RFC4774"></xref>.</t>
</list></t>
<t>Prerequisites for network endpoints to enable use of ECN include:</t>
<t><list style="symbols">
<t>should use transports that can set and receive ECN marks.</t>
<t>when ECN is used, must correctly return feedback indicating
congestion to the sending endpoint.</t>
<t>when ECN is used, must use transports that react appropriately to
received ECN feedback (see <xref target="Cheating"></xref>).</t>
<t>when ECN is used, should use transports that can detect misuse of
ECN and detect paths that bleach ECN, providing fallback to
loss-based congestion detection when ECN is not supported (see <xref
target="Verification"></xref>).</t>
</list>Application developers should where possible use transports
that enable the benefits of ECN. Applications that directly use UDP need
to provide support to implement the functions required for ECN <xref
target="ID.RFC5405.bis"></xref>. Once enabled, an application that uses
a transport that supports ECN will experience the benefits of ECN as
network deployment starts to enable ECN. The application does not need
to be rewritten to gain these benefits. Table 1 summarises some of these
benefits.</t>
<figure>
<artwork><![CDATA[+---------+-----------------------------------------------------+
| Section | Benefit |
+---------+-----------------------------------------------------+
| 2.1 | Improved throughput |
| 2.2 | Reduced Head-of-Line blocking |
| 2.3 | Reduced probability of RTO Expiry |
| 2.4 | Applications that do not retransmit lost packets |
| 2.5 | Making incipient congestion visible |
| 2.6 | Opportunities for new transport mechanisms |
+---------+-----------------------------------------------------+
Table 1: Summary of Key Benefits
]]></artwork>
</figure>
<t></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors were part-funded by the European Community under its
Seventh Framework Programme through the Reducing Internet Transport
Latency (RITE) project (ICT-317700). The views expressed are solely
those of the authors.</t>
<t>The authors would like to thank the following people for their
comments on prior versions of this document: Bob Briscoe, David
Collier-Brown, John Leslie, Colin Perkins, Richard Scheffenegger, Dave
Taht, Wes Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John
Leslie, and other members of the TSVWG.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>XX RFC ED - PLEASE REMOVE THIS SECTION XXX</t>
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document introduces no new security considerations. Each RFC
listed in this document discusses the security considerations of the
specification it contains.</t>
</section>
<section title="Revision Information">
<t>XXX RFC-Ed please remove this section prior to publication.</t>
<t>Revision 00 was the first WG draft.</t>
<t>Revision 01 includes updates to complete all the sections and a
rewrite to improve readability. Added section 2. Author list reversed,
since Gorry has become the lead author. Corrections following feedback
from Wes Eddy upon review of an interim version of this draft.</t>
<t>Note: Wes Eddy raised a question about whether discussion of the ECN
Pitfalls could be improved or restructured - this is expected to be
addressed in the next revision.</t>
<t>Revision 02 updates the title, and also the description of mechanisms
that help with partial ECN support.</t>
<t>We think this draft is ready for wider review. Comments are welcome
to the authors or via the IETF AQM or TSVWG mailing lists.</t>
<t>Revision 03 includes updates from the mailing list and WG discussions
at the Dallas IETF meeting.</t>
<t>The section "Avoiding Capacity Overshoot" was removed, since this
refers primarily to an AQM benefit, and the additional benefits of ECN
are already stated. Separated normative and infoirmative references</t>
<t>Revision 4 (WG Review during WGLC)</t>
<t>Updated the abstract.</t>
<t>Added a table of contents.</t>
<t>Addressed various (some conflicting) comments during WGLC with new
text.</t>
<t>The section on Network Support for ECN was moved, and some
suggestions for rewording sections were implemented.</t>
<t>Decided not to remove section headers for 2.1 and 2.2 - to ensure the
document clearly calls-out the benefits.</t>
<t>Updated references. Updated text to improve consistency of terms and
added deifinitions for key terms.</t>
<t>Note: The group suggested this document should not define
recommendations for end hosts or routers, but simply state the things
needs to enable deployment to be sucessful.</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;
<reference anchor="ID.RFC2309.bis" target="">
<front>
<title>IETF Recommendations Regarding Active Queue
Management</title>
<author fullname="F. Baker" initials="F." surname="Baker"></author>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"></author>
<date month="October" year="2014" />
</front>
<seriesInfo name="Internet-draft"
value="draft-ietf-aqm-recommendation-06" />
</reference>
<reference anchor="RFC2474">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="ID.RFC5405.bis">
<front>
<title>Unicast UDP Usage Guidelines</title>
<author fullname="Lars Eggert" initials="Lars" surname="Eggert">
<organization></organization>
</author>
<author fullname="Gorry Fairhurst" initials="Gorry"
surname="Fairhurst">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Greg Shepherd" initials="Greg" surname="Shepherd">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date year="2015" />
</front>
</reference>
&RFC6040;
</references>
<references title="Informative References">
<reference anchor="RFC0768">
<front>
<title>User Datagram Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization></organization>
</author>
<date year="1980" />
</front>
</reference>
<reference anchor="RFC1349">
<front>
<title>Type of Service in the Internet Protocol Suite</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
&RFC3649;
&RFC3758;
&RFC4340;
&RFC4774;
&RFC5562;
&RFC5681;
&RFC6679;
&RFC6789;
<reference anchor="ID.Acc.ECN">
<front>
<title>More Accurate ECN Feedback in TCP, Work-in-Progress</title>
<author fullname="Bob Briscoe" initials="Bob" surname="Briscoe">
<organization></organization>
</author>
<author fullname="Richard Scheffeneger" initials="Richard"
surname="Scheffeneger">
<organization></organization>
</author>
<author fullname="Mirja Kuehlewind" initials="Mirja"
surname="Kuehlewind">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="ID.DCTCP">
<front>
<title>Microsoft's Datacenter TCP (DCTCP): TCP Congestion Control
for Datacenters (Work-in-progress, draft-bensley-tcpm-dctcp)</title>
<author fullname="S. Bensley" initials="S" surname="Bensley">
<organization></organization>
</author>
<author fullname="Lars Eggert" initials="Lars" surname="Eggert">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="D. Thaler" initials="D" surname="Thaler">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date year="2015" />
</front>
</reference>
<reference anchor="ID.AQM.eval">
<front>
<title>AQM Characterization Guidelines (Work-in-progress,
draft-ietf-aqm-eval-guidelines)</title>
<author fullname="Nicolas Kuhn" initials="Nicolas" surname="Kuhn">
<organization></organization>
</author>
<author fullname="Preethi Natarajan" initials="Preethi"
surname="Natarajan">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="David Ros" initials="David" surname="Ros">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Naeem Khademi" initials="Naeem" surname="Khademi">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date year="2015" />
</front>
</reference>
<reference anchor="ID.Fallback">
<front>
<title>A Mechanism for ECN Path Probing and Fallback,
draft-kuehlewind-tcpm-ecn-fallback, Work-in-Progress</title>
<author fullname="Mirja Kuehlewind" initials="Mirja"
surname="Kuehlewind">
<organization></organization>
</author>
<author fullname="Brian Trammell" initials="Brian"
surname="Trammell">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date />
</front>
</reference>
<reference anchor="ID.ECN-Encap">
<front>
<title>Guidelines for Adding Congestion Notification to Protocols
that Encapsulate IP</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization></organization>
</author>
<author fullname="J Kaippallimalil" initials="J"
surname="Kaippallimalil">
<organization></organization>
</author>
<author fullname="Pat Thaler" initials="P" surname="Thaler">
<organization>PT</organization>
</author>
<date />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-tsvwg-ecn-encap-guidelines" />
</reference>
<reference anchor="BA11">
<front>
<title>Measuring the State of ECN Readiness in Servers, Clients, and
Routers, ACM IMC</title>
<author fullname="Steven Bauer" initials="Steven" surname="Bauer">
<organization></organization>
</author>
<author fullname="Robert Beverly" initials="Robert"
surname="Beverly">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Arthur Berger" initials="Arthur" surname="Berger">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="AL10" target="">
<front>
<title>Data Center TCP (DCTCP)</title>
<author fullname="M. Alizadeh" initials="M." surname="Alizadeh"></author>
<author fullname="A. Greenberg" initials="A." surname="Greenberg"></author>
<author fullname="D. A. Maltz" initials="D. A." surname="Maltz"></author>
<author fullname="J. Padhye" initials="J." surname="Padhye"></author>
<author fullname="P. Patel" initials="P." surname="Patel"></author>
<author fullname="B. Prabhakar" initials="B." surname="Prabhakar"></author>
<author fullname="S. Sengupta" initials="S." surname="Sengupta"></author>
<author fullname="M. Sridharan" initials="M." surname="Sridharan"></author>
<date month="August" year="2010" />
</front>
<seriesInfo name="SIGCOMM" value="2010" />
</reference>
<!-- <reference anchor="KH13" target="">
<front>
<title>The New AQM Kids on the Block: Much Ado About
Nothing?</title>
<author fullname="N. Perkins" initials="N." surname="Khademi"></author>
<author fullname="D. Ros" initials="D." surname="Ros"></author>
<author fullname="M. Welzl" initials="M." surname="Welzl"></author>
<date month="October" year="2013" />
</front>
<seriesInfo name="University of Oslo Department of Informatics technical report"
value="434" />
</reference>
-->
<reference anchor="Fla13" target="">
<front>
<title>Reducing web latency: the virtue of gentle
aggression.</title>
<author fullname="Tobias Flach" initials="Tobias" surname="Flach"></author>
<author fullname="Nandita Dukkipati" initials="Nandita"
surname="Dukkipati"></author>
<author fullname="Andreas Terzis" initials="Andreas"
surname="Terzis"></author>
<author fullname="Barath Raghavan" initials="Barath"
surname="Raghavan"></author>
<author fullname="Neal Cardwell" initials="Neal" surname="Cardwell"></author>
<author fullname="Yuchung Cheng" initials="Yuchung" surname="Cheng"></author>
<author fullname="Ankur Jain" initials="Ankur" surname="Jain"></author>
<author fullname="Shuai Hao" initials="Shuai" surname="Hao"></author>
<author fullname="Ethan Katz-Bassett" initials="Ethan"
surname="Katz-Bassett">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Ramesh Govindan" initials="Ramesh"
surname="Govindan">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="October" year="2013" />
</front>
<seriesInfo name="SIGCOMM" value="2013" />
</reference>
<reference anchor="ST14" target="">
<front>
<title>ECN for Stream Control Transmission Protocol (SCTP)</title>
<author fullname="R. Stewart" initials="R." surname="Stewart"></author>
<author fullname="M. Tuexen" initials="M." surname="Tuexen"></author>
<author fullname="X. Dong" initials="X." surname="Dong"></author>
<date month="January" year="2014" />
</front>
<seriesInfo name="Internet-draft"
value="draft-stewart-tsvwg-sctpecn-05.txt" />
</reference>
<reference anchor="TR15">
<front>
<title>Enabling internet-wide deployment of Explicit Congestion
Notification Tramwell, B., Kuehlewind, M., Boppart, D., Learmonth,
I., Fairhurst, G. & Scheffnegger, Passive and Active Measurement
Conference (PAM)</title>
<author fullname="B. Trammel" initials="Brian" surname="Tranmmel">
<organization>Tr</organization>
</author>
<author fullname="M. Kuehlewind" initials="Mirja"
surname="Kuehlewind">
<organization></organization>
</author>
<author fullname="D. Boppart" initials=" Damiano" surname="Boppart">
<organization></organization>
</author>
<author fullname="I. Learmonth" initials="Iain" surname="Learmonth">
<organization></organization>
</author>
<author fullname="G. Fairhurst" initials="Gorry"
surname=" Fairhurst">
<organization></organization>
</author>
<date day="19" month="March" year="2015" />
</front>
</reference>
<!-- <reference anchor="rtcweb-usecases" target="">
<front>
<title>Web Real-Time Communication Use-cases and Requirements</title>
<author initials="C." surname="Holmberg" fullname="C. Holmberg"></author>
<author initials="S." surname="Hakansson" fullname="S. Hakansson"></author>
<author initials="G." surname="Eriksson" fullname="G. Eriksson"></author>
<date month="December" year="2012"/>
</front>
<seriesInfo name="Internet-draft" value="draft-ietf-rtcweb-use-cases-and-requirements-10.txt"/>
</reference>
<reference anchor="transport-multiplex" target="">
<front>
<title>Multiple RTP Sessions on a Single Lower-Layer Transport</title>
<author initials="M." surname="Westerlund" fullname="M. Westerlund"></author>
<author initials="C." surname="Perkins" fullname="C. Perkins"></author>
<date month="October" year="2012"/>
</front>
<seriesInfo name="Internet-draft" value="draft-westerlund-avtcore-transport-multiplexing-04.txt"/>
</reference>
<reference anchor="rtcweb-rtp-usage" target="">
<front>
<title>Web Real-Time Communication (WebRTC): Media Transport and Use of RTP</title>
<author initials="C." surname="Perkins" fullname="C. Perkins"></author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund"></author>
<author initials="J." surname="Ott" fullname="J. Ott"></author>
<date month="October" year="2012"/>
</front>
<seriesInfo name="Internet-draft" value="draft-ietf-rtcweb-rtp-usage-05.txt"/>
</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 23:26:00 |