One document matched: draft-ietf-aqm-ecn-benefits-02.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="no"?>
<!-- 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-02"
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.W." 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="22" month="March" year="2015" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup></workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>ecn, aqm, sctp, tcp</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes the potential benefits when applications
enable Explicit Congestion Notification (ECN). It 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 identifies some potential problems that might occur
when ECN is used. The document does not propose new algorithms that may
be able to use ECN or describe the details of implementation of ECN in
endpoint devices, routers and 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) have two ways to detect
congestion: the loss of a packet and, if Explicit Congestion
Notification (ECN) <xref target="RFC3168"></xref> is enabled, by
reception of a packet with a Congestion Experienced (CE)-marking in the
IP header. Both of these are treated by transports as indications of
(potential) congestion. ECN may also be enabled by other transports: UDP
applications may enable ECN when they are able to correctly process the
ECN signals (e.g. ECN with RTP <xref target="RFC6679"></xref>).</t>
<t>A network device (router, middlebox, or other device that forwards
packets through the network) that does not support AQM, typically uses a
drop-tail policy to discard 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 triggers a congestion control reaction to reduce the maximum rate
permitted by the sending endpoint.</t>
<t>When an application uses a transport that enables the use of ECN, 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, packets in periods of congestion. This marking
is generally performed by Active Queue Management (AQM) <xref
target="RFC2309.bis"></xref> and may be the result of various AQM
algorithms, where the exact combination of AQM/ECN algorithms does not
need to be known by the transport endpoints. The focus of this document
is on usage of ECN by transport and application layer flows, not its
implementation in hosts, routers and other network devices.</t>
<t>ECN makes it possible for the network to signal the presence of
congestion without incurring packet loss. This 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 of these benefits have to do with reducing latency in
some way (e.g., reduced Head-of-Line Blocking and potentially smaller
queuing delay, depending on the marking rules in network devices).</t>
<t>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 router 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,
separate configuration of the drop and mark thresholds is known to be
supported in some network devices and this is recommended <xref
target="RFC2309.bis"></xref>. Some benefits of ECN that are discussed
rely upon network devices marking packets at a lower level of
congestion, before they would otherwise drop packets from queue overflow
<xref target="KH13"></xref>.</t>
<t>The ability to use ECN relies upon using a transport that can support
ECN. Some benefits are also only realised when the transport endpoint
behaviour is also updated, this is discussed further in <xref
target="sec-experimental"></xref>.</t>
</section>
<section title="ECN Deployment">
<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 pass IP packets that set ECN codepoints, and do not drop packets
because these codepoints are used <xref target="Bleaching"></xref>. This
is the recommended behaviour for network devices <xref
target="RFC2309.bis"> </xref> <xref target="RFC3168"></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>
<t>For an application to gain benefit from using a transport that
enables ECN, network devices need to enable ECN marking. However, not
all network devices along the path need to enable ECN, for the
application to benefit. Any network device that does not mark an
ECN-enabled packet with a CE-codepoint 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>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="RFC2309.bis"></xref>. A recent survey reported growing
support for ECN on common network paths <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>.</t>
</list></t>
<t>Some mechanisms that can assist in using ECN across paths that only
partially supports ECN are noted in <xref
target="mechanisms"></xref>.</t>
<section title="Enabling ECN in network devices">
<t>Network deployment needs also to consider the requirements for
processing ECN at tunnel endpoints of network tunnels, and guidance on
the treatment of ECN is provided in <xref target="RFC6040"></xref>.
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 value
by the remote endpoint.</t>
<t>The current IPv4 and IPv6 specifications assign usage of 2 bits in
the IP header to carry the ECN codepoint<xref target="RFC2474"></xref>
<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>. Network devices that conform to this older
specification may still remark or erase the ECN codepoints, and such
equipment needs to be updated to the current specifications to support
ECN . This remarking has also been called "ECN bleaching".</t>
<t>Some network devices have been observed to implement a policy that
erases or "bleaches" the ECN marks at a network edge (resetting these
to zero). This may be implemented for various reasons (including
normalising packets to hide which equipment supports ECN). This policy
prevents use of ECN by applications. A network device should therefore
not remark an ECT(0) or ECT(1) mark to zero.</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, the packet must be
discarded). Such a packet has already received ECN treatment in the
network, and remarking it would then hide the congestion signal from
the endpoints.</t>
<t>Some networks may use ECN internally or tunnel ECN for traffic
engineering or security. Guidance on the correct use of ECN in this
case is provided in <xref target="RFC6040"></xref>.</t>
</section>
</section>
<section title="Benefit of using ECN to avoid congestion loss">
<t>When packet loss is a result of (mild) congestion, an ECN-enabled
router may be expected to CE-mark, rather than drop an ECN-enabled
packet <xref target="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 performance of applications,
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. 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>
</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. This requires that the transport
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.
This is the usual requirement for TCP and SCTP. PR-SCTP <xref
target="RFC3758"></xref>, UDP, and DCCP <xref target="RFC4340"></xref>
provide a transport that does not have this requirement.</t>
<t>Delaying data to provide in-order transmission to an application
results in additional latency when segments are dropped as indications
of congestion. The congestive loss creates a delay of at least one RTT
for a loss event before data can be delivered to an application. We
call this Head-of-Line (HOL) blocking.</t>
<t>In contrast, using ECN can remove the resulting delay following a
loss that is a result of congestion:</t>
<t><list style="symbols">
<t>First, the application receives the data normally. This also
avoids the inefficiency of dropping data that has already made it
across at least part of the network path. It also avoids the
additional delay of waiting for recovery of the lost segment.</t>
<t>Second, the transport receiver notes that it has received
CE-marked packets, and then requests the sender to make an
appropriate congestion-response to reduce the maximum transmission
rate for future traffic.</t>
</list></t>
</section>
<section title="Reduced Probability of RTO Expiry">
<t>In some situations, ECN can help reduce the chance of a
retransmission timer expiring (e.g., expiry of the TCP or SCTP
retransmission timeout, RTO <xref target="RFC5681"></xref>. When an
application sends 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), the last segment of the burst may be lost. It is
often not possible to recover this last segment (or last few segments)
using standard methods such as Fast Recovery <xref
target="RFC5681"></xref>, since the receiver generates no feedback
because it is unaware that the lost segments were actually sent.</t>
<t>In addition to avoiding HOL blocking, this allows the transport to
avoid the consequent loss of state about the network path it is using,
which would have arisen had there been a retransmission timeout.
Typical impacts of a transport timeout are to reset path estimates
such as the RTT, the congestion window, and possibly other transport
state that can reduce the performance of the transport until it again
adapts to the path.</t>
<t>Avoiding timeouts can hence improve the throughput of the
application. This benefits applications that send intermittent bursts
of data, and rely upon timer-based recovery of packet loss. It can 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 they may be able to adjust the sending rate in the presence of
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 loss-hiding
mechanisms (e.g., packet forward error correction, or data
duplication) to mitigate the effect of congestion loss on the
application. However, such mechanisms add complexity and can
themselves consume additional network capacity reducing the 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, especially when the
congestion is mild and the application/transport can react promptly to
reception of a CE-marked packet. 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>
<section anchor="sec-early"
title="Benefit from Early Congestion Detection">
<t>An application can further benefit from using ECN, when the network
devices are configured such that they mark packets at a lower level of
congestion before they would otherwise have dropped packets from queue
overflow:</t>
<section anchor="sec-ss" title="Avoiding Capacity Overshoot ">
<t>Internet transports do not know apriori how much capacity exists
along a network path. Transports therefore try to measure the capacity
available to an application by probing the network path with
increasing traffic to the point where they detect the onset of
congestion (such as TCP or SCTP Slow Start).</t>
<t>ECN can help capacity probing algorithms (such as Slow Start) from
significantly exceeding the bottleneck capacity of a network path.
Since a transport that enables ECN can receive congestion signals
before there is significant congestion, an early-marking method in
network devices can help a transport respond before it induces
significant congestion with resultant loss to itself or other
applications sharing a common bottleneck. For example, an
application/transport can avoid incurring significant congestion
during Slow Start, or a bulk application that tries to increase its
rate as fast as possible, may quickly detect the presence of
congestion, causing it to promptly reduce its rate.</t>
<t>Use of ECN is more effective than schemes such as Limited
Slow-Start <xref target="RFC3742"></xref> because it provides direct
information about the state of the network path. An ECN-enabled
application/transport that probes for capacity can reduce its rate as
soon as it discovers CE-marked packets are received, and before the
applications increases its rate to the point where it builds a queue
in a network device that induces congestion loss. This benefits an
application seeking to increase its rate - but perhaps more
significantly, it eliminates the often unwanted loss and queueing
delay that otherwise may be inflicted on flows that share a common
bottleneck.</t>
</section>
<section anchor="sec-visibility" title="Making 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 performance of the path, and
could be used to directly meter the amount of congestion that has been
encountered upstream on a path; 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-marks 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-marks and loss when there is only congestion or when
there is a combination of packet loss and congestion <xref
target="RFC2309.bis"></xref>. Recording the presence of CE-marked
packets can therefore provide information about the performance of the
network path.</t>
</section>
</section>
<section anchor="sec-experimental"
title="Other forms of ECN-Marking/Reactions">
<t>ECN requires a definition of both how packets are CE-marked and how
applications/transports need to react to reception of CE-marked packets.
This section describes the benefits when updated methods are used.</t>
<t>ECN-capable receiving endpoints may provide more detailed feedback
describing the ECN codepoints that they observe using <xref
target="ID.Acc-ECN"></xref>. This can provide more information to a
sending endpoint's congestion control mechanism.</t>
<t>Benefit has been noted when packets are CE-marked earlier than they
would otherwise be dropped, using an instantaneous queue, and if the
receiver provides precise feedback about the number of packet marks
encountered, a better sender behavior is possible. This has been shown
by Datacenter TCP (DCTCP) <xref target="AL10"></xref>.</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>. An
underlying assumption of DCTCP is that it is deployed in 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 anchor="mechanisms"
title="ECN transport mechanisms for paths with partial ECN support">
<t>Early deployment of ECN encountered a number of operational
difficulties when the network only partially supports the use of ECN, or
to respond to the challenges due to misbehaving network devices and/or
endpoints. These problems have been observed to diminish with time, but
may still be encountered on some Internet paths <xref
target="TR15"></xref>.</t>
<t>This section describes transport mechanisms that allow ECN-enabled
endpoints to continue to work effectively over a path with partial ECN
support.</t>
<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 path that they use and fallback 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
may 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>Endpoints also need to be robust to path changes. A change in the
set of network devices along a path may 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 and then provide a mechanism to
feed the 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="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="Conclusion">
<t>Network devices should enable ECN and people configuring host stacks
should also enable ECN. Specifically network devices 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). These are prerequisites to
allow applications to gain the benefits of ECN.</t>
<t>Prerequisites for network devices (including IP routers) to enable
use of ECN include:<list style="symbols">
<t>should not reset the ECN codepoint to zero by default <xref
target="Bleaching"></xref>.</t>
<t>should correctly update the ECN codepoint in the presence of
congestion.</t>
<t>should correctly 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>should correctly return feedback of congestion to the sending
endpoint.</t>
<t>must use transports that react appropriately to received ECN
feedback <xref target="Cheating"></xref>.</t>
<t>should use transports that can detect misuse of ECN and detect
paths that do not support ECN, providing fallback to loss-based
congestion detection when ECN is not supported <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. 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 |
+---------+-----------------------------------------------------+
| 3.1 | Improved Throughput |
| 3.2 | Reduced Head-of-Line |
| 3.3 | Reduced Probability of RTO Expiry |
| 3.4 | Applications that do not retransmit lost packets |
| 4.1 | Avoiding Capacity Overshoot |
| 4.2 | Making Congestion Visible |
+---------+-----------------------------------------------------+
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.</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 restrcutured - 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>
</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="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>
</references>
<references title="Informative References">
<reference anchor="RFC1349">
<front>
<title>Type of Service in the Internet Protocol Suite</title>
<author>
<organization></organization>
</author>
<date />
</front>
</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>
&RFC3649;
&RFC3742;
&RFC3758;
&RFC4340;
&RFC4774;
&RFC5562;
&RFC5681;
&RFC6040;
&RFC6679;
&RFC6789;
<reference anchor="ID.Acc-ECN">
<front>
<title>Problem Statement and Requirements for a More Accurate ECN
Feedback</title>
<author fullname="M. Kuehlewind" initials="Mirja"
surname="Kuehlewind">
<organization></organization>
</author>
<author fullname="R. Scheffenegger" initials="Richard"
surname="Scheffenegger">
<organization></organization>
</author>
<author fullname="B. Briscoe" initials="Bob" surname="Briscoe">
<organization></organization>
</author>
<date year="2015" />
</front>
<seriesInfo name="Internet-draft, IETF work-in-progress"
value="draft-ietf-tcpm-accecn-reqs" />
</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="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="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="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:33:15 |