One document matched: draft-ietf-aqm-ecn-benefits-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!--<!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 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-00" 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 and Pitfalls 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="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>
<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>
<date month="October" year="2014" />
<!-- 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 and pitfalls 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 lists 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>When an application 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
to indicate to routers 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 is generally not known by the transport endpoints.</t>
<t>ECN makes it possible for the network to signal congestion without
packet loss. This lets the network deliver some packets to an
application that would otherwise have been dropped. 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 routers). There are also
some potential pitfalls when enabling ECN.</t>
<!--
GF Edited MW's text - hope this is OK.
-->
<t>The focus of this document is on usage of ECN, not its implementation
in endpoint devices, routers and other network devices. <xref
target="RFC3168"></xref> describes a method in which a router sets the
CE codepoint of an ECN-Capable packet at the time that the router would
otherwise have dropped the packet.</t>
<t>While it has often been assumed that
routers mark packets at the same level of congestion at which they would
otherwise drop them, separate configuration of the drop and mark
thresholds is known to be supported in some network devices and this is
recommended in <xref target="RFC2309.bis"></xref>. Some benefits of ECN
that are discussed rely upon routers marking
packets at a lower level of congestion before they would otherwise drop
packets from queue overflow <xref target="KH13"></xref>.</t>
<t>Some of benefits are also only realised when the transport endpoint
behaviour is also updated, this is discussed further in <xref
target="sec-experimental"></xref>.</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>
</section>
<section title="ECN Deployment Scenarios / Use Cases">
<t>XXX to be continued -- this section is intended to describe some
specific example cases of where ECN has provided benefit XXX</t>
<section title="ECN within data centers">
<t>ECN with a low marking threshold has been proposed for use within
a data centre environment. This proposed usage exploits ECN in
combination with an updated transport behaviour,
Datacenter TCP (DCTCP) <xref target="AL10"></xref>.</t>
</section>
</section>
<section title="Benefit of using ECN to avoid congestion loss">
<t>An application that uses a transport that supports ECN can
benefit in several ways:</t>
<section 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 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 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 for a loss
that is a result of congestion:</t>
<t><list style="symbols">
<t>First, the application receives the data normally - this also
avoids dropping data that has already made it across at least part
of the network path. This avoids the additional delay of waiting
for recovery of the lost segment.</t>
<t>Second, the transport receiver notes the ECN-marked packets,
and then requests the sender to make an appropriate
congestion-response for future traffic.</t>
</list></t>
</section>
<section title="Reduced Probability of RTO Expiry">
<t>ECN can help reduce the chance of the TCP or SCTP retransmission
timer expiring (RTO expiry). 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
the last segment (or last few segments) using standard methods such as
Fast Recovery, since the receiver is unaware that the lost segments
were actually sent.</t>
<t>ECN provides a mitigation when the loss is a result of (mild)
congestion, since a router may mark, rather than drop, these segments
- which benefits the application in a way similar to above, but with
the significant additional benefit that this eliminates a
retransmission event. The application benefits because:</t>
<t><list style="symbols">
<t>Data is received without HOL blocking.</t>
<t>The transport does not suffer RTO expiry with consequent loss
of state about the network path it is using. This would cause it
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 adapts to the path again. This can
improve the throughput of the application.</t>
</list></t>
<t>The benefit of avoiding reliance on an RTO-based retransmission
event can be especially significant when ECN is used on TCP SYN/ACK
packets as specified in <xref target="RFC5562"></xref> because in this
case TCP cannot base its RTO for these packets on prior RTT
measurements from the same connection.</t>
</section>
<section title="Applications that do not retransmit lost packets">
<t>Certain 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. By decoupling congestion control from loss, ECN can
allow such applications to reduce their rate before experiencing
significant loss. It also enables them to decide how to discard data in
a controlled manner, rather than forcing them to recover from loss.
This reduces the negative impact of having to rely on
loss-hiding mechanisms (e.g. Packet forward error correction, or data
duplication), yielding 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>If ECN is configured such that routers mark packets at a lower level
of congestion before they would otherwise drop packets from queue
overflow, an application can benefit from using ECN in the following
ways:</t>
<section anchor="sec-ss" title="Avoiding Capacity Overshoot ">
<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 serious congestion, an early-marking method can help a
transport respond before it induces significant congestion. For
example, a TCP or SCTP sender can avoid incurring significant
congestion during Slow Start, or a bulk application that tries to
increase its rate as fast as possible, may detect the presence of
congestion, causing it to 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 probing for bandwidth can reduce its rate as soon as
ECN-marked packets are detected, and before the applications increases
its rate to the point where it builds a router queue that induces
congestion loss. This benefits the 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 could 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. This
is used by Congestion Exposure (CoNex) <xref
target="RFC6789"></xref>.</t>
<t>Note: traffic that observes only congestion marks and no loss
implies that a sender 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 mixture of ECN-marks and loss may occur
during only congestion or from a combination of packet loss and
congestion.</t>
</section>
</section>
<section anchor="sec-experimental"
title="Other forms of ECN-Marking/Reactions">
<t>The ECN mechanism defines both how packets are marked and transports
need to react to markings. This section describes the benefits when
updated methods are used.</t>
<t>Benefit has been noted when packets are 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 RTP over UDP <xref target="RFC6679"></xref> and proposed
for SCTP <xref target="ST14"></xref> and TCP <xref
target="KU13"></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 title="Pitfalls when using ECN">
<t>This section describes issues with ECN.</t>
<section title="Bleaching and middlebox requirements to deploy">
<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. A previous usage assigned these
bits as a part of the now deprecated Type of Service (ToS) field.
Equipment conformant with this older specification may remark or erase
the ECN codepoints, such equipment needs to be updated to the current specifications
to support ECN.</t>
<t>Another policy may erase or "bleach" the ECN marks at a network edge (resetting
these to zero) for various reasons (including normalising packets to hide which
equipment support ECN). This policy prevents use of ECN.</t>
<t>Some networks may use ECN internally or tunnel ECN fro traffic engineering
or security. Guidance on the correct use of ECN in this case is provided
in <xref target="RFC6040"></xref>.</t>
<t>The recommendation of this document is that a router or middlebox
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), and
SHOULD NOT remark an ECT(0) or ECT(1) mark to zero.</t>
</section>
<section title="Cheating">
<t>Endpoint receivers MUST NOT try to conceal reception of CE marks in the
ECN feedback information they provide to the sending endpoint. Transport
protocols are actively encouraged to include mechanisms that can detect and
appropriately respond to such misbehavior.</t>
</section>
<section title="The possible need to verify if a path really supports ECN">
<t>Endpoints need to be robust to path changes that may impact the ability
to effectively signal or use ECN across a path, e.g. when a path changes to
use a middlebox that bleaches ECN codepoints. As a necessary but short term
fix, such mechanisms could fall-back to disabling use of ECN.</t>
</section>
</section>
<section title="Conclusion">
<t>People configuring host stacks and network devices should ensure
that their equipment correctly reacts to packets carrying ECN codepoints.
This includes:
<list style="symbols">
<t>routers not resetting the ECN codepoint to zero by default</t>
<t>routers correctly updating the codepoint in the presence of congestion</t>
<t>routers correctly supporting alternate ECN semantics (<xref target="RFC4774"></xref>)</t>
<t>hosts receiving ECN marks correctly reflecting them</t>
</list>
</t>
<t>Application developers should where possible use transports that
enable the benefits of ECN. Once enabled, the benefits of ECN are
provided by the transport layer and the application does not need to be
rewritten to gain these benefits. Table 1 summarises some of these
benefits.</t>
<figure>
<artwork><![CDATA[+---------+-----------------------------------------------------+
| Section | Benefit |
+---------+-----------------------------------------------------+
| 2.1 | Improved Throughput |
| 2.2 | Reduced Head-of-Line |
| 2.3 | Reduced Probability of RTO Expiry |
| 2.4 | Applications that do not retransmit lost packets |
| 3.1 | Avoiding Capacity Overshoot |
| 3.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</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>XXRFC 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>
</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">
&RFC3649;
&RFC3742;
&RFC3758;
&RFC4340;
&RFC4774;
&RFC5562;
&RFC6040;
&RFC6679;
&RFC6789;
<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="KU13" target="">
<front>
<title>Problem Statement and Requirements for a More Accurate ECN
Feedback</title>
<author fullname="M. Kuehlewind" initials="M." surname="Kuehlewind"></author>
<author fullname="R. Scheffenegger" initials="R."
surname="Scheffenegger"></author>
<date month="October" year="2013" />
</front>
<seriesInfo name="Internet-draft"
value="draft-ietf-tcpm-accecn-reqs-04.txt" />
</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:35:25 |