One document matched: draft-ietf-aqm-ecn-benefits-05.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-05"
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="23" month="June" 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 a network path that includes equipment that supports
ECN-marking. It also discusses challenges for 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 are designed to detect and react to
network congestion. Congestion may be detected by loss of an IP packet
or, if Explicit Congestion Notification (ECN) <xref
target="RFC3168"></xref> is enabled, by 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. An ECN-capable network device can then signal incipient
congestion (network queueing) at a point before a transport experiences
congestion loss or high 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). </t>
<t>The focus of the 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>AQM: Active Queue Management.</t>
<t>CE: Congestion Experienced, a codepoint value marked in the IP
packet header.</t>
<t>ECN-capable: An IP packet with a non-zero ECN value (i.e., with a
ECT(0), ECT(1), or the CE codepoint). An ECN-capable network device
may forward, drop or queue an ECN-capable packet and may choose to
CE-mark this packet when there is incipient congestion.</t>
<t>ECN field: A 2-bit field specified for use explicit congestion
signalling in the IPv4 and IPv6 packet headers.</t>
<t>Endpoint: An Internet host that terminates a transport protocol
connection across an Internet path.</t>
<t>Incipient Congestion: The detection of congestion when it is
starting, perhaps by a network device noting that the arrival rate
exceeds the forwarding rate.</t>
<t>Network device: A router, middlebox, or other device that forwards
IP packets through the network.</t>
<t>non-ECN-capable: An IP packet with a zero value ECN codepoint. A
non-ECN-capable packet may be forwarded, dropped or queued by a
network device.</t>
</section>
</section>
<section title="Benefit of using ECN to avoid Congestion Loss">
<t>An ECN-capable network device is expected to CE-mark an ECN-capable
IP packet when an AQM method detects incipient congestion, rather than
to drop the 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 seeks to avoid the inefficiency of dropping data that has
already made it across at least part of the network path.</t>
<t>ECN can improve the throughput of an application, although this
increase in throughput is often not the most significant gain. 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 would be 0.02 (i.e., 1 in 50 packets). This translates into
an approximate 2% throughput gain if ECN is enabled. (Note that 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 Internet transports provide in-order delivery of received data
segments to the applications they support. For these applications, use
of ECN can reduce the delay that can result when these applications
experience packet loss.</t>
<t>Packet loss may occur for various reasons. One cause arises when an
AQM scheme drops a packet as a signal of incipient congestion.
Whatever the cause of loss, a missing packet needs to trigger a
congestion control response. A reliable transport also triggers
retransmission to recover the lost data. 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 lost segment to be
correctly received before it can forward any later data to the
application. A 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. 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
provide re-ordering).</t>
<t>By enabling ECN, a transport continues to receive in-order data
when there is incipient congestion, and can pass this data to the
receiving application. Use of ECN avoids the additional reordering
delay in a reliable transport. The sender still needs to make an
appropriate congestion-response to reduce the maximum transmission
rate for future traffic, which usually will require a reduction in the
sending rate <xref target="ID.RFC5405.bis"></xref>.)</t>
</section>
<section title="Reduced Probability of RTO Expiry">
<t>Some patterns of packet loss can result in a retransmission time
out (RTO), which causes a sudden and significant change in the allowed
rate at which a transport/application can forward packets. Because ECN
provides an alternative to drop for network devices to signal
incipient congestion, this can reduce the probability of loss and
hence reduce the likelihood of RTO expiry.</t>
<t>Internet transports/applications generally use a RTO timer as a
last resort to detect and recover loss <xref
target="ID.RFC5405.bis"></xref> <xref target="RFC5681"></xref>).
Specifically, a RTO timer detects loss of a packet that is not
followed by other packets, such as at the end of a burst of data
segments or when an application 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). This loss of the last segment (or last few segments)
of a traffic burst is also known as a "tail loss". Standard transport
recovery methods, such as Fast Recovery <xref
target="RFC5681">(</xref>, are often unable to recover from a tail
loss. This is because the endpoint 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. This timer is
also used to detect a lack of forwarding along a path. Expiry of the
RTO therefore 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>An ECN-capable network device cannot eliminate the possibility of
tail loss, because a drop may occur due to a traffic burst exceeding
the instantaneous available capacity of a network buffer or as a
result of the AQM algorithm (overload protection mechanisms, etc <xref
target="ID.RFC2309.bis"></xref>). However, an ECN-capable network
device that observes incipient congestion may be expected to buffer
the IP packets of an ECN-capable flow and set a CE-mark in one or more
packet(s), rather than triggering packet drop. Setting a CE-mark
signals incipient congestion without forcing the transport/application
to enter retransmission timeout. This reduces application-level
latency and can improve the throughput for applications that send
intermittent bursts of data. </t>
<t>The benefit of avoiding retransmission loss is expected to be
significant when ECN is used on TCP SYN/ACK packets <xref
target="RFC5562"></xref> where the RTO interval may be large because
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>A transport that enables ECN can receive timely congestion signals
without the need to retransmit packets each time it receives a
congestion signal.</t>
<t>Some latency-critical applications do not retransmit lost packets,
yet may be able to adjust their sending rate following detection 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 the transport/application may
therefore employ mechanisms (e.g., packet forward error correction,
data duplication, or media codec error concealment) to mitigate the
immediate effect of congestion loss on the application. Some
mechanisms consume additional network capacity, some require
additional processing and some contribute additional path latency when
congestion is experienced. By decoupling congestion control from loss,
ECN can allow transports that support these applications to reduce
their rate before the application experiences loss from congestion.
This can reduce the negative impact of triggering loss-hiding
mechanisms with 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
allowing information to be collected about the presence of incipient
congestion.</t>
<t>Recording the presence of CE-marked packets can provide information
about the current congestion level experienced on a network path. A
network flow that only experiences CE-marking and no loss implies that
the sending endpoint is experiencing only congestion. A network flow
may also experience loss (e.g., due to queue overflow, AQM methods
that protect other flows, link corruption or loss in middleboxes).
When a mixture of ECN-marking and packet loss is experienced,
transports and measurements need to assume there is congestion <xref
target="ID.RFC2309.bis"></xref>. An absence of CE-marks therefore does
not indicate a path has not experienced congestion.</t>
<t>The reception of CE-marked packets can be used to monitor the level
of congestion by a transport/application or a network operator. For
example, ECN measurements are used by Congestion Exposure (ConEx)
<xref target="RFC6789"></xref>. In contrast, metering packet loss is
harder.</t>
</section>
<section anchor="Acc-feedback"
title="Opportunities for new Transport Mechanisms">
<t>ECN can enable design and deployment of new algorithms in network
devices and Internet transports. Internet transports need to regard
both loss and CE-marking as an indication of congestion. However,
while the amount of feedback provided by drop ought naturally to be
minimized, this is not the case for ECN. In contrast, an ECN-Capable
network device could provide richer (more frequent and fine-grained)
indication of its congestion state to the transport.</t>
<t>All ECN-capable receiving endpoints need to provide feedback to the
transport sender to indicate that CE-marks have been received.<xref
target="RFC3168"> </xref> provides one method that signals once each
round trip time that CE-marked packets have been received.</t>
<t>A receiving endpoint may provide more detailed feedback to the
congestion controller at the sender (e.g., describing the set of
received ECN codepoints, or indicating each received CE-marked
packet). Precise feedback about the number of CE-marks encountered is
supported by the Real Time Protocol (RTP) when used over UDP <xref
target="RFC6679"></xref> and has been proposed for SCTP <xref
target="ST14"></xref> and TCP <xref target="ID.Acc.ECN"></xref>.</t>
<t>More detailed feedback is expected to enable evolution of transport
protocols allowing the congestion control mechanism to make a more
appropriate decision on how to react to congestion. Designers of
transport protocols need to consider not only how network devices
CE-mark packets, but also how the control loop in the
application/transport reacts to reception of these CE-marked packets.
</t>
<t>Benefit has been noted when packets are CE-marked early using an
instantaneous queue, and if the receiving endpoint 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 controlled
environments such as a datacenter. This is work-in-progress and it is
currently unknown whether or how such behaviour could be safely
introduced into the Internet. Any update to an Internet transport
protocol requires careful consideration of the robustness of the
behaviour when working with endpoints or network devices that were not
designed for the new congestion reaction.</t>
</section>
</section>
<section title="Network Support for ECN">
<t>For an application to use ECN requires that the endpoints first
enable ECN within the transport being used, but also for all network
devices along the path to at least forward IP packets that set a
non-zero ECN codepoint.</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>. </t>
<t>ECN may be deployed within a controlled environment, for example
within a data centre or within a well-managed private network. This
use of ECN may be tuned to the specific use-case. An example is
DCTCP <xref target="AL10"></xref> <xref
target="ID.DCTCP"></xref>.</t>
</list></t>
<t>Early experience of using ECN across the general Internet encountered
a number of operational difficulties when the network path either failed
to transfer ECN-capable packets or inappropriately changed the ECN
codepoints <xref target="BA11"></xref>. A recent survey reported a
growing support for network paths to pass ECN codepoints <xref
target="TR15"></xref>. </t>
<t>The remainder of this section identifies what is needed for network
devices to effectively support ECN.</t>
<section anchor="Codepoint" title="The ECN Field ">
<t>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>. </t>
<t><xref target="RFC4774"></xref> discusses some of the issues in
defining alternate semantics for the ECN field, and specifies
requirements for a safe coexistence in an Internet that could include
routers that do not understand the defined alternate semantics.</t>
</section>
<section anchor="Forwarding" title="Forwarding ECN-Capable IP Packets">
<t>Not all network devices along a path need to be ECN-capable (i.e.,
perform CE-marking). However, all network devices need to be
configured not to drop packets solely because the ECT(0) or ECT(1)
codepoints are used.</t>
<t>Any network device that does not perform CE-marking of an
ECN-capable packet can be expected to drop these packets under
congestion. Applications that experience congestion at these network
devices do not see any benefit from enabling ECN. However, they may be
expected to see benefit if the congestion were to occur within a
network device that did support ECN.</t>
</section>
<section anchor="Enabling" title="Enabling ECN in Network Devices">
<t>Network devices should use an AQM algorithm that CE-marks
ECN-capable traffic when making decisions about the response to
congestion <xref target="ID.RFC2309.bis"></xref>. An ECN method should
set a CE-mark on ECN-capable packets in the presence of incipient
congestion. A CE-marked packet will be interpreted as an indication of
incipient congestion by the transport endpoints.</t>
<t>There is opportunity to design an AQM method for an ECN-capable
network device that differs from an AQM method designed to drop
packets. <xref target="ID.RFC2309.bis"></xref> states that the network
device should allow this behaviour to be configurable.</t>
<t><xref target="RFC3168"></xref> describes a method in which a
network device sets the CE-mark 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>
</section>
<section anchor="Non-ECN" title="Co-existance of ECN and non-ECN flows">
<t>Network devices need to be able to forward all IP flows and provide
appropriate treatment for both ECN and non-ECN traffic.</t>
<t>The design considerations for an AQM scheme supporting ECN needs to
consider the impact of queueing during incipient congestion. For
example, a simple AQM scheme could choose to queue ECN-capable and
non-ECN capable flows in the same queue with an ECN scheme that
CE-mark packets during incipient congestion. The CE-marked packets
that remain in the queue during congestion can continue to contribute
to queueing delay. In contrast, non-ECN-capable packets would normally
be dropped by an AQM scheme under incipient congestion. This
difference in queueing is one motivation for consideration of more
advanced AQM schemes, and may provide an incentive for enabling flow
isolation using scheduling <xref target="ID.RFC2309.bis"></xref>. The
IETF is defining methods to evaluate the suitability of AQM schemes
for deployment in the general Internet <xref
target="ID.AQM.eval"></xref>.</t>
</section>
<section anchor="Bleaching"
title="Bleaching and Middlebox Requirements to deploy ECN">
<t>Network devices should not be configured to change the ECN
codepoint in the packets that they forward, except to set the
CE-codepoint to signal incipient congestion.</t>
<t>Cases have been noted where an endpoint sends a packet with a
non-zero ECN mark, but the packet is received by the remote endpoint
with a zero ECN codepoint <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). Bleaching may
occur for various reasons (including normalising packets to hide which
equipment supports ECN). This policy prevents use of ECN by
applications.</t>
<t>When ECN-capable IP packets, marked as ECT(0) or ECT(1), are
remarked to non-ECN-capable (i.e., the ECN field is set to zero
codepoint), this could result in the packets being dropped by
ECN-capable network devices further along the path. This 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 network device decides not to forward the packet
with the CE-mark, it has to instead drop the packet and not bleach the
marking. This is because a CE-marked packet has 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.</t>
<t>Prior to RFC2474, a previous usage assigned the bits now forming
the ECN field 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 was allowed to remark or erase the ECN
codepoints, and such equipment needs to be updated to the current
specifications to support ECN.</t>
</section>
<section anchor="Tunnels"
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). These methods need to ensure that
the ECN-field of the tunnel packets is handled correctly at the
ingress and egress of the tunnel. Guidance on the correct use of ECN
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>
<section anchor="mechanisms" title="Using ECN across the Internet">
<t>A receiving endpoint needs to report the loss it experiences when it
uses loss-based congestion control. So also, when ECN is enabled, a
receiving endpoint must correctly report the presence of CE-marks by
providing a mechanism to feed this congestion information back to the
sending endpoint <xref target="RFC3168">,</xref>, <xref
target="ID.RFC5405.bis"></xref>, enabling the sender to react to
experienced congestion. This mechanism needs to be designed to operate
robustly across a wide range of Internet path characteristics. This
section describes partial deployment, how ECN-enabled endpoints can
continue to work effectively over a path that experiences misbehaving
network devices or when an endpoint does not correctly provide feedback
of ECN congestion information.</t>
<section title="Partial Deployment">
<t>Use of ECN is negotiated between the endpoints prior to using the
mechanism. This</t>
<t>ECN has been designed to allow incremental partial deployment <xref
target="RFC3168"></xref>. Any network device can choose to use either
ECN or some other loss-based policy to manage its traffic. Similarly,
transport/application negotiation allows senders and receiving
endpoints to choose whether ECN is to be used to manage congestion for
a particular network flow.</t>
</section>
<section anchor="Verification"
title="Detecting whether a Path Really Supports ECN">
<t>Internet transport and applications need to be robust to the
variety and sometimes varying path characteristics that are
encountered in the general Internet They need to monitor correct
forwarding of ECN over the entire path and duration of a session. </t>
<t>To be robust, applications and transports need to be designed with
the expectation of heterogeneous forwarding (e.g., where some IP
packets are CE-marked by one network device, and some by another,
possibly using a different AQM algorithm, or when a combination of
CE-marking and loss-based congestion indications are used. ( <xref
target="ID.AQM.eval"></xref> describes methodologies for evaluating
AQM schemes.)</t>
<t>A 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 (see
<xref target="Bleaching"></xref>). </t>
<t>A sending endpoint can check that any ECN-marks applied to packets
received from the path are indeed delivered to the remote receiving
endpoint and that appropriate feedback is provided. (This could be
done by a sender setting known ECN codepoints for specific packets in
a network flow and then checking whether the remote endpoint correctly
reports these marks <xref target="ID.Fallback"></xref>, <xref
target="TR15"></xref>.) If a sender detects misuse of ECN, it needs to
either conservatively react to congestion or even fall back to using
loss-based recovery instead of ECN. </t>
</section>
<section anchor="Cheating"
title="Detecting ECN Receiver Feedback Cheating">
<t>Appropriate feedback requires that the endpoint receiver does not
try to conceal reception of CE-marked packets in the ECN feedback
information provided to the sending endpoint <xref
target="ID.RFC2309.bis"></xref>. Designers of applications/transports
are therefore encouraged to include mechanisms that can detect this
misbehavior. If a sending endpoint detects that a receiver is not
correctly providing this feedback, it can either conservatively react
to congestion or fall back to using loss-based recovery instead of
ECN. </t>
</section>
</section>
<section title="Summary: Enabling ECN in Network Devices and Hosts">
<t>This section summarises the benefits of deploying and using ECN
within the Internet. It also provides a list of summary of prerequisites
to achieve ECN deployment.</t>
<t>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 the key
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>Network operators and people configuring network devices should
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>A network device that updates the ECN field in IP packets must
use IETF-specified methods (see <xref target="Codepoint"></xref>).
</t>
<t>A network device may support alternate ECN semantics (see <xref
target="Codepoint"></xref>).</t>
<t>Network devices need to be configured not to drop packets solely
because the ECT(0) or ECT(1) codepoints are used (see <xref
target="Forwarding"></xref>).</t>
<t>A network device must not change a packet with a CE mark to a
zero codepoint, if the network device decides not to forward the
packet with the CE-mark, it has to instead drop the packet and not
bleach the marking (see <xref target="Bleaching"></xref>).</t>
<t>An ECN-capable network device should correctly update the ECN
codepoint of ECN-capable packets in the presence of incipient
congestion (see <xref target="Enabling"></xref>).</t>
<t>Network devices need to be able to forward both ECN-capable and
non-ECN-capable flows (see <xref target="Non-ECN"></xref>).</t>
</list></t>
<t>Prerequisites for network endpoints to enable use of ECN include:</t>
<t><list style="symbols">
<t>an application should use an Internet transport that can set and
receive ECN marks (see <xref target="mechanisms"></xref>).</t>
<t>an ECN-capable transport/application must return feedback
indicating congestion to the sending endpoint and perform an
appropriate congestion response (see <xref
target="mechanisms"></xref>).</t>
<t>an ECN-capable transport/application should detect paths where
there is misuse of ECN and either conservatively react to congestion
or even fall back to not using ECN (see <xref
target="Verification"></xref>).</t>
<t>designers of applications/transports are encouraged to include
mechanisms that can detect and react appropriately to misbehaving
receivers that fail to report CE-marked packets (see <xref
target="Cheating"></xref>).</t>
</list></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, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes
Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie, and
other members of the AQM and TSV Working Groups.</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 informative references</t>
<t>Revision 04 (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 definitions 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 sucessfull.</t>
<t>Revision 05 (after WGLC comments)</t>
<t>Updated abstract to avoid suggesting that this describes new methods
for deployment.</t>
<t>Added ECN-field definition, and sorted terms in order.</t>
<t>Added an opening para to each "benefit" to say what this is. Sought
to remove redundnacy between sections.</t>
<t>Added new section on Codepoints to avoid saying the same thing
twice.</t>
<t>Reworked sections 3 and 4 to clarify discussion and to remove
unnecessary text.</t>
<t>Reformatted Summary to refer to sections describing things, rather
than appear as a list of new recommendations. Reordered to match the new
document order.</t>
<t>Note: This version expects an update to RFC5405.bis that will
indicate UDP ECN requirements (normative).</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 15:53:27 |