One document matched: draft-briscoe-tsvwg-ecn-l4s-id-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.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">
<!ENTITY RFC0970 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0970.xml">
<!ENTITY RFC2309 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2474 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC3540 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3540.xml">
<!ENTITY RFC6660 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml">
<!ENTITY RFC2983 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml">
<!ENTITY RFC3246 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3246.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 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 RFC6077 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6077.xml">
<!ENTITY RFC6679 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-encap-guidelines SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-encap-guidelines.xml">
<!ENTITY I-D.ietf-tcpm-accecn-reqs SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-accecn-reqs.xml">
<!ENTITY I-D.ietf-aqm-pie SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-aqm-pie.xml">
<!ENTITY I-D.ietf-aqm-fq-codel SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-aqm-fq-codel.xml">
<!ENTITY I-D.bensley-tcpm-dctcp SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bensley-tcpm-dctcp.xml">
<!ENTITY I-D.zimmermann-tcpm-cubic SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.zimmermann-tcpm-cubic.xml">
<!ENTITY I-D.sridharan-tcpm-ctcp SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.sridharan-tcpm-ctcp.xml">
<!ENTITY I-D.moncaster-tcpm-rcv-cheat SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.moncaster-tcpm-rcv-cheat.xml">
<!ENTITY I-D.ietf-conex-abstract-mech SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-conex-abstract-mech.xml">
<!ENTITY I-D.briscoe-aqm-dualq-coupled SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.briscoe-aqm-dualq-coupled.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://xml.resource.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="4"?>
<!-- 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 -->
<rfc category="exp" docName="draft-briscoe-tsvwg-ecn-l4s-id-00"
ipr="trust200902" updates="">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
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="ECN Semantics for Low Queuing Delay">Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing
Delay</title>
<author fullname="Koen De Schepper" initials="K." surname="De Schepper">
<organization>Bell Labs</organization>
<address>
<postal>
<street/>
<city>Antwerp</city>
<country>Belgium</country>
</postal>
<email>koen.de_schepper@alcatel-lucent.com</email>
<uri>https://www.bell-labs.com/usr/koen.de_schepper</uri>
</address>
</author>
<author fullname="Bob Briscoe" initials="B." role="editor"
surname="Briscoe">
<organization>Simula Research Lab</organization>
<address>
<postal>
<street/>
</postal>
<email>ietf@bobbriscoe.net</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<!--
<author fullname="Olga Bondarenko" initials="O." surname="Bondarenko">
<organization>Simula Research Lab</organization>
<address>
<postal>
<street/>
<city>Lysaker</city>
<country>Norway</country>
</postal>
<email>olgabnd@gmail.com</email>
<uri>https://www.simula.no/people/olgabo</uri>
</address>
</author>
-->
<author fullname="Ing-jyh Tsang" initials="I." surname="Tsang">
<organization>Bell Labs</organization>
<address>
<postal>
<street/>
<city>Antwerp</city>
<country>Belgium</country>
</postal>
<email>ing-jyh.tsang@alcatel-lucent.com</email>
</address>
</author>
<date day="" month="" year="2015"/>
<area>Transport</area>
<workgroup>Transport Services (tsv)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>I-D</keyword>
<abstract>
<t>This specification defines the identifier to be used on IP packets
for a new network service called low latency, low loss and scalable
throughput (L4S). It is similar to the original (or 'Classic') Explicit
Congestion Notification (ECN). 'Classic' ECN marking was required to be
equivalent to a drop, both when applied in the network and when
responded to by a transport. Unlike 'Classic' ECN marking, the network
applies the L4S identifier more immediately and more aggressively than
drop, and the transport response to each mark is reduced and smoothed
relative to that for drop. The two changes counterbalance each other so
that the bit-rate of an L4S flow will be roughly the same as a 'Classic'
flow under the same conditions. However, the much more frequent control
signals and the finer responses to them result in ultra-low queuing
delay without compromising link utilization, even during high load.
Examples of new active queue management (AQM) marking algorithms and
examples of new transports (whether TCP-like or real-time) are specified
separately. The new L4S identifier is the key piece that enables them to
interwork and distinguishes them from 'Classic' traffic. It gives an
incremental migration path so that existing 'Classic' TCP traffic will
be no worse off, but it can be prevented from degrading the ultra-low
delay and loss of the new scalable transports.</t>
</abstract>
</front>
<middle>
<section anchor="l4sid_intro" title="Introduction">
<t>This specification defines the identifier to be used on IP packets
for a new network service called low latency, low loss and scalable
throughput (L4S). It is similar to the original (or 'Classic') Explicit
Congestion Notification (ECN). 'Classic' ECN marking was required to be
equivalent to a drop, both when applied in the network and when
responded to by a transport. Unlike 'Classic' ECN marking, the network
applies the L4S identifier more immediately and more aggressively than
drop, and the transport response to each mark is reduced and smoothed
relative to that for drop. The two changes counterbalance each other so
that the bit-rate of an L4S flow will be roughly the same as a 'Classic'
flow under the same conditions. However, the much more frequent control
signals and the finer responses to them result in ultra-low queuing
delay without compromising link utilization, even during high load. </t>
<t>An example of an active queue management (AQM) marking algorithm that
enables the L4S service is the DualQ Coupled AQM defined in a
complementary specification <xref
target="I-D.briscoe-aqm-dualq-coupled"/>. An example of a scalable
transport that would enable the L4S service is Data Centre TCP (DCTCP),
which until now has been applicable solely to controlled environments
like data centres <xref target="I-D.bensley-tcpm-dctcp"/>, because it is
too aggressive to co-exist with existing TCP. However, AQMs like DualQ
Coupled enable scalable transports like DCTCP to co-exist with existing
traffic, each getting roughly the same flow rate when they compete under
similar conditions.</t>
<t>The new L4S identifier is the key piece that enables these two parts
to interwork and distinguishes them from 'Classic' traffic. It gives an
incremental migration path so that existing 'Classic' TCP traffic will
be no worse off, but it can be prevented from degrading the ultra-low
delay and loss of the new scalable transports. The performance
improvement is so great that it is hoped it will motivate initial
deployment of the separate parts of this system.</t>
<section anchor="l4sid_problem" title="Problem">
<t>Latency is becoming the critical performance factor for many
(most?) applications on the public Internet, e.g. Web, voice,
conversational video, gaming and finance apps. In the developed world,
further increases in access network bit-rate offer diminishing
returns, whereas latency is still a multi-faceted problem. In the last
decade or so, much has been done to reduce propagation time by placing
caches or servers closer to users. However, queuing remains a major
component of latency.</t>
<t>The Diffserv architecture provides Expedited Forwarding <xref
target="RFC3246"/>, so that low latency traffic can jump the queue of
other traffic. However, on access links dedicated to individual sites
(homes, small enterprises or mobile devices), often all traffic at any
one time will be latency-sensitive. Then Diffserv is of little use.
Instead, we need to remove the causes of any unnecessary delay.</t>
<t>The bufferbloat project has shown that excessively-large buffering
(`bufferbloat') has been introducing significantly more delay than the
underlying propagation time. These delays appear only
intermittently—only when a capacity-seeking (e.g. TCP) flow is
long enough for the queue to fill the buffer, making every packet in
other flows sharing the buffer sit through the queue.</t>
<t>Active queue management (AQM) was originally developed to solve
this problem (and others). Unlike Diffserv, which gives low latency to
some traffic at the expense of others, AQM controls latency for <spanx
style="emph">all</spanx> traffic in a class. In general, AQMs
introduce an increasing level of discard from the buffer the longer
the queue persists above a shallow threshold. This gives sufficient
signals to capacity-seeking (aka. greedy) flows to keep the buffer
empty for its intended purpose: absorbing bursts. However,
RED <xref target="RFC2309"/> and other algorithms from the 1990s
were sensitive to their configuration and hard to set correctly. So,
AQM was not widely deployed. More recent state-of-the-art AQMs, e.g.
fq_CoDel <xref target="I-D.ietf-aqm-fq-codel"/>, PIE <xref
target="I-D.ietf-aqm-pie"/>, Adaptive RED <xref
target="ARED01"/>, define the threshold in time not bytes, so it is
invariant for different link rates.</t>
<t>Latency is not our only concern: It was known when TCP was first
developed that it would not scale to high bandwidth-delay products.
Given regular broadband bit-rates over WAN distances are
already <xref target="RFC3649"/> beyond the scaling range of
`classic' TCP Reno, `less unscalable' Cubic <xref
target="I-D.zimmermann-tcpm-cubic"/> and Compound <xref
target="I-D.sridharan-tcpm-ctcp"/> variants of TCP have been
successfully deployed. However, these are now approaching their
scaling limits. Unfortunately, fully scalable TCPs such as DCTCP <xref
target="I-D.bensley-tcpm-dctcp"/> cause `classic' TCP to starve
itself, which is why they have been confined to private data centres
or research testbeds (until now).</t>
<t>It turns out that a TCP algorithm like DCTCP that solves TCP's
scalability problem also solves the latency problem, because the finer
sawteeth cause very little queuing delay. A supporting paper <xref
target="DCttH15"/> gives the full explanation of why the design solves
both the latency and the scaling problems, both in plain English and
in more precise mathematical form. THe explanation is summarised
without the maths in <xref
target="I-D.briscoe-aqm-dualq-coupled"/>.</t>
</section>
<section anchor="l4sid_Terminology" title="Terminology">
<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"/>. In this document, these words will appear with
that interpretation only when in ALL CAPS. Lower case uses of these
words are not to be interpreted as carrying RFC-2119 significance.</t>
<t><list style="hanging">
<t hangText="Classic service:">The `Classic' service is intended
for all the behaviours that currently co-exist with TCP Reno (TCP
Cubic, Compound, SCTP, etc).</t>
<t hangText="Low-Latency, Low-Loss and Scalable (L4S):">The `L4S'
service is intended for traffic from scalable TCP algorithms such
as Data Centre TCP. But it is also more general—it will
allow a set of congestion controls with similar scaling properties
to DCTCP (e.g. Relentless <xref target="Mathis09"/>) to
evolve.<vspace blankLines="1"/>Both Classic and L4S services can
cope with a proportion of unresponsive or less-responsive traffic
as well (e.g. DNS, VoIP, etc).</t>
<t hangText="Classic ECN:">The original Explicit Congestion
Notification (ECN) protocol <xref target="RFC3168"/>.</t>
</list></t>
</section>
<section title="Scope">
<t>.The new L4S identifier defined in this specification is applicable
for IPv4 and IPv6 packets (as for classic ECN <xref
target="RFC3168"/>). It is applicable for the unicast, multicast and
anycast forwarding modes. It is an orthogonal packet classification to
Differentiated Services (Diffserv <xref target="RFC2474"/>), therefore
it can be applied to any packet in any Diffserv traffic class.
However, as with classic ECN, any particular forwarding node might not
implement an active queue management algorithm in all its DIffserv
queues.</t>
<t>This document is intended for experimental status, so it does not
update any standards track RFCs. If the experiment is successful and
this document proceeds to the standards track, it would be expected to
update the specification of ECN in IP and in TCP <xref
target="RFC3168"/>. For packets carrying the L4S identifier, it would
update both the network's ECN marking behaviour and the TCP response
to ECN feedback, making them distinct from the behaviours for drop. It
would also update the specification of ECN in RTP over UDP <xref
target="RFC6679"/> {ToDo: DCCP and SCTP refs}. Finally, it would also
obsolete the experimental ECN nonce <xref target="RFC3540"/>.</t>
</section>
</section>
<section anchor="l4sid_identifier" title="L4S Packet Identifier">
<t/>
<section anchor="l4sid_reqs"
title="L4S Packet Identification Requirements">
<t>Ideally, the identifier for packets using the Low Latency, Low
Loss, Scalable throughput (L4S) service ought to meet the following
requirements:<list style="symbols">
<t>it SHOULD survive end-to-end between source and destination
applications: across the boundary between host and network,
between interconnected networks, and through middleboxes;</t>
<t>it SHOULD be common to IPv4 and IPv6;</t>
<t>it SHOULD be incrementally deployable;</t>
<t>it SHOULD enable an AQM to classify packets encapsulated by
outer IP or lower-layer headers;</t>
<t>it SHOULD consume minimal extra codepoints;</t>
<t>it SHOULD not lead to some packets of a transport-layer flow
being served by a different queue from others.</t>
</list></t>
<t>It is recognised that the chosen identifier is unlikely to satisfy
all these requirements, particularly given the limited space left in
the IP header. Therefore a compromise will be necessary, which is why
all the requirements are expressed with the word 'SHOULD' not 'MUST'.
<xref target="l4sid_Alts"/> discusses the pros and cons of the
compromises made in various competing identification schemes. The
chosen scheme is defined in <xref target="l4sid_identification"/>
below.</t>
<t>Whether the identifier would be recoverable if the experiment
failed is a factor that could be taken into account. However, this has
not been made a requirement, because that would favour schemes that
would be easier to fail, rather than those more likely to succeed.</t>
</section>
<section anchor="l4sid_identification" title="L4S Packet Identification">
<t>The L4S treatment is an alternative packet marking treatment <xref
target="RFC4774"/> to the classic ECN treatment <xref
target="RFC3168"/>. Like classic ECN, it identifies the marking
treatment that network nodes are expected to apply to L4S packets, and
it identifies packets that are expected to have been sent from hosts
applying a broad type of behaviour, termed L4S congestion control.</t>
<t>For a packet to receive L4S treatment as it is forwarded, the
sender MUST set the ECN field in the IP header (v4 or v6) to the
ECT(1) codepoint.</t>
<t>A network node that implements the L4S service MUST classify
arriving ECT(1) packets for L4S treatment and it SHOULD classify
arriving CE packets for L4S treatment as well. <xref
target="l4sid_identification_trasnport_aware"/> describes an exception
to this latter rule.</t>
<t>The L4S AQM treatment follows similar codepoint transition rules to
those in RFC 3168. Specifically, the ECT(1) codepoint MUST NOT be
changed to any other codepoint than CE, and CE MUST NOT be changed to
any other codepoint. An ECT(1) packet is classified as ECN-capable
and, if congestion increases, an L4S AQM algorithm will set the ECN
marking of an increasing proportion of packets to CE, otherwise
forwarding packets unchanged as ECT(1). The L4S marking treatment is
defined in <xref target="l4sid_Seamntics"/>. Under persistent overload
conditions, the AQM will follow RFC 3168 and turn off ECN marking,
using drop as a congestion signal until the overload episode has
subsided.</t>
<t>The L4S treatment is the default for ECT(1) packets in all Diffserv
Classes <xref target="RFC4774"/>.</t>
<t>For backward compatibility, a network node that implements the L4S
treatment MUST also implement a classic AQM treatment. It MUST
classify arriving ECT(0) and Not-ECT packets for treatment by the
Classic AQM. Classic treatment means that the AQM will mark ECT(0)
packets under the same conditions as it would drop Not-ECT packets
<xref target="RFC3168"/>.</t>
</section>
<section anchor="l4sid_identification_trasnport_aware"
title="L4S Packet Identification with Transport-Layer Awareness">
<t>To implement the L4S treatment, a network node does not need to
identify transport-layer flows. Nonetheless, if a network node is
capable of identifying transport-layer flows, it SHOULD classify CE
packets for classic ECN <xref target="RFC3168"/> treatment if the most
recent ECT packet in the same flow was ECT(0). If a network node does
not identify transport-layer flows, or if the most recent ECT packet
was ECT(1), it MUST classify CE packets for L4S treatment.</t>
<t>Only the most recent ECT packet of a flow is used to classify a CE
packet, because a sender might have to switch from sending ECT(1)
(L4S) packets to sending ECT(0) (Classic) packets, or back again, in
the middle of a transport-layer flow. Such a switch-over is likely to
be very rare, but It could be necessary if the path bottleneck moves
from a network node that supports L4S to one that only supports
Classic ECN. Such a change ought to be detectable from the change in
RTT variation.</t>
<!--{ToDo: What if there have been CE and ECT(0) packets, but no ECT(1) packets for some time?}-->
</section>
<section anchor="l4sid_Seamntics"
title="The Meaning of CE Relative to Drop">
<t>The likelihood that an AQM drops a Not-ECT Classic packet MUST be
proportional to the square of the likelihood that it would have marked
it if it had been an L4S packet. The constant of proportionality does
not have to be standardised for interoperability, but a value of 1 is
RECOMMENDED.</t>
<t><xref target="I-D.briscoe-aqm-dualq-coupled"/>.specifies the
essential aspects of an L4S AQM, as well as recommending other
aspects. It gives an example implementation in an appendix.</t>
<t>The term 'likelihood' is used above to allow for marking and
dropping to be either probabilistic or deterministic. This example AQM
in <xref target="I-D.briscoe-aqm-dualq-coupled"/> drops and marks
probabilistically, so the drop probability is arranged to be the
square of the marking probability. Nonetheless, an alternative AQM
that dropped and marked deterministically would be valid, as long as
the dropping frequency was proportional to the square of the marking
frequency.</t>
<t>Note that, contrary to RFC 3168, an AQM implementing the L4S and
Classic treatments does not mark an ECT(1) packet under the same
conditions that it would have dropped a Not-ECT packet. However, it
does mark and ECT(0) packet under the same conditions that it would
have dropped a Not-ECT packet.</t>
</section>
</section>
<section anchor="l4sid_IANA" title="IANA Considerations">
<t>This specification contains no IANA considerations.</t>
<t>{ToDo: If this specification becomes and experimental RFC, should
IANA be asked to update
<http://www.iana.org/assignments/ipv4-tos-byte/ipv4-tos-byte.xhtml#ipv4-tos-byte-1>
so that the reference for the specification of ECT(1) points to this
document, and CE points to both RFC3168 and this document? I think not,
because this experimental specification will not update RFC3168, which
is standards track.}</t>
</section>
<section anchor="l4sid_Security_Considerations"
title="Security Considerations">
<t>Two approaches to assure the integrity of signals using the new
identifer are introduced in <xref
target="l4sid_competing_integrity"/>.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Richard Scheffenegger, John Leslie, David Täht,
Jonathan Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson and
Andrew McGregor for the discussions that led to this specification.</t>
<t>The authors' contributions are part-funded by the European Community
under its Seventh Framework Programme through the Reducing Internet
Transport Latency (RITE) project (ICT-317700). The views expressed here
are solely those of the authors.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC3168;
&RFC4774;
&RFC6679;
</references>
<references title="Informative References">
&RFC2474;
&RFC2309;
&RFC3540;
&RFC2983;
&RFC3246;
&RFC3649;
&RFC5562;
&RFC6660;
&RFC6077;
&I-D.ietf-tcpm-accecn-reqs;
&I-D.ietf-aqm-pie;
&I-D.ietf-aqm-fq-codel;
&I-D.ietf-tsvwg-ecn-encap-guidelines;
&I-D.moncaster-tcpm-rcv-cheat;
&I-D.ietf-conex-abstract-mech;
&I-D.briscoe-aqm-dualq-coupled;
<reference anchor="ARED01" target="http://www.icir.org/floyd/red.html">
<front>
<title>Adaptive RED: An Algorithm for Increasing the Robustness of
RED's Active Queue Management</title>
<author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization>ACIRI</organization>
</author>
<author fullname="Ramakrishna Gummadi" initials="R."
surname="Gummadi">
<organization>ACIRI</organization>
</author>
<author fullname="S. Shenker" initials="S." surname="Shenker">
<organization>ACIRI</organization>
</author>
<date month="August" year="2001"/>
</front>
<seriesInfo name="ACIRI Technical Report" value=""/>
<format target="http://www.icir.org/floyd/red.html" type="PDF"/>
</reference>
&I-D.bensley-tcpm-dctcp;
&I-D.zimmermann-tcpm-cubic;
&I-D.sridharan-tcpm-ctcp;
<reference anchor="Mathis09"
target="http://www.hpcc.jp/pfldnet2009/Program_files/1569198525.pdf">
<front>
<title>Relentless Congestion Control</title>
<author fullname="Matt Mathis" initials="M." surname="Mathis">
<organization>PSC</organization>
</author>
<date month="May" year="2009"/>
</front>
<seriesInfo name="PFLDNeT'09" value=""/>
<format target="http://www.hpcc.jp/pfldnet2009/Program_files/1569198525.pdf"
type="PDF"/>
</reference>
<!--{ToDo: DCttH ref will need to be updated, once stable}-->
<reference anchor="DCttH15"
target="http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf">
<front>
<title>`Data Centre to the Home': Ultra-Low Latency for All</title>
<author fullname="Koen De Schepper" initials="K."
surname="De Schepper">
<organization>Bell Labs</organization>
</author>
<author fullname="Olga Bondarenko" initials="O."
surname="Bondarenko">
<organization>Simula Research Lab</organization>
</author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
</author>
<author fullname="Ing-jyh Tsang" initials="I." surname="Tsang">
<organization>Bell Labs</organization>
</author>
<date year="2015"/>
</front>
<annotation>(Under submission)</annotation>
</reference>
<reference anchor="VCP"
target="http://doi.acm.org/10.1145/1080091.1080098">
<front>
<title>One more bit is enough</title>
<author fullname="Yong Xia" initials="Y." surname="Xia">
<organization/>
</author>
<author fullname="Lakshminarayanan Subramanian" initials="L."
surname="Subramanian">
<organization/>
</author>
<author fullname="Ion Stoica" initials="I." surname="Stoica">
<organization/>
</author>
<author fullname="Shivkumar Kalyanaraman" initials="S."
surname="Kalyanaraman">
<organization/>
</author>
<date month="" year="2005"/>
</front>
<seriesInfo name="Proc. SIGCOMM'05, ACM CCR" value="35(4)37--48"/>
<format target="http://conferences.sigcomm.org/sigcomm/2005/paper-XiaSub.pdf"
type="PDF"/>
</reference>
<reference anchor="QV" target="TBA">
<front>
<title>Up to Speed with Queue View</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
</author>
<author fullname="Per Hurtig" initials="P." surname="Hurtig">
<organization>Uni Karlstad</organization>
</author>
<date month="August" year="2015"/>
</front>
<seriesInfo name="RITE Technical Report" value=""/>
<format target="TBA" type="PDF"/>
</reference>
</references>
<section anchor="l4sid_Alts" title="Alternative Identifiers">
<t>This appendix is informative, not normative. It records the pros and
cons of various alternative ways to identify L4S packets to record the
rationale for the choice of ECT(1) (<xref target="l4sid_ECT1_CE"/>) as
the L4S identifier. At the end, <xref target="l4sid_Als_Summary"/>
summarises the distinguishing features of the leading alternatives,.It
is intended to supplement, not replace the detailed text.</t>
<t>The leading solutions all use the ECN field, sometimes in combination
with the Diffserv field. Both the ECN and Diffserv fields have the
additional advantage that they are no different in either IPv4 or IPv6.
A couple of alternatives that use other fields are mentioned at the end,
but it is quickly explained why they are not serious contenders.</t>
<section anchor="l4sid_ECT1_CE" title="ECT(1) and CE codepoints">
<t>Definition:<list style="empty">
<t>Packets with ECT(1) and conditionally packets with CE would
signify L4S semantics as an alternative to the semantics of
classic ECN <xref target="RFC3168"/>, specifically:<list
style="symbols">
<t>The ECT(1) codepoint would signify that the packet was sent
by an L4S-capable sender. Successful negotiation of accurate
ECN (AccECN) feedback <xref
target="I-D.ietf-tcpm-accecn-reqs"/> is a pre-requisite for a
sender to send L4S packets, therefore ECT(1) in turn signifies
that both endpoints support AccECN;</t>
<t>Given shortage of codepoints, both L4S and classic ECN
sides of an AQM would have to use the same CE codepoint to
indicate that a packet had experienced congestion. If a packet
that had already been marked CE in an upstream buffer arrived
at a subsequent AQM, this AQM would then have to guess whether
to classify CE packets as L4S or classic ECN. Choosing the L4S
treatment would be a safer choice, because then a few classic
packets might arrive early, rather than a few L4S packets
arriving late;</t>
<t>Additional information might be available if the classifier
were transport-aware. Then it could classify a CE packet for
classic ECN treatment if the most recent ECT packet in the
same flow had been marked ECT(0). However, the L4S service
should not need tranport-layer awareness;</t>
</list></t>
</list>Cons:<list style="hanging">
<t hangText="Consumes the last ECN codepoint:">The L4S service is
intended to supersede the service provided by classic ECN,
therefore using ECT(1) to identify L4S packets could ultimately
mean that the ECT(0) codepoint was `wasted' purely to distinguish
one form of ECN from its successor;</t>
<t hangText="ECN hard in some lower layers:">It is not always
possible to support ECN in an AQM acting in a buffer below the IP
layer <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines"/>. In
such cases, the L4S service would have to drop rather than mark
frames even though they might contain an ECN-capable packet.
However, such cases would be unusual.</t>
<t hangText="Risk of reordering classic CE packets:">Having to
classify all CE packets as L4S risks some classic CE packets
arriving early, which is a form of reordering. Reordering can
cause the TCP sender to retransmit spuriously. However, one or two
packets delivered early does not cause any spurious
retransmissions because the subsequent packets continue to move
the cumulative acknowledgement boundary forwards. Anyway, even the
risk of reordering would be low, because: i) it is quite unusual
to experience more than one bottleneck queue on a path; ii) even
then, reordering would only occur if there was simultaneous mixing
of classic and L4S traffic, which would be more unlikely in an
access link, which is where most bottlenecks are located; iii)
even then, spurious retransmissions would only occur if a
contiguous sequence of three or more classic CE packets from one
bottleneck arrived at the next, which should in itself happen very
rarely with a good AQM. The risk would be completely eliminated in
AQMs that were transport-aware (but they should not need to
be);</t>
<t hangText="Non-L4S service for control packets:">The classic ECN
RFCs <xref target="RFC3168"/> and <xref target="RFC5562"/> require
a sender to clear the ECN field to Not-ECT for retransmissions and
certain control packets specifically pure ACKs, window probes and
SYNs. When L4S packets are classified by the ECN field alone,
these control packets would not be classified into an L4S queue,
and could therefore be delayed relative to the other packets in
the flow. This would not cause re-ordering (because
retransmissions are already out of order, and the control packets
carry no data). However, it would make critical control packets
more vulnerable to loss and delay. {ToDo: Discuss the likelihood
that all these packets might be made ECN-capable in future.}</t>
</list></t>
<t>Pros:<list style="hanging">
<t hangText="Should work e2e:">The ECN field generally works
end-to-end across the Internet. Unlike the DSCP, the setting of
the ECN field is at least forwarded unchanged by networks that do
not support ECN, and networks rarely clear it to zero;</t>
<t hangText="Should work in tunnels:">Unlike Diffserv, ECN is
defined to always work across tunnels. However, tunnels do not
always implement ECN processing as they should do, particularly
because IPsec tunnels were defined differently for a few
years.</t>
<t hangText="Could migrate to one codepoint:">If all classic ECN
senders eventually evolve to use the L4S service, the ECT(0)
codepoint could be reused for some future purpose, but only once
use of ECT(0) packets had reduced to zero, or near-zero, which
might never happen.</t>
</list></t>
</section>
<section anchor="l4sid_ECN_DSCP"
title="ECN Plus a Diffserv Codepoint (DSCP)">
<t>Definition:<list style="empty">
<t>For packets with a defined DSCP, all codepoints of the ECN
field (except Not-ECT) would signify alternative L4S semantics to
those for classic ECN <xref target="RFC3168"/>, specifically:<list
style="symbols">
<t>The L4S DSCP would signifiy that the packet came from an
L4S-capable sender;</t>
<t>ECT(0) and ECT(1) would both signify that the packet was
travelling between transport endpoints that were both
ECN-capable and supported accurate ECN feedback <xref
target="I-D.ietf-tcpm-accecn-reqs"/>;</t>
<t>CE would signify that the packet had been marked by an AQM
implementing the L4S service.</t>
</list></t>
</list></t>
<t>Use of a DSCP is the only approach for alternative ECN semantics
given as an example in <xref target="RFC4774"/>. However, it was
perhaps considered more for controlled environments than new
end-to-end services;</t>
<t>Cons:<list style="hanging">
<t hangText="Consumes DSCP pairs:">A DSCP is obviously not
orthogonal to Diffserv. Therefore, wherever the L4S service is
applied to multiple Diffserv scheduling behaviours, it would be
necessary to replace each DSCP with a pair of DSCPs.</t>
<t hangText="Uses critical lower-layer header space:">The
resulting increased number of DSCPs might be hard to support for
some lower layer technologies, e.g. 802.1p and MPLS both offer
only 3-bits for a maximum of 8 traffic class identifiers. Although
L4S should reduce and possibly remove the need for some DSCPs
intended for differentiated queuing delay, it will not remove the
need for Diffserv entirely, because Diffserv is also used to
allocate bandwidth, e.g. by prioritising some classes of traffic
over others when traffic exceeds available capacity.</t>
<t hangText="Not end-to-end (host-network):">Very few networks
honour a DSCP set by a host. Typically a network will zero
(bleach) the Diffserv field from all hosts. Sometimes networks
will attempt to identify applications by some form of packet
inspection and, based on network policy, they will set the DSCP
considered appropriate for the identified application.
Network-based application identification might use some
combination of protocol ID, port numbers(s), application layer
protocol headers, IP address(es), VLAN ID(s) and even packet
timing.</t>
<t hangText="Not end-to-end (network-network):">Very few networks
honour a DSCP received from a neighbouring network. Typically a
network will zero (bleach) the Diffserv field from all
neighbouring networks at an interconnection point. Sometimes
bilateral arrangements are made between networks, such that the
receiving network remarks some DSCPs to those it uses for roughly
equivalent services. The likelihood that a DSCP will be bleached
or ignored depends on the type of DSCP:<list style="hanging">
<t hangText="Local-use DSCP:">These tend to be used to
implement application-specific network policies, but a
bilateral arrangement to remark certain DSCPs is often applied
to DSCPs in the local-use range simply because it is easier
not to change all of a network's internal configurations when
a new arrangement is made with a neighbour;</t>
<t hangText="Global-use DSCP:">These do not tend to be
honoured across network interconnections more than local-use
DSCPs. However, if two networks decide to honour certain of
each other's DSCPs, the reconfiguration is a little easier if
both of their globally recognised services are already
represented by the relevant global-use DSCPs. <vspace
blankLines="1"/>Note that today a global-use DSCP gives little
more assurance of end-to-end service than a local-use DSCP. In
future the global-use range might give more assurance of
end-to-end service than local-use, but it is unlikely that
either assurance will be high, particularly given the hosts
are included in the end-to-end path.</t>
</list></t>
<t hangText="Not all tunnels:">Diffserv codepoints are often not
propagated to the outer header when a packet is encapsulated by a
tunnel header. DSCPs are propagated to the outer of uniform mode
tunnels, but not pipe mode <xref target="RFC2983"/>, and pipe mode
is fairly common.</t>
<t hangText="ECN hard in some lower layers::">Because this
approach uses both the Diffserv and ECN fields, an AQM wil only
work at a lower layer if both can be supported. If individual
network operators wished to deploy an AQM at a lower layer, they
would usually propagate an IP Diffserv codepoint to the lower
layer, using for example IEEE 802.1p. However, the ECN capability
is harder to propagate down to lower layers because few lower
layers support it.</t>
</list></t>
<t>Pros:<list style="hanging">
<t hangText="Could migrate to e2e:">If all usage of classic ECN
migrates to usage of L4S, the DSCP would become redundant, and the
ECN capability alone could eventually identify L4S packets without
the interconnection problems of Diffserv detailed below, and
without having permanently consumed more than one codepoint in the
IP header. Although the DSCP does not generally function as an
end-to-end identifier (see below), it could be used initially by
individual ISPs to introduce the L4S service for their own locally
generated traffic;</t>
</list></t>
</section>
<section anchor="l4sid_ECN_alone" title="ECN capability alone">
<t>Definition:<list style="empty">
<t>This approach uses ECN capability alone as the L4S identifier.
It is only feasible if classic ECN is not widely deployed. The
specific definition of codepoints would be:<list style="symbols">
<t>Any ECN codepoint other than Not-ECT would signify an
L4S-capable sender, which in turn would indicate that both
transports supported accurate ECN feedback <xref
target="I-D.ietf-tcpm-accecn-reqs"/>;</t>
<t>ECN codepoints would not be used for classic ECN, and the
classic network service would only be used for Not-ECT
packets.</t>
</list>This approach would only be feasible if <list
style="letters">
<t>it was generally agreed that there was little chance of any
classic ECN deployment in any network;</t>
<t>developers of operating systems for user devices would only
enable ECN by default once the TCP stack implemented accurate
ECN <xref target="I-D.ietf-tcpm-accecn-reqs"/> including
requesting it by default;</t>
<t>hosts would only negotiate accurate ECN if they supported
L4S behaviour. In other words, developers of client OSs would
all have to agree not to encourage further deployment of
classic ECN.</t>
</list></t>
</list></t>
<t>Cons:<list style="hanging">
<t hangText="Near-infeasible deployment constraints:">The
constraints for deployment above represent a highly unlikely set
of circumstances, but not completely impossible. If, despite the
above measures, a pair of hosts did negotiate to use classic ECN,
their packets would be classified into the same queue as L4S
traffic, and if they had to compete with a long-running L4S flow
they would get a very small capacity share;</t>
<t hangText="ECN hard in some lower layers:">See the same issue
with "ECT(1) and CE codepoints" (<xref
target="l4sid_ECT1_CE"/>);</t>
<t hangText="Non-L4S service for control packets:">See the same
issue with "ECT(1) and CE codepoints" (<xref
target="l4sid_ECT1_CE"/>).</t>
</list></t>
<t>Pros:<list style="hanging">
<t hangText="Consumes no additional codepoints:">The ECT(1)
codepoint and all spare Diffserv codepoints would remain available
for future use;</t>
<t hangText="Should work e2e:">As with "ECT(1) and CE codepoints"
(<xref target="l4sid_ECT1_CE"/>);</t>
<t hangText="Should work in tunnels:">As with "ECT(1) and CE
codepoints" (<xref target="l4sid_ECT1_CE"/>).</t>
</list></t>
</section>
<section title="Protocol ID">
<t>It has been suggested that a new ID in the IPv4 Protocol field or
the IPv6 Next Header field could identify L4S packets. However this
approach is ruled out by numerous problems:<list style="symbols">
<t>A new protocol ID would need to be paired with the old one for
each transport (TCP, SCTP, UDP, etc.);</t>
<t>In IPv6, there can be a sequence of Next Header fields, and it
would not be obvious which one would be expected to identify a
network service like L4S;</t>
<t>A new protocol ID would rarely provide an end-to-end service,
because It is well-known that new protocol IDs are often blocked
by numerous types of middlebox;</t>
<t>The approach is not a solution for AQMs below the IP layer;</t>
</list></t>
</section>
<section title="Source or destination addressing">
<t>Locally, a network operator could arrange for L4S service to be
applied based on source or destination addressing, e.g. packets from
its own data centre and/or CDN hosts, packets to its business
customers, etc. It could use addressing at any layer, e.g. IP
addresses, MAC addresses, VLAN IDs, etc. Although addressing might be
a useful tactical approach for a single ISP, it would not be a
feasible approach to identify an end-to-end service like L4S. Even for
a single ISP, it would require packet classifiers in buffers to be
dependent on changing topology and address allocation decisions
elsewhere in the network. Therefore this approach is not a feasible
solution.</t>
</section>
<section anchor="l4sid_Als_Summary"
title="Summary: Merits of Alternative Identifiers">
<t><xref target="l4sid_tab_compare"/> provides a very high level
summary of the pros and cons detailed against the schemes described
respectively in <xref target="l4sid_ECN_DSCP"/>, <xref
target="l4sid_ECN_alone"/> and <xref target="l4sid_ECT1_CE"/>, for six
issues that set them apart.</t>
<texttable anchor="l4sid_tab_compare"
title="Comparison of the Merits of Three Alternative Identifiers">
<ttcol>Issue</ttcol>
<ttcol align="center">DSCP + ECN</ttcol>
<ttcol align="center">ECN</ttcol>
<ttcol align="center">ECT(1) + CE</ttcol>
<c/>
<c>initial eventual</c>
<c>initial</c>
<c>initial eventual</c>
<c/>
<c/>
<c/>
<c/>
<c>end-to-end</c>
<c>N . . . ? .</c>
<c>. . Y</c>
<c>. . Y . . Y</c>
<c>tunnels</c>
<c>. O . . O .</c>
<c>. . ?</c>
<c>. . ? . . Y</c>
<c>lower layers</c>
<c>N . . . ? .</c>
<c>. O .</c>
<c>. O . . . ?</c>
<c>codepoints</c>
<c>N . . . . ?</c>
<c>. . Y</c>
<c>N . . . . ?</c>
<c>reordering</c>
<c>. . Y . . Y</c>
<c>. . Y</c>
<c>. O . . . ?</c>
<c>ctrl pkts</c>
<c>. . Y . . Y</c>
<c>. O .</c>
<c>. O . . . ?</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>Note 1</c>
<c/>
<postamble>Note 1: Only feasible if classic ECN is
obsolete.</postamble>
</texttable>
<t>The schemes are scored based on both their capabilities now
('initial') and in the long term ('eventual'). The 'ECN' scheme shares
the 'eventual' scores of the 'ECT(0) + CE' scheme. The scores are one
of 'N, O, Y', meaning 'Poor', 'Ordinary', 'Good' respectively. The
same scores are aligned vertically to aid the eye. A score of "?" in
one of the positions means that this approach might optimisitically
become this good, given sufficient effort. The table is not meant to
be understandable without referring to the text.</t>
</section>
</section>
<section title="Potential Competing Uses for the ECT(1) Codepoint">
<t>The ECT(1) codepoint of the ECN field has already been assigned once
for experimental use <xref target="RFC3540"/>. ECN is probably the only
remaining field in the Internet Protocol that is common to IPv4 and IPv6
and still has potential to work end-to-end, with tunnels and with lower
layers. Therefore, ECT(1) should not be reassigned to a different
experimental use without carefully assessing competing potential uses.
These fall into the following categories:</t>
<section anchor="l4sid_competing_integrity"
title="Integrity of Congestion Feedback">
<t>Receiving hosts can fool a sender into downloading faster by
suppressing feedback of ECN marks (or loss if retransmissions are not
necessary or available otherwise). <xref target="RFC3540"/> proposes
that a TCP sender could set either ECT(0) or ECT(1) in each packet of
a flow and remember the pattern, termed the ECN nonce. If any packet
is lost or congestion marked, the receiver will miss that bit of the
sequence. An ECN Nonce receiver has to feed back the least significant
bit of the sum, so it cannot suppress feedback of a loss or mark
without a 50-50 chance of guessing the sum incorrectly.</t>
<t>As far as is known, the ECN Nonce has never been deployed, and it
was only implemented for a couple of testbed evaluations. It would be
nearly impossible to deploy now, because any misbehaving receiver can
simply opt-out, which would be unremarkable given all receivers
currently opt-out.</t>
<t>Other ways to protect TCP feedback integrity have since been
developed that do not consume any extra codepoints. For instance:<list
style="symbols">
<t>the sender can test the integrity of the receiver's feedback by
occasionally setting the IP-ECN field to a value normally only set
by the network. Then it can test whether the receiver's feedback
faithfully reports what it expects <xref
target="I-D.moncaster-tcpm-rcv-cheat"/>. This works for loss and
it will work for the accurate ECN feedback <xref
target="I-D.ietf-tcpm-accecn-reqs"/> intended for L4S;</t>
<t>A network can enforce a congestion response to its ECN markings
(or packet losses) by auditing congestion exposure (ConEx) <xref
target="I-D.ietf-conex-abstract-mech"/>. Whether the receiver or a
downstream network is suppressing congestion feedback or the
sender is unresponsive to the feedback, or both, ConEx audit can
neutralise any advantage that any of these three parties would
otherwise gain.</t>
</list></t>
<t>ECN in RTP <xref target="RFC6679"/> is defined so that the receiver
can ask the sender to send all ECT(0); all ECT(1); or both randomly.
It recommends that the receiver asks for ECT(0), which is the default.
The sender can choose to ignore the receiver's request. A rather
complex but optional nonce mechaism was included in early drafts of
RFC 6679, but it was replaced with a statement that a nonce mechanism
is not specified, explaining that misbehaving receivers could opt-out
anyway. RFC 6679 as published gives no rationale for why ECT(1) or
'random' might be needed, but it warns that 'random' would make header
compression highly inefficient. The possibility of using ECT(1) may
have been left in the RFC to allow a nonce mechanism to be added
later.</t>
<t>Therefore, it seems unlikely that anyone has implemented the
optional use of ECT(1) for RTP, it even if they have, it seems even
less likely that any deployment actually uses it. However these
assumptions will need to be verified.</t>
</section>
<section title="Notification of Less Severe Congestion than CE">
<t>Various researchers have proposed to use ECT(1) as a less severe
congestion notification than CE, particularly to enable flows to fill
available capacity more quickly after an idle period, when another
flow departs or when a flow starts, e.g. VCP <xref target="VCP"/>,
Queue View (QV) <xref target="QV"/> {ToDo: Jonathan Morton's ELR if
relevant once the promised write-up appears}.</t>
<t>Before assigning ECT(1) as an identifer for L4S, we must carefully
consider whether it might be better to hold ECT(1) in reserve for
future standardisation of rapid flow acceleration, which is an
important and enduring problem <xref target="RFC6077"/>.</t>
<t>Pre-Congestion Notification (PCN) is another scheme that assigns
alternative semantics to the ECN field. It uses ECT(1) to signify a
less severe level of pre-congestion notification than CE <xref
target="RFC6660"/>. However, the ECN field only takes on the PCN
semantics if packets carry a Diffserv codepoint defined to indicate
PCN marking within a controlled environment. PCN is required to be
applied solely to the outer header of a tunnel across the controlled
region in order not to interfere with any end-to-end use of the ECN
field. Therefore a PCN region on the path would not interfere with any
of the L4S service identifiers proposed in <xref
target="l4sid_Alts"/>.</t>
</section>
</section>
<!-- <section title="Change Log (to be Deleted before Publication)">
<t>A detailed version history can be accessed at
<http://datatracker.ietf.org/doc/draft-briscoe-aqm-ecn-roadmap/history/></t>
<t><list style="hanging">
<t hangText="From briscoe-...-00 to briscoe-...-01:">Technical
changes:<list style="symbols">
<t/>
</list>Editorial changes:<list style="symbols">
<t/>
</list></t>
</list></t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 16:57:30 |