One document matched: draft-briscoe-tsvwg-ecn-l4s-id-02.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">
<?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-02"
ipr="trust200902">
<!-- 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>Nokia Bell Labs</organization>
<address>
<postal>
<street/>
<city>Antwerp</city>
<country>Belgium</country>
</postal>
<email>koen.de_schepper@nokia.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>Nokia Bell Labs</organization>
<address>
<postal>
<street/>
<city>Antwerp</city>
<country>Belgium</country>
</postal>
<email>ing-jyh.tsang@nokia.com</email>
</address>
</author>
<date day="31" month="October" year="2016"/>
<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, for packets
carrying the L4S identifier, the network applies marking 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 throughput 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 L4S marking 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.ietf-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. Note that DCTCP will still not be safe to deploy on
the Internet until it satisfies the 'Safety Additions' listed in
Appendix A of <xref
target="I-D.briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem"/>.</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, finance apps, remote desktop and
cloud-based applications. 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.</t>
<t>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"/>, are easier to configure, because they define the
queuing threshold in time not bytes, so it is invariant for different
link rates. However, no matter how good the AQM, the sawtoothing rate
of TCP will either cause queuing delay to vary or cause the link to be
under-utilized. Even with a perfectly tuned AQM, the additional
queuing delay will be of the same order as the underlying
speed-of-light delay across the network. Flow-queuing can isolate one
flow from another, but it cannot isolate a TCP flow from the delay
variations it inflicts on itself, and it has other problems - it
overrides the flow rate decisions of variable rate video applications,
it does not recognise the flows within IPSec VPN tunnels and it is
relatively expensive to implement.</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.ietf-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.ietf-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", "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 (e.g.
TCP Cubic, Compound, SCTP, etc).</t>
<t
hangText="Low-Latency, Low-Loss and Scalable (L4S) service:">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. Therefore it depends on <xref
target="I-D.black-tsvwg-ecn-experimentation"/>, which proposes
to:<list style="symbols">
<t>update the ECN proposed standard <xref target="RFC3168"/> (in
certain specified cases including the present document) to relax
the requirement that an ECN mark must be equivalent to a drop,
both when applied by the network, and when responded to by the
sender;</t>
<t>obsolete the experimental ECN nonce <xref target="RFC3540"/>
(see <xref target="l4sid_competing_integrity"/> for
rationale);</t>
<t>make consequent updates to the following proposed standard RFCs
to reflect the above two bullets:<list style="symbols">
<t>ECN for RTP <xref target="RFC6679"/>;</t>
<t>the congestion control specifications of various DCCP CCIDs
<xref target="RFC4341"/>, <xref target="RFC4342"/>, <xref
target="RFC5622"/>.</t>
</list></t>
</list></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 and transport
agnostic;</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>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>
<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 against
the above requirements. On the basis of this analysis, the "ECT(1) and
CE codepoints" is the best compromise. Therefore this scheme is
defined in detail in the following section (<xref
target="l4sid_identification"/>), while <xref target="l4sid_Alts"/>
has been left to document the rationale for this decision.</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 both network and
host behaviour: it identifies the marking treatment that network nodes
are expected to apply to L4S packets, and it identifies packets that
have been sent from hosts that are expected to comply with a broad
type of behaviour.</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_transport_aware"/> describes a possible
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 mark the ECN
field as CE for an increasing proportion of packets, otherwise
forwarding packets unchanged as ECT(1). The L4S marking treatment is
defined in <xref target="l4sid_Semantics"/>. 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>
<!--KDS:Do we
want to propose this? In the paper I proposed to limit the probabilities
to a max value, and to use delay to control overload (until tail drop).
BB: I've allowed what you do and made it sound compatible with RFC3168
-->
<t>The L4S treatment is the default for ECT(1) packets in all Diffserv
Classes <xref target="RFC4774"/>.</t>
<t>For backward compatibility in uncontrolled environments, 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_transport_req"
title="Pre-Requisite Transport Layer Behaviour">
<t>For a host to send packets with the L4S identifier (ECT(1)), it
SHOULD implement a congestion control behaviour that ensures the flow
rate is inversely proportional to the proportion of bytes in packets
marked with the CE codepoint. This is termed a scalable congestion
control, because the number of control signals (ECN marks) per round
trip remains roughly constant for any flow rate. As with all transport
behaviours, a detailed specification will need to be defined for each
type of transport or application, including the timescale over which
the proportionality is averaged, and control of burstiness. The
inverse proportionality requirement above is worded as a 'SHOULD'
rather than a 'MUST' to allow reasonable flexibility when defining
these specifications.</t>
<t>Data Center TCP (DCTCP <xref target="I-D.ietf-tcpm-dctcp"/>) is an
example of a scalable congestion control.</t>
<!--For example, the timescale over which this rough proportionality applies will depend on the type of application, ranging from per packet adjustment through smooth adjustment of encoding
over perhaps tens of seconds. Low bit-rate flows might even respond at the timescale of self-admission control solely at the start of each flow. As with any congestion control, the sender
SHOULD also avoid excessive bursts, but this is particularly important with the L4S service.-->
<t>Each sender in a session can use a scalable congestion control
independently of the congestion control used by the receiver(s) when
they send data. Therefore theoretically there might be ECT(1) packets
in one direction and ECT(0) in the other.</t>
<t>In general, a scalable congestion control needs feedback of the
extent of CE marking on the forward path. Due to the history of TCP
development, when ECN was added it reported no more than one CE mark
per round trip. Some transport protocols derived from TCP mimick this
behaviour while others report the extent of TCP marking. This means
that some transport protocols will need to be updated as a
pre-requisite for scalable congestion control. The position for a few
well-known transport protocols is given below.<list style="hanging">
<t hangText="TCP:">Support for accurate ECN feedback (AccECN <xref
target="I-D.ietf-tcpm-accurate-ecn"/>) by both ends is a
pre-requisite for scalable congestion control. However, the
reverse does not apply. So even if both ends support AccECN,
either of the two ends can choose not to use a scalable congestion
control, whatever the other end's choice. Nonetheless, the
presence of ECT(1) in the IP headers even in one direction of a
TCP connection will imply that both ends support AccECN.</t>
<t hangText="SCTP:">An ECN feedback protocol such as that
specified in <xref target="I-D.stewart-tsvwg-sctpecn"/> would be a
pre-requisite for scalable congestion control. That draft would
update the ECN feedback protocol sketched out in Appendix A of the
standards track specification of SCTP <xref target="RFC4960"/> by
adding a field to report the number of CE marks.</t>
<t hangText="RTP over UDP:">A pre-requisite for scalable
congestion control is for both (all) ends of one media-level hop
to signal ECN support using the ecn-capable-rtp attribute <xref
target="RFC6679"/>. However, the reverse does not apply, so each
end of a media-level hop can independently choose not to use a
scalable congestion control, even if both ends support ECN.
Nonetheless, the presence of ECT(1) implies that both (all) ends
of that hop support ECN.</t>
<t hangText="DCCP:">The ACK vector in DCCP <xref
target="RFC4340"/> is already sufficient to report the extent of
CE marking as needed by a scalable congestion control.</t>
</list></t>
</section>
<section anchor="l4sid_identification_transport_aware"
title="L4S Packet Identification by Network Nodes with Transport-Layer Awareness">
<!--This section doesn't fit very well here. It would be better as an Appendix, then it would need the following introductory para:
Section 2.3 recognizes that CE packets might have originally been L4S or Classic. It argues that this ambiguity is not serious, and therefore, for simplicity,
it recommends that a packet classifer in the network "SHOULD" classify all CE packets as L4S. Even though it is probably unnecessary to resolve the ambiguity,
the following text provides a way to do so using per-flow processing in the network. Per-flow processing has other detrimental side-effects, so this text is
controversial, but worth recording, particularly for those cases where per-flow processing is already being used for other purposes.-->
<t>To implement the L4S treatment, a network node does not need to
identify transport-layer flows. Nonetheless, if an implementer is
willing to identify transport-layer flows at a network node, and if
the most recent ECT packet in the same flow was ECT(0), the node MAY
classify CE packets for classic ECN <xref target="RFC3168"/>
treatment. In all other cases, a network node MUST classify CE packets
for L4S treatment. Examples of such other cases are: i) if no ECT
packets have yet been identified in a flow; ii) if it is not desirable
for a network node to identify transport-layer flows; or iii) if the
most recent ECT packet in a flow was ECT(1).</t>
<!--KDS: I'm not sure if looking at the most recent ECT packet is a good strategy.
It makes it very difficult to do deterministic measurements of the delay in the
classic to L4S paths (as it depends on how previous packets are marked). I think
always classifying CE would also be an advantage... To be further thought of...
BB: Added visible ToDo
-->
<t>If an implementer uses flow-awareness to classify CE packets, to
determine whether the flow is using ECT(0) or ECT(1) it only uses the
most recent ECT packet of a flow {ToDo: this advice will need to be
verified experimentally}. This is 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. A host ought to be able to detect such
a change from a change in RTT variation.</t>
</section>
<section anchor="l4sid_Semantics"
title="The Meaning of CE Relative to Drop">
<t>The likelihood that an AQM drops a Not-ECT Classic packet (p_C)
MUST be roughly proportional to the square of the likelihood that it
would have marked it if it had been an L4S packet (p_L). That is<list
style="empty">
<t>p_C ~= (p_L / k)^2</t>
</list>The constant of proportionality (k) does not have to be
standardised for interoperability, but a value of 2 is
RECOMMENDED.</t>
<!--KDS: I have to use 2 in PI2, as DCTCP gets twice the throughput with value 1.
Also with all our demos in dualQ we also use 2 to give classic enough throughput.
BB: Done-->
<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 example implementations in appendices.</t>
<t>The term 'likelihood' is used above to allow for marking and
dropping to be either probabilistic or deterministic. The example AQMs
in <xref target="I-D.briscoe-aqm-dualq-coupled"/> drop and mark
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 an ECT(0) packet under the same conditions that it would
have dropped a Not-ECT packet.</t>
<!--KDS: replace "a Not-ECT packet"
by "a packet", as any drop should be classic, and also ECT(0),(1) or CE packets can be dropped
BB: But that's not the intended meaning. Yes, a packet with any ECN field can be dropped, but this rule is just about what /would/ have been done
/if/ the ECN field had been one specific value (Not-ECT).
-->
</section>
</section>
<section anchor="l4sid_IANA" title="IANA Considerations">
<t>This specification contains no IANA considerations.</t>
<!--{ToDo: If this specification becomes an 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.}-->
</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 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 here
are solely those of the authors.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3168'?>
<?rfc include='reference.RFC.4774'?>
<?rfc include='reference.RFC.6679'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2474'?>
<?rfc include='reference.RFC.2309'?>
<?rfc include='reference.RFC.3540'?>
<?rfc include='reference.RFC.2983'?>
<?rfc include='reference.RFC.3246'?>
<?rfc include='reference.RFC.3649'?>
<?rfc include='reference.RFC.4340'?>
<?rfc include='reference.RFC.4341'?>
<?rfc include='reference.RFC.4342'?>
<?rfc include='reference.RFC.5622'?>
<?rfc include='reference.RFC.4960'?>
<?rfc include='reference.RFC.5562'?>
<?rfc include='reference.RFC.6660'?>
<?rfc include='reference.RFC.6077'?>
<?rfc include='reference.RFC.7560'?>
<?rfc include='reference.I-D.ietf-tcpm-accurate-ecn'?>
<?rfc include='reference.I-D.ietf-aqm-pie'?>
<?rfc include='reference.I-D.ietf-aqm-fq-codel'?>
<?rfc include='reference.I-D.ietf-tsvwg-ecn-encap-guidelines'?>
<?rfc include='reference.I-D.moncaster-tcpm-rcv-cheat'?>
<?rfc include='reference.RFC.7713'?>
<?rfc include='reference.I-D.briscoe-aqm-dualq-coupled'?>
<?rfc include='reference.I-D.stewart-tsvwg-sctpecn'?>
<?rfc include='reference.I-D.briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem'?>
<?rfc include='reference.I-D.black-tsvwg-ecn-experimentation'?>
<?rfc include='reference.I-D.bagnulo-tswg-generalized-ecn'?>
<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>
<?rfc include='reference.I-D.ietf-tcpm-dctcp'?>
<?rfc include='reference.I-D.ietf-tcpm-cubic'?>
<?rfc include='reference.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="https://riteproject.files.wordpress.com/2015/12/rite-deliverable-2-3.pdf">
<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="D2.3; Appendix C.2"/>
<format target="https://riteproject.files.wordpress.com/2015/12/rite-deliverable-2-3.pdf"
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;</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
ought not to 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, 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. To address this problem, <xref
target="I-D.bagnulo-tswg-generalized-ecn"/> proposes an experiment
in which all TCP control packets and retransmissions are
ECN-capable.</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;</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 above, 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 above), 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;</t>
<t>ECN codepoints would not be used for classic <xref
target="RFC3168"/> 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 <xref target="RFC3168"/> ECN deployment in any network
nodes;</t>
<t>it was generally agreed that there was little chance of any
client devices being deployed with classic <xref
target="RFC3168"/> TCP-ECN on by default (note that classic
TCP-ECN is already on-by-default on many servers);</t>
<t>for TCP connections, developers of client OSs would all
have to agree not to encourage further deployment of classic
ECN. Specifically, at the start of a TCP connection classic
ECN could be disabled during negotation of the ECN
capability:<list style="symbols">
<t>an L4S-capable host would have to disable ECN if the
corresponding host did not support accurate ECN feedback
<xref target="RFC7560"/>, which is a prerequisite for the
L4S service;</t>
<t>developers of operating systems for user devices would
only enable ECN by default for TCP once the stack
implemented L4S and accurate ECN feedback <xref
target="RFC7560"/> including requesting accurate ECN
feedback by default.</t>
</list></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, but
not completely impossible, set of circumstances. 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(1) + 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 summarises the
text and is not meant to be understandable without having read 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 as the ECN nonce <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 of losses if retransmissions are
not necessary or available otherwise). <xref target="RFC3540"/>
proposes that a TCP sender could set either of ECT(0) or ECT(1) in
each packet of a flow and remember the sequence it had set, 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 in the base IP
header. 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="RFC7560"/> 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="RFC7713"/>. 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. 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: consider Jonathan Morton's
Explicit Load Regulation (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:46:51 |