rfc9331.original.xml   rfc9331.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<?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 xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie
tf-tsvwg-ecn-l4s-id-29" ipr="trust200902" obsoletes="" updates="" submissionType
="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="tr
ue" version="3">
<!-- xml2rfc v2v3 conversion 3.14.1 -->
<!-- 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 ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" exp" consensus="true" docName="draft-ietf-tsvwg-ecn-l4s-id-29" number="9331" ipr ="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth= "4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="ECN Protocol for L4S">
if the The Explicit Congestion Notification (ECN) Protocol for
full title is longer than 39 characters --> Low Latency, Low Loss, and Scalable Throughput (L4S)</title>
<seriesInfo name="RFC" value="9331"/>
<title abbrev="L4S ECN Protocol for V Low Queuing Delay">Explicit
Congestion Notification (ECN) Protocol for Very Low Queuing Delay
(L4S)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-l4s-id-29"/>
<author fullname="Koen De Schepper" initials="K." surname="De Schepper"> <author fullname="Koen De Schepper" initials="K." surname="De Schepper">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Antwerp</city> <city>Antwerp</city>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<email>koen.de_schepper@nokia.com</email> <email>koen.de_schepper@nokia.com</email>
<uri>https://www.bell-labs.com/about/researcher-profiles/koende_schepper /</uri> <uri>https://www.bell-labs.com/about/researcher-profiles/koende_schepper /</uri>
</address> </address>
</author> </author>
<author fullname="Bob Briscoe" initials="B." role="editor" surname="Briscoe" > <author fullname="Bob Briscoe" initials="B." surname="Briscoe" role="editor" >
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>UK</country> <country>United Kingdom</country>
</postal> </postal>
<email>ietf@bobbriscoe.net</email> <email>ietf@bobbriscoe.net</email>
<uri>https://bobbriscoe.net/</uri> <uri>https://bobbriscoe.net/</uri>
</address> </address>
</author> </author>
<!-- <date year="2023" month="January" />
<author fullname="Olga Bondarenko" initials="O." surname="Bondarenko"> <area>tsv</area>
<organization>Simula Research Lab</organization> <workgroup>tsvwg</workgroup>
<keyword>Performance</keyword>
<address> <keyword>Queuing Delay</keyword>
<postal> <keyword>One Way Delay</keyword>
<street/> <keyword>Round-Trip Time</keyword>
<keyword>RTT</keyword>
<city>Lysaker</city> <keyword>Jitter</keyword>
<keyword>Congestion Control</keyword>
<country>Norway</country> <keyword>Congestion Avoidance</keyword>
</postal> <keyword>Quality of Service</keyword>
<keyword>QoS</keyword>
<email>olgabnd@gmail.com</email> <keyword>Quality of Experience</keyword>
<keyword>QoE</keyword>
<uri>https://www.simula.no/people/olgabo</uri> <keyword>Active Queue Management</keyword>
</address> <keyword>AQM</keyword>
</author> <keyword>Explicit Congestion Notification</keyword>
<keyword>ECN</keyword>
<!-- <keyword>Burstiness</keyword>
<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 year=""/>
<area>Transport</area>
<workgroup>Transport Services (tsv)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>I-D</keyword>
<abstract> <abstract>
<t>This specification defines the protocol to be used for a new network <t>This specification defines the protocol to be used for a new network
service called low latency, low loss and scalable throughput (L4S). L4S service called Low Latency, Low Loss, and Scalable throughput (L4S). L4S
uses an Explicit Congestion Notification (ECN) scheme at the IP layer uses an Explicit Congestion Notification (ECN) scheme at the IP layer
that is similar to the original (or 'Classic') ECN approach, except as that is similar to the original (or 'Classic') ECN approach, except as
specified within. L4S uses 'scalable' congestion control, which induces specified within. L4S uses 'Scalable' congestion control, which induces
much more frequent control signals from the network and it responds to much more frequent control signals from the network, and it responds to
them with much more fine-grained adjustments, so that very low them with much more fine-grained adjustments so that very low
(typically sub-millisecond on average) and consistently low queuing (typically sub-millisecond on average) and consistently low queuing
delay becomes possible for L4S traffic without compromising link delay becomes possible for L4S traffic without compromising link
utilization. Thus even capacity-seeking (TCP-like) traffic can have high utilization. Thus, even capacity-seeking (TCP-like) traffic can have high
bandwidth and very low delay at the same time, even during periods of bandwidth and very low delay at the same time, even during periods of
high traffic load.</t> high traffic load.</t>
<t>The L4S identifier defined in this document distinguishes L4S from <t>The L4S identifier defined in this document distinguishes L4S from
'Classic' (e.g. TCP-Reno-friendly) traffic. Then, network 'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network
bottlenecks can be incrementally modified to distinguish and isolate bottlenecks can be incrementally modified to distinguish and isolate
existing traffic that still follows the Classic behaviour, to prevent it existing traffic that still follows the Classic behaviour, to prevent it
degrading the low queuing delay and low loss of L4S traffic. This from degrading the low queuing delay and low loss of L4S traffic. This
experimental track specification defines the rules that L4S transports Experimental specification defines the rules that L4S transports
and network elements need to follow, with the intention that L4S flows and network elements need to follow, with the intention that L4S flows
neither harm each other's performance nor that of Classic traffic. It neither harm each other's performance nor that of Classic traffic. It
also suggests open questions to be investigated during experimentation. also suggests open questions to be investigated during experimentation.
Examples of new active queue management (AQM) marking algorithms and Examples of new Active Queue Management (AQM) marking algorithms and
examples of new transports (whether TCP-like or real-time) are specified new transports (whether TCP-like or real time) are specified
separately.</t> separately.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="l4sid_intro" numbered="true" toc="default"> <section anchor="l4sid_intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This experimental track specification defines the protocol to be used <t>This Experimental specification defines the protocol to be used
for a new network service called low latency, low loss and scalable for a new network service called Low Latency, Low Loss, and Scalable
throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) throughput (L4S). L4S uses an Explicit Congestion Notification (ECN)
scheme at the IP layer with the same set of codepoint transitions as the scheme at the IP layer with the same set of codepoint transitions as the
original (or 'Classic') Explicit Congestion Notification (ECN <xref target ="RFC3168" format="default"/>). RFC 3168 required an ECN mark to be equivalent original (or 'Classic') ECN <xref target="RFC3168" format="default"/>. <xr ef target="RFC3168"/> requires an ECN mark to be equivalent
to a drop, both when applied in the network and when responded to by a to a drop, both when applied in the network and when responded to by a
transport. Unlike Classic ECN marking: i) the network applies L4S transport. Unlike Classic ECN marking, i) the network applies L4S
marking more immediately and more frequently than drop; and ii) the marking more immediately and more frequently than drop and ii) the
transport response to each mark is reduced and smoothed relative to that transport response to each mark is reduced and smoothed relative to that
for drop. The two changes counterbalance each other so that the for drop. The two changes counterbalance each other so that the
throughput of an L4S flow will be roughly the same as a comparable throughput of an L4S flow will be roughly the same as a comparable
non-L4S flow under the same conditions. Nonetheless, the much more non-L4S flow under the same conditions. Nonetheless, the much more
frequent ECN control signals and the finer responses to these signals frequent ECN control signals and the finer responses to these signals
result in very low queuing delay without compromising link utilization, result in very low queuing delay without compromising link utilization,
and this low delay can be maintained during high load. For instance, and this low delay can be maintained during high load. For instance,
queuing delay under heavy and highly varying load with the example queuing delay under heavy and highly varying load with the example
DCTCP/DualQ solution described below on a DSL or Ethernet link is DCTCP/DualQ solution described below on a DSL or Ethernet link is
sub-millisecond on average and roughly 1 to 2 milliseconds at the 99th sub-millisecond on average and roughly 1 to 2 milliseconds at the 99th
percentile without losing link utilization <xref target="DualPI2Linux" for percentile without losing link utilization <xref target="L4Seval22" format
mat="default"/>, <xref target="DCttH19" format="default"/>. Note that the queuin ="default"/> <xref target="DualPI2Linux" format="default"/>.
g Note that the queuing
delay while waiting to acquire a shared medium such as wireless has to delay while waiting to acquire a shared medium such as wireless has to
be added to the above. It is a different issue that needs to be be added to the above. It is a different issue that needs to be
addressed, but separately (see section 6.3 of the L4S addressed, but separately (see Section <xref target="RFC9330" section="6.3
architecture <xref target="I-D.ietf-tsvwg-l4s-arch" format="default"/>).</ "
t> sectionFormat="bare"/> of the L4S
<t>L4S relies on 'scalable' congestion controls for these delay architecture <xref target="RFC9330" format="default"/>).</t>
<t>L4S relies on 'Scalable' congestion controls for these delay
properties and for preserving low delay as flow rate scales, hence the properties and for preserving low delay as flow rate scales, hence the
name. The congestion control used in Data Center TCP (DCTCP) is an name. The congestion control used in Data Center TCP (DCTCP) is an
example of a scalable congestion control, but DCTCP is applicable solely example of a Scalable congestion control, but DCTCP is applicable solely
to controlled environments like data centres <xref target="RFC8257" format to controlled environments like data centres <xref target="RFC8257" format
="default"/>, because it is too aggressive to co-exist with ="default"/>, because it is too aggressive to coexist with
existing TCP-Reno-friendly traffic. The DualQ Coupled AQM, which is existing TCP-Reno-friendly traffic. Dual-Queue Coupled AQM, which is
defined in a complementary experimental specification <xref target="I-D.ie defined in a complementary Experimental specification <xref target="RFC933
tf-tsvwg-aqm-dualq-coupled" format="default"/>, is an AQM framework that 2" format="default"/>, is an AQM framework that
enables scalable congestion controls derived from DCTCP to co-exist with enables Scalable congestion controls derived from DCTCP to coexist with
existing traffic, each getting roughly the same flow rate when they existing traffic, each getting roughly the same flow rate when they
compete under similar conditions. Note that a scalable congestion compete under similar conditions. Note that a Scalable congestion
control is still not safe to deploy on the Internet unless it satisfies control is still not safe to deploy on the Internet unless it satisfies
the requirements listed in <xref target="l4sid_transport_req" format="defa ult"/>.</t> the requirements listed in <xref target="l4sid_transport_req" format="defa ult"/>.</t>
<t>L4S is not only for elastic (TCP-like) traffic - there are scalable
congestion controls for real-time media, such as the L4S variant <xref tar <t>L4S is not only for elastic (TCP-like) traffic -- there are Scalable
get="SCReAM-L4S" format="default"/> of the SCReAM <xref target="RFC8298" format= congestion controls for real-time media, such as the L4S variant <xref tar
"default"/> get="SCReAM-L4S" format="default"/> of the SCReAM <xref target="RFC8298" format=
real-time media congestion avoidance technique (RMCAT). The factor that "default"/> RTP Media Congestion Avoidance Techniques (RMCAT). The factor that
distinguishes L4S from Classic traffic is its behaviour in response to distinguishes L4S from Classic traffic is its behaviour in response to
congestion. The transport wire protocol, e.g. TCP, QUIC, SCTP, congestion.
DCCP, RTP/RTCP, is orthogonal (and therefore not suitable for The transport wire protocol, e.g., TCP, QUIC, the Stream Control Transmiss
ion Protocol (SCTP),
the Datagram Congestion Control Protocol (DCCP), or RTP/RTCP, is orthogona
l (and therefore not suitable for
distinguishing L4S from Classic packets).</t> distinguishing L4S from Classic packets).</t>
<t>The L4S identifier defined in this document is the key piece that <t>The L4S identifier defined in this document is the key piece that
distinguishes L4S from 'Classic' (e.g. Reno-friendly) traffic. distinguishes L4S from 'Classic' (e.g., Reno-friendly) traffic.
Then, network bottlenecks can be incrementally modified to distinguish Then, network bottlenecks can be incrementally modified to distinguish
and isolate existing Classic traffic from L4S traffic, to prevent the and isolate existing Classic traffic from L4S traffic, to prevent the
former from degrading the very low queuing delay and loss of the new former from degrading the very low queuing delay and loss of the new
scalable transports, without harming Classic performance at these Scalable transports, without harming Classic performance at these
bottlenecks. Although both sender and network deployment are required bottlenecks. Although both sender and network deployment are required
before any benefit, initial implementations of the separate parts of the before any benefit, initial implementations of the separate parts of the
system have been motivated by the potential performance benefits.</t> system have been motivated by the potential performance benefits.</t>
<section anchor="l4sid_problem" numbered="true" toc="default"> <section anchor="l4sid_problem" numbered="true" toc="default">
<name>Latency, Loss and Scaling Problems</name> <name>Latency, Loss, and Scaling Problems</name>
<t>Latency is becoming the critical performance factor for many <t>Latency is becoming the critical performance factor for many
(most?) Internet applications, e.g. interactive web, web (perhaps most) Internet applications, e.g., interactive web, web
services, voice, conversational video, interactive video, interactive services, voice, conversational video, interactive video, interactive
remote presence, instant messaging, online gaming, remote desktop, remote presence, instant messaging, online gaming, remote desktop,
cloud-based applications &amp; services, and remote control of cloud-based applications &amp; services, and remote control of
machinery and industrial processes. In many parts of the world, machinery and industrial processes. In many parts of the world,
further increases in access network bit rate offer diminishing returns further increases in access network bitrate offer diminishing returns
<xref target="Dukkipati06" format="default"/>, whereas latency is still a multi-faceted <xref target="Dukkipati06" format="default"/>, whereas latency is still a multi-faceted
problem. As a result, much has been done to reduce propagation time by problem. As a result, much has been done to reduce propagation time by
placing caches or servers closer to users. However, queuing remains a placing caches or servers closer to users. However, queuing remains a
major, albeit intermittent, component of latency.</t> major, albeit intermittent, component of latency.</t>
<t>The Diffserv architecture provides Expedited Forwarding <xref target= "RFC3246" format="default"/>, so that low latency traffic can jump the queue of <t>The Diffserv architecture provides Expedited Forwarding (EF) <xref ta rget="RFC3246" format="default"/> so that low-latency traffic can jump the queue of
other traffic. If growth in latency-sensitive applications continues, other traffic. If growth in latency-sensitive applications continues,
periods with solely latency-sensitive traffic will become increasingly periods with solely latency-sensitive traffic will become increasingly
common on links where traffic aggregation is low. During these common on links where traffic aggregation is low. During these
periods, if all the traffic were marked for the same treatment, periods, if all the traffic were marked for the same treatment,
Diffserv would make no difference. The links with low aggregation also Diffserv would make no difference. The links with low aggregation also
tend to become the path bottleneck under load, for instance, the tend to become the path bottleneck under load, for instance, the
access links dedicated to individual sites (homes, small enterprises access links dedicated to individual sites (homes, small enterprises,
or mobile devices). So, instead of differentiation, it becomes or mobile devices). So, instead of differentiation, it becomes
imperative to remove the underlying causes of any unnecessary imperative to remove the underlying causes of any unnecessary
delay.</t> delay.</t>
<t>The Bufferbloat project has shown that excessively-large buffering <t>The Bufferbloat project has shown that excessively large buffering
('bufferbloat') has been introducing significantly more delay than the ('bufferbloat') has been introducing significantly more delay than the
underlying propagation time <xref target="Bufferbloat" format="default"/ >. These delays underlying propagation time <xref target="Bufferbloat" format="default"/ >. These delays
appear only intermittently -- only when a capacity-seeking appear only intermittently -- only when a capacity-seeking
(e.g. TCP) flow is long enough for the queue to fill the buffer, (e.g., TCP) flow is long enough for the queue to fill the buffer,
causing every packet in other flows sharing the buffer to have to work causing every packet in other flows sharing the buffer to have to work
its way through the queue.</t> its way through the queue.</t>
<t>Active queue management (AQM) was originally developed to solve
<t>AQM was originally developed to solve
this problem (and others). Unlike Diffserv, which gives low latency to this problem (and others). Unlike Diffserv, which gives low latency to
some traffic at the expense of others, AQM controls latency for <em>all< /em> traffic in a class. In general, AQM methods some traffic at the expense of others, AQM controls latency for <em>all< /em> traffic in a class. In general, AQM methods
introduce an increasing level of discard from the buffer, the longer introduce an increasing level of discard from the buffer, the longer
the queue persists above a shallow threshold. This gives sufficient the queue persists above a shallow threshold.
signals to capacity-seeking (aka. greedy) flows to keep the This gives sufficient
buffer empty for its intended purpose: absorbing bursts. However, signals to capacity-seeking (a.k.a. greedy) flows to keep the
RED <xref target="RFC2309" format="default"/> and other algorithms from buffer empty for its intended purpose: absorbing bursts.
the 1990s However, Random Early Detection (RED) and other algorithms from the 1990s
were sensitive to their configuration and hard to set correctly. So, were sensitive to their configuration and hard to set correctly <xref ta
rget="RFC7567" format="default"/>. So
this form of AQM was not widely deployed.</t> this form of AQM was not widely deployed.</t>
<t>More recent state-of-the-art AQM methods, such <t>More recent state-of-the-art AQM methods, such
as FQ-CoDel <xref target="RFC8290" format="default"/>, PIE <xref target= "RFC8033" format="default"/> or Adaptive RED <xref target="ARED01" format="defau lt"/>, are as Flow Queue CoDel <xref target="RFC8290" format="default"/>, Proportio nal Integral controller Enhanced (PIE) <xref target="RFC8033" format="default"/> , or Adaptive RED <xref target="ARED01" format="default"/>, are
easier to configure, because they define the queuing threshold in time easier to configure, because they define the queuing threshold in time
not bytes, so configuration is invariant whatever the link rate. not bytes, so configuration is invariant whatever the link rate.
However, the sawtoothing window of a Classic congestion control However, the sawtoothing window of a Classic congestion control
creates a dilemma for the operator: i) either configure a shallow AQM creates a dilemma for the operator: either i) configure a shallow AQM
operating point, so the tips of the sawteeth cause minimal queue operating point so the tips of the sawteeth cause minimal queue
delay, but the troughs underutilize the link; or ii) configure the delay, but then the troughs underutilize the link, or ii) configure the
operating point deeper into the buffer, so the troughs utilize the operating point deeper into the buffer so the troughs utilize the
link better, but then the tips cause more delay variation. Even with a link better, but then the tips cause more delay variation. Even with a
perfectly tuned AQM, the additional queuing delay at the tips of the perfectly tuned AQM, the additional queuing delay at the tips of the
sawteeth will be of the same order as the underlying base round trip sawteeth will be of the same order as the underlying base round-trip
time (RTT), thereby roughly doubling the total round-trip time.</t> time (RTT), thereby roughly doubling the total RTT.</t>
<t>If a sender's own behaviour is introducing queuing delay variation, <t>If a sender's own behaviour is introducing queuing delay variation,
no AQM in the network can 'un-vary' the delay without significantly no AQM in the network can 'un-vary' the delay without significantly
compromising link utilization. Even flow-queuing (e.g. <xref target="RFC 8290" format="default"/>), which isolates one flow from another, cannot compromising link utilization. Even flow queuing (e.g., <xref target="RF C8290" format="default"/>), which isolates one flow from another, cannot
isolate a flow from the delay variations it inflicts on itself. isolate a flow from the delay variations it inflicts on itself.
Therefore, those applications that need to seek out high bandwidth but Therefore, those applications that need to seek out high bandwidth but
also need low latency will have to migrate to scalable congestion also need low latency will have to migrate to Scalable congestion
control, which uses much smaller sawtooth variations.</t> control, which uses much smaller sawtooth variations.</t>
<t>Altering host behaviour is not enough on its own though. Even if <t>Altering host behaviour is not enough on its own though. Even if
hosts adopt low latency scalable congestion controls, they need to be hosts adopt low-latency Scalable congestion controls, they need to be
isolated from the large queue variations induced by existing Classic isolated from the large queue variations induced by existing Classic
congestion controls. L4S AQMs provide that latency isolation in the congestion controls. L4S AQMs provide that latency isolation in the
network and the L4S identifier enables the AQMs to distinguish the two network, and the L4S identifier enables the AQMs to distinguish the two
types of packet that need to be isolated: L4S and Classic. L4S types of packets that need to be isolated: L4S and Classic. L4S
isolation can be achieved with a queue per flow (e.g. <xref target="RFC8 isolation can be achieved with a queue per flow (e.g., <xref target="RFC
290" format="default"/>) but a DualQ <xref target="I-D.ietf-tsvwg-aqm-dualq-coup 8290" format="default"/>), but a DualQ <xref target="RFC9332" format="default"/>
led" format="default"/> is sufficient, and is sufficient and
actually gives better tail latency <xref target="DCttH19" format="defaul actually gives better tail latency <xref target="DCttH19" format="defaul
t"/>. Both t"/>. Both
approaches are addressed in this document.</t> approaches are addressed in this document.</t>
<t>The DualQ solution was developed to make very low latency available <t>The DualQ solution was developed to make very low latency available
without requiring per-flow queues at every bottleneck. This was useful without requiring per-flow queues at every bottleneck. This was useful
because per-flow-queuing (FQ) has well-known downsides - not least the because per-flow queuing (FQ) has well-known downsides -- not least the
need to inspect transport layer headers in the network, which makes it need to inspect transport-layer headers in the network, which makes it
incompatible with privacy approaches such as IPSec VPN tunnels, and incompatible with privacy approaches such as IPsec Virtual Private Netwo
incompatible with link layer queue management, where transport layer rk (VPN) tunnels and
headers can be hidden, e.g. 5G.</t> incompatible with link-layer queue management, where transport-layer
headers can be hidden, e.g., 5G.</t>
<t>Latency is not the only concern addressed by L4S. It was known when <t>Latency is not the only concern addressed by L4S. It was known when
TCP congestion avoidance was first developed that it would not scale TCP congestion avoidance was first developed that it would not scale
to high bandwidth-delay products (footnote 6 of Jacobson and to high bandwidth-delay products (see footnote 6 of Jacobson and
Karels <xref target="TCP-CA" format="default"/>). Given regular broadban Karels <xref target="TCP-CA" format="default"/>).
d Given that Reno congestion control is already beyond its scaling range a
bit-rates over WAN distances are already <xref target="RFC3649" format=" t
default"/> regular broadband bitrates over WAN distances <xref target="RFC3649" for
beyond the scaling range of Reno congestion control, 'less unscalable' mat="default"/>, 'less unscalable'
Cubic <xref target="RFC8312" format="default"/> and Compound <xref targe CUBIC <xref target="RFC8312" format="default"/> and Compound <xref targe
t="I-D.sridharan-tcpm-ctcp" format="default"/> variants of TCP have been t="I-D.sridharan-tcpm-ctcp" format="default"/> variants of TCP have been
successfully deployed. However, these are now approaching their successfully deployed. However, these are now approaching their
scaling limits. Unfortunately, fully scalable congestion controls such scaling limits. Unfortunately, fully Scalable congestion controls such
as DCTCP <xref target="RFC8257" format="default"/> outcompete Classic EC as DCTCP <xref target="RFC8257" format="default"/> outcompete Classic EC
N N
congestion controls sharing the same queue, which is why they have congestion controls sharing the same queue, which is why they have
been confined to private data centres or research testbeds.</t> been confined to private data centres or research testbeds.</t>
<t>It turns out that these scalable congestion control algorithms that <t>It turns out that these Scalable congestion control algorithms that
solve the latency problem can also solve the scalability problem of solve the latency problem can also solve the scalability problem of
Classic congestion controls. The finer sawteeth in the congestion Classic congestion controls. The finer sawteeth in the congestion
window have low amplitude, so they cause very little queuing delay window (cwnd) have low amplitude, so they cause very little queuing dela
variation and the average time to recover from one congestion signal y
variation, and the average time to recover from one congestion signal
to the next (the average duration of each sawtooth) remains invariant, to the next (the average duration of each sawtooth) remains invariant,
which maintains constant tight control as flow-rate scales. A which maintains constant tight control as flow rate scales. A
background paper <xref target="DCttH19" format="default"/> gives the ful background paper <xref target="L4Seval22" format="default"/> gives the f
l ull
explanation of why the design solves both the latency and the scaling explanation of why the design solves both the latency and the scaling
problems, both in plain English and in more precise mathematical form. problems, both in plain English and in more precise mathematical form.
The explanation is summarized without the mathematics in Section 4 of The explanation is summarized without the mathematics in Section <xref t
the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" format="defa arget="RFC9330" section="4"
ult"/>.</t> sectionFormat="bare"/> of
the L4S architecture <xref target="RFC9330" format="default"/>.</t>
</section> </section>
<section anchor="l4sid_Terminology" numbered="true" toc="default"> <section anchor="l4sid_Terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" form NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
at="default"/> when, and only RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>[Note to the RFC Editor (to be removed before publication as an be interpreted as
RFC): The L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" format described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
="default"/> repeats the following definitions, when, and only when, they appear in all capitals, as shown here.
which should be identical, except in the architecture Classic CC and </t>
Scalable CC are condensed because they refer to a section later in the
architecture.]</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Classic Congestion Control:</dt> <dt>Classic Congestion Control:</dt>
<dd>A congestion control <dd>A congestion control
behaviour that can co-exist with standard Reno <xref target="RFC5681 behaviour that can coexist with standard Reno <xref target="RFC5681"
" format="default"/> without causing significantly negative impact format="default"/> without causing significantly negative impact
on its flow rate <xref target="RFC5033" format="default"/>. With Cla on its flow rate <xref target="RFC5033" format="default"/>. With Cla
ssic ssic
congestion controls, such as Reno or Cubic, because flow rate has congestion controls, such as Reno or CUBIC, because flow rate has
scaled since TCP congestion control was first designed in 1988, it scaled since TCP congestion control was first designed in 1988, it
now takes hundreds of round trips (and growing) to recover after a now takes hundreds of round trips (and growing) to recover after a
congestion signal (whether a loss or an ECN mark) as shown in the congestion signal (whether a loss or an ECN mark) as shown in the
examples in section 5.1 of the L4S architecture <xref target="I-D.ie examples in Section <xref target="RFC9330" section="5.1"
tf-tsvwg-l4s-arch" format="default"/> and in <xref target="RFC3649" format="defa sectionFormat="bare"/> of the L4S architecture <xref target="RFC9330" format="de
ult"/>. Therefore, control of queuing and utilization fault"/> and in <xref target="RFC3649" format="default"/>. Therefore, control of
becomes very slack, and the slightest disturbances (e.g. from queuing and utilization
becomes very slack, and the slightest disturbances (e.g., from
new flows starting) prevent a high rate from being attained.</dd> new flows starting) prevent a high rate from being attained.</dd>
<dt>Scalable Congestion Control:</dt> <dt>Scalable Congestion Control:</dt>
<dd>A congestion control <dd>A congestion control
where the average time from one congestion signal to the next (the where the average time from one congestion signal to the next (the
recovery time) remains invariant as the flow rate scales, all recovery time) remains invariant as flow rate scales, all
other factors being equal. This maintains the same degree of other factors being equal. This maintains the same degree of
control over queueing and utilization whatever the flow rate, as control over queuing and utilization whatever the flow rate, as
well as ensuring that high throughput is robust to disturbances. well as ensuring that high throughput is robust to disturbances.
For instance, DCTCP averages 2 congestion signals per round-trip For instance, DCTCP averages 2 congestion signals per round trip,
whatever the flow rate, as do other recently developed scalable whatever the flow rate, as do other recently developed Scalable
congestion controls, e.g. Relentless TCP <xref target="I-D.mathis-ic congestion controls, e.g., Relentless TCP <xref target="I-D.mathis-i
crg-relentless-tcp" format="default"/>, TCP Prague <xref target="I-D.briscoe-icc ccrg-relentless-tcp" format="default"/>, Prague for TCP and QUIC <xref target="I
rg-prague-congestion-control" format="default"/>, <xref target="PragueLinux" for -D.briscoe-iccrg-prague-congestion-control" format="default"/> <xref target="Pra
mat="default"/>, BBRv2 <xref target="BBRv2" format="default"/>, <xref target="I- gueLinux" format="default"/>, the L4S ECN
D.cardwell-iccrg-bbr-congestion-control" format="default"/> and the L4S part of Bottleneck Bandwidth and Round-trip propagation time
variant of SCREAM for real-time media <xref target="SCReAM-L4S" form (BBRv2) <xref target="BBRv2" format="default"/> <xref target="I-D.cardwell-ic
at="default"/>, <xref target="RFC8298" format="default"/>. See <xref target="l4s crg-bbr-congestion-control" format="default"/>, and the L4S
id_congestion_response" format="default"/> for more explanation.</dd> variant of SCReAM for real-time media <xref target="SCReAM-L4S" form
<dt>Classic service:</dt> at="default"/> <xref target="RFC8298" format="default"/>. See <xref target="l4si
d_congestion_response" format="default"/> for more explanation.</dd>
<dt>Classic Service:</dt>
<dd>The Classic service is intended for <dd>The Classic service is intended for
all the congestion control behaviours that co-exist with all the congestion control behaviours
Reno <xref target="RFC5681" format="default"/> (e.g. Reno itself, that coexist with Reno <xref target="RFC5681" format="default"/> (e.g
Cubic <xref target="RFC8312" format="default"/>, Compound <xref targ ., Reno itself,
et="I-D.sridharan-tcpm-ctcp" format="default"/>, TFRC <xref target="RFC5348" for CUBIC <xref target="RFC8312" format="default"/>, Compound <xref targ
mat="default"/>). The term 'Classic queue' means a queue et="I-D.sridharan-tcpm-ctcp" format="default"/>, and TFRC <xref target="RFC5348"
format="default"/>). The term 'Classic queue' means a queue
providing the Classic service.</dd> providing the Classic service.</dd>
<dt>Low-Latency, Low-Loss Scalable throughput (L4S) service:</dt> <dt>Low Latency, Low Loss, and Scalable throughput (L4S) service:</dt>
<dd> <dd>
<t>The <t>The
'L4S' service is intended for traffic from scalable congestion 'L4S' service is intended for traffic from Scalable congestion
control algorithms, such as the Prague congestion control <xref targ et="I-D.briscoe-iccrg-prague-congestion-control" format="default"/>, which was control algorithms, such as the Prague congestion control <xref targ et="I-D.briscoe-iccrg-prague-congestion-control" format="default"/>, which was
derived from DCTCP <xref target="RFC8257" format="default"/>. The L4 derived from DCTCP <xref target="RFC8257" format="default"/>.
S service The L4S service
is for more general traffic than just Prague -- it allows the is for more general traffic than just Prague -- it allows the
set of congestion controls with similar scaling properties to set of congestion controls with similar scaling properties to
Prague to evolve, such as the examples listed above (Relentless, Prague to evolve, such as the examples listed above (Relentless,
SCReAM, etc.). The term 'L4S queue' means a queue providing the SCReAM, etc.). The term 'L4S queue' means a queue providing the
L4S service.</t> L4S service.</t>
<t>The terms Classic or L4S can <t>The terms Classic or L4S can
also qualify other nouns, such as 'queue', 'codepoint', also qualify other nouns, such as 'queue', 'codepoint',
'identifier', 'classification', 'packet', 'flow'. For example: an 'identifier', 'classification', 'packet', and 'flow'. For example, a n
L4S packet means a packet with an L4S identifier sent from an L4S L4S packet means a packet with an L4S identifier sent from an L4S
congestion control.</t> congestion control.</t>
<t>Both Classic and L4S <t>Both Classic and L4S
services can cope with a proportion of unresponsive or services can cope with a proportion of unresponsive or
less-responsive traffic as well, but in the L4S case its rate has less-responsive traffic as well but, in the L4S case, its rate has
to be smooth enough or low enough not to build a queue to be smooth enough or low enough to not build a queue
(e.g. DNS, VoIP, game sync datagrams, etc.).</t> (e.g., DNS, Voice over IP (VoIP), game sync datagrams, etc.).</t>
</dd> </dd>
<dt>Reno-friendly:</dt> <dt>Reno-friendly:</dt>
<dd>The subset of Classic traffic that is <dd>The subset of Classic traffic that is
friendly to the standard Reno congestion control defined for TCP friendly to the standard Reno congestion control defined for TCP
in <xref target="RFC5681" format="default"/>. The TFRC spec <xref ta rget="RFC5348" format="default"/> indirectly implies that 'friendly' is defined in <xref target="RFC5681" format="default"/>. The TFRC spec <xref ta rget="RFC5348" format="default"/> indirectly implies that 'friendly' is defined
as "generally within a factor of two of the sending rate of a TCP as "generally within a factor of two of the sending rate of a TCP
flow under the same conditions". Reno-friendly is used here in flow under the same conditions". Reno-friendly is used here in
place of 'TCP-friendly', given the latter has become imprecise, place of 'TCP-friendly', given the latter has become imprecise,
because the TCP protocol is now used with so many different because the TCP protocol is now used with so many different
congestion control behaviours, and Reno can be used in non-TCP congestion control behaviours, and Reno is used in non-TCP
transports such as QUIC <xref target="RFC9000" format="default"/>.</ transports, such as QUIC <xref target="RFC9000" format="default"/>.<
dd> /dd>
<dt>Classic ECN:</dt> <dt>Classic ECN:</dt>
<dd>The original Explicit Congestion <dd><t>The original Explicit Congestion Notification (ECN) protocol <x
Notification (ECN) protocol <xref target="RFC3168" format="default"/ ref target="RFC3168" format="default"/> that
>, which requires ECN signals to be treated as equivalent to drops, both when
requires ECN signals to be treated the same as drops, both when generated in the network and when responded to by the sender.</t>
generated in the network and when responded to by the sender. For
L4S, the names used for the four codepoints of the 2-bit IP-ECN <t>For L4S, the names used for the
field are unchanged from those defined in <xref target="RFC3168" for four codepoints of the 2-bit IP-ECN field are unchanged from those
mat="default"/>: Not ECT, ECT(0), ECT(1) and CE, where ECT defined in the ECN spec <xref target="RFC3168" format="default"/>, i.
stands for ECN-Capable Transport and CE stands for Congestion e., Not-ECT,
Experienced. A packet marked with the CE codepoint is termed ECT(0), ECT(1), and CE, where ECT stands for ECN-Capable
'ECN-marked' or sometimes just 'marked' where the context makes Transport and CE stands for Congestion Experienced. A packet
ECN obvious.</dd> marked with the CE codepoint is termed 'ECN-marked' or sometimes
just 'marked' where the context makes ECN obvious.</t></dd>
<dt>Site:</dt> <dt>Site:</dt>
<dd>A home, mobile device, small enterprise or <dd>A home, mobile device, small enterprise, or
campus, where the network bottleneck is typically the access link campus where the network bottleneck is typically the access link
to the site. Not all network arrangements fit this model but it is to the site. Not all network arrangements fit this model, but it is
a useful, widely applicable generalization.</dd> a useful, widely applicable generalization.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Scope</name> <name>Scope</name>
<t>The new L4S identifier defined in this specification is applicable <t>The new L4S identifier defined in this specification is applicable
for IPv4 and IPv6 packets (as for Classic ECN <xref target="RFC3168" for mat="default"/>). It is applicable for the unicast, multicast and for IPv4 and IPv6 packets (as is Classic ECN <xref target="RFC3168" form at="default"/>). It is applicable for the unicast, multicast, and
anycast forwarding modes.</t> anycast forwarding modes.</t>
<t>The L4S identifier is an orthogonal packet classification to the <t>The L4S identifier is an orthogonal packet classification to the
Differentiated Services Code Point (DSCP) <xref target="RFC2474" format= "default"/>. <xref target="l4sid_other_IDs" format="default"/> explains what Differentiated Services Code Point (DSCP) <xref target="RFC2474" format= "default"/>. <xref target="l4sid_other_IDs" format="default"/> explains what
this means in practice.</t> this means in practice.</t>
<t>This document is intended for experimental status, so it does not <t>This document is Experimental, so it does not
update any standards track RFCs. Therefore, it depends on <xref target=" update any Standards Track RFCs. Therefore, it depends on <xref target="
RFC8311" format="default"/>, which is a standards track specification RFC8311" format="default"/>, which is a Standards Track specification
that:</t> that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>updates the ECN proposed standard <xref target="RFC3168" format="d <li>updates the ECN Proposed Standard <xref target="RFC3168" format="d
efault"/> efault"/>
to allow experimental track RFCs to relax the requirement that an to allow Experimental RFCs to relax the requirement that an
ECN mark must be equivalent to a drop (when the network applies ECN mark must be equivalent to a drop (when the network applies
markings and/or when the sender responds to them). For instance, markings and/or when the sender responds to them).
in the ABE experiment <xref target="RFC8511" format="default"/> this For instance,
permits a in the Alternative Backoff with ECN (ABE) experiment <xref target="R
FC8511" format="default"/>, this relaxation permits a
sender to respond less to ECN marks than to drops;</li> sender to respond less to ECN marks than to drops;</li>
<li>changes the status of the experimental ECN nonce <xref target="RFC 3540" format="default"/> to historic;</li> <li>changes the status of the Experimental ECN nonce spec <xref target ="RFC3540" format="default"/> to Historic; and</li>
<li> <li>
<t>makes consequent updates to the following additional proposed <t>makes consequent updates to the following additional Proposed
standard RFCs to reflect the above two bullets:</t> Standard RFCs to reflect the above two bullets:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>ECN for RTP <xref target="RFC6679" format="default"/>;</li> <li>ECN for RTP <xref target="RFC6679" format="default"/> and </li >
<li>the congestion control specifications of various DCCP <li>the congestion control specifications of various DCCP
congestion control identifier (CCID) profiles <xref target="RFC4 341" format="default"/>, <xref target="RFC4342" format="default"/>, <xref target ="RFC5622" format="default"/>.</li> Congestion Control Identifier (CCID) profiles <xref target="RFC4 341" format="default"/> <xref target="RFC4342" format="default"/> <xref target=" RFC5622" format="default"/>.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>This document is about identifiers that are used for interoperation <t>This document is about identifiers that are used for interoperation
between hosts and networks. So the audience is broad, covering between hosts and networks. So the audience is broad, covering
developers of host transports and network AQMs, as well as covering developers of host transports and network AQMs, as well as covering
how operators might wish to combine various identifiers, which would how operators might wish to combine various identifiers, which would
require flexibility from equipment developers.</t> require flexibility from equipment developers.</t>
</section> </section>
</section> </section>
<section anchor="l4sid_identification" numbered="true" toc="default"> <section anchor="l4sid_identification" numbered="true" toc="default">
<name>L4S Packet Identification: Document Roadmap</name> <name>L4S Packet Identification: Document Roadmap</name>
<t>The L4S treatment is an experimental track alternative packet marking <t>The L4S ECN marking treatment is an experimental alternative
treatment to the Classic ECN treatment in <xref target="RFC3168" format="d to the Classic ECN treatment in <xref target="RFC3168" format="default"/>,
efault"/>,
which has been updated by <xref target="RFC8311" format="default"/> to all ow experiments which has been updated by <xref target="RFC8311" format="default"/> to all ow experiments
such as the one defined in the present specification. <xref target="RFC477 4" format="default"/> discusses some of the issues and evaluation criteria such as the one defined in the present specification. <xref target="RFC477 4" format="default"/> discusses some of the issues and evaluation criteria
when defining alternative ECN semantics, which are further discussed in when defining alternative ECN semantics, which are further discussed in
<xref target="l4sid_congestion_response_rfcs" format="default"/>.</t> <xref target="l4sid_congestion_response_rfcs" format="default"/>.</t>
<t>The L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" format="def ault"/> <t>The L4S architecture <xref target="RFC9330" format="default"/>
describes the three main components of L4S: the sending host behaviour, describes the three main components of L4S: the sending host behaviour,
the marking behaviour in the network and the L4S ECN protocol that the marking behaviour in the network, and the L4S ECN protocol that
identifies L4S packets as they flow between the two.</t> identifies L4S packets as they flow between the two.</t>
<t>The next section of the present document (<xref target="l4sid_reqs" for
mat="default"/>) records the requirements that informed the choice <t><xref target="l4sid_reqs" format="default"/> of this document records t
of L4S identifier. Then subsequent sections specify the L4S ECN he requirements that informed the choice
of L4S identifier. Then, subsequent sections specify the L4S ECN
protocol, which i) identifies packets that have been sent from hosts protocol, which i) identifies packets that have been sent from hosts
that are expected to comply with a broad type of sending behaviour; and that are expected to comply with a broad type of sending behaviour and
ii) identifies the marking treatment that network nodes are expected to ii) identifies the marking treatment that network nodes are expected to
apply to L4S packets.</t> apply to L4S packets.</t>
<t>For a packet to receive L4S treatment as it is forwarded, the sender <t>For a packet to receive L4S treatment as it is forwarded, the sender
sets the ECN field in the IP header to the ECT(1) codepoint. See <xref tar get="l4sid_transport_req" format="default"/> for full transport layer behaviour sets the ECN field in the IP header to the ECT(1) codepoint. See <xref tar get="l4sid_transport_req" format="default"/> for full transport-layer behaviour
requirements, including feedback and congestion response.</t> requirements, including feedback and congestion response.</t>
<t>A network node that implements the L4S service always classifies <t>A network node that implements the L4S service always classifies
arriving ECT(1) packets for L4S treatment and by default classifies CE arriving ECT(1) packets for L4S treatment and by default classifies CE
packets for L4S treatment unless the heuristics described in <xref target= "l4sid_identification_transport_aware" format="default"/> are employed. See <xre f target="l4sid_network_req" format="default"/> for full network element behavio ur packets for L4S treatment unless the heuristics described in <xref target= "l4sid_identification_transport_aware" format="default"/> are employed. See <xre f target="l4sid_network_req" format="default"/> for full network element behavio ur
requirements, including classification, ECN-marking and interaction of requirements, including classification, ECN marking, and interaction of
the L4S identifier with other identifiers and per-hop behaviours.</t> the L4S identifier with other identifiers and per-hop behaviours.</t>
<t>L4S ECN works with ECN tunnelling and encapsulation behaviour as is, <t>L4S ECN works with ECN tunnelling and encapsulation behaviour as is,
except there is one known case where careful attention to configuration except there is one known case where careful attention to configuration
is required, which is detailed in <xref target="l4sid_encaps" format="defa ult"/>.</t> is required, which is detailed in <xref target="l4sid_encaps" format="defa ult"/>.</t>
<t>L4S ECN is currently on the experimental track. So <xref target="l4sid_ expts" format="default"/> collects together the general questions and <t>This specification of L4S ECN currently has Experimental status. So <xr ef target="l4sid_expts" format="default"/> collects the general questions and
issues that remain open for investigation during L4S experimentation. issues that remain open for investigation during L4S experimentation.
Open issues or questions specific to particular components are called Open issues or questions specific to particular components are called
out in the specifications of each component part, such as the DualQ out in the specifications of each component part, such as the DualQ
<xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" format="default"/>.</t> <xref target="RFC9332" format="default"/>.</t>
<t>The IANA assignment of the L4S identifier is specified in <xref target= "l4sid_IANA" format="default"/>. And <xref target="l4sid_Security_Considerations " format="default"/> covers security considerations <t>The IANA assignment of the L4S identifier is specified in <xref target= "l4sid_IANA" format="default"/>. And <xref target="l4sid_Security_Considerations " format="default"/> covers security considerations
specific to the L4S identifier. System security aspects, such as specific to the L4S identifier. System security aspects, such as
policing and privacy, are covered in the L4S architecture <xref target="I- D.ietf-tsvwg-l4s-arch" format="default"/>.</t> policing and privacy, are covered in the L4S architecture <xref target="RF C9330" format="default"/>.</t>
</section> </section>
<section anchor="l4sid_reqs" numbered="true" toc="default"> <section anchor="l4sid_reqs" numbered="true" toc="default">
<name>Choice of L4S Packet Identifier: Requirements</name> <name>Choice of L4S Packet Identifier: Requirements</name>
<t>This subsection briefly records the process that led to the chosen <t>This subsection briefly records the process that led to the chosen
L4S identifier.</t> L4S identifier.</t>
<t>The identifier for packets using the Low Latency, Low Loss, Scalable <t>The identifier for packets using the L4S service needs to meet the foll
throughput (L4S) service needs to meet the following requirements:</t> owing requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>it SHOULD survive end-to-end between source and destination <li>it <bcp14>SHOULD</bcp14> survive end to end between source and desti
end-points: across the boundary between host and network, between nation
endpoints: across the boundary between host and network, between
interconnected networks, and through middleboxes;</li> interconnected networks, and through middleboxes;</li>
<li>it SHOULD be visible at the IP layer;</li> <li>it <bcp14>SHOULD</bcp14> be visible at the IP layer;</li>
<li>it SHOULD be common to IPv4 and IPv6 and transport-agnostic;</li> <li>it <bcp14>SHOULD</bcp14> be common to IPv4 and IPv6 and be transport
<li>it SHOULD be incrementally deployable;</li> -agnostic;</li>
<li>it SHOULD enable an AQM to classify packets encapsulated by outer <li>it <bcp14>SHOULD</bcp14> be incrementally deployable;</li>
<li>it <bcp14>SHOULD</bcp14> enable an AQM to classify packets encapsula
ted by outer
IP or lower-layer headers;</li> IP or lower-layer headers;</li>
<li>it SHOULD consume minimal extra codepoints;</li> <li>it <bcp14>SHOULD</bcp14> consume minimal extra codepoints; and</li>
<li>it SHOULD be consistent on all the packets of a transport layer <li>it <bcp14>SHOULD</bcp14> be consistent on all the packets of a trans
port-layer
flow, so that some packets of a flow are not served by a different flow, so that some packets of a flow are not served by a different
queue to others.</li> queue to others.</li>
</ul> </ul>
<t>Whether the identifier would be recoverable if the experiment failed <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 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 made a requirement, because that would favour schemes that would be
easier to fail, rather than those more likely to succeed.</t> easier to fail rather than more likely to succeed.</t>
<t>It is recognized that any choice of identifier is unlikely to satisfy <t>It is recognized that any choice of identifier is unlikely to satisfy
all these requirements, particularly given the limited space left in the all these requirements, particularly given the limited space left in the
IP header. Therefore, a compromise will always be necessary, which is IP header. Therefore, a compromise will always be necessary, which is
why all the above requirements are expressed with the word 'SHOULD' not why all the above requirements are expressed with the word "<bcp14>SHOULD<
'MUST'.</t> /bcp14>" not
"<bcp14>MUST</bcp14>".</t>
<t>After extensive assessment of alternative schemes, "ECT(1) and CE <t>After extensive assessment of alternative schemes, "ECT(1) and CE
codepoints" was chosen as the best compromise. Therefore, this scheme is codepoints" was chosen as the best compromise. Therefore, this scheme is
defined in detail in the following sections, while <xref target="l4sid_ECT 1_CE" format="default"/> records its pros and cons against the above defined in detail in the following sections, while <xref target="l4sid_ECT 1_CE" format="default"/> records its pros and cons against the above
requirements.</t> requirements.</t>
</section> </section>
<section anchor="l4sid_transport_req" numbered="true" toc="default"> <section anchor="l4sid_transport_req" numbered="true" toc="default">
<name>Transport Layer Behaviour (the 'Prague Requirements')</name> <name>Transport-Layer Behaviour (the 'Prague L4S Requirements')</name>
<t>This section defines L4S behaviour at the transport layer, also known <t>This section defines L4S behaviour at the transport layer, also known
as the Prague L4S Requirements (see <xref target="l4sps_tcp-prague-reqs" f ormat="default"/> for the origin of the name).</t> as the 'Prague L4S Requirements' (see <xref target="l4sps_tcp-prague-reqs" format="default"/> for the origin of the name).</t>
<section anchor="l4sid_codepoint" numbered="true" toc="default"> <section anchor="l4sid_codepoint" numbered="true" toc="default">
<name>Codepoint Setting</name> <name>Codepoint Setting</name>
<t>A sender that wishes a packet to receive L4S treatment as it is <t>A sender that wishes a packet to receive L4S treatment as it is
forwarded, MUST set the ECN field in the IP header (v4 or v6) to the forwarded <bcp14>MUST</bcp14> set the ECN field in the IP header (v4 or v6) to the
ECT(1) codepoint.</t> ECT(1) codepoint.</t>
</section> </section>
<section anchor="l4sid_feedback" numbered="true" toc="default"> <section anchor="l4sid_feedback" numbered="true" toc="default">
<name>Prerequisite Transport Feedback</name> <name>Prerequisite Transport Feedback</name>
<t>For a transport protocol to provide scalable congestion control <t>For a transport protocol to provide Scalable congestion control
(<xref target="l4sid_congestion_response" format="default"/>) it MUST pr (<xref target="l4sid_congestion_response" format="default"/>), it <bcp14
ovide feedback >MUST</bcp14> provide feedback
of the extent of CE marking on the forward path. When ECN was added to of the extent of CE marking on the forward path. When ECN was added to
TCP <xref target="RFC3168" format="default"/>, the feedback method repor ted no TCP <xref target="RFC3168" format="default"/>, the feedback method repor ted no
more than one CE mark per round trip. Some transport protocols derived more than one CE mark per round trip. Some transport protocols derived
from TCP mimic this behaviour while others report the accurate extent from TCP mimic this behaviour while others report the accurate extent
of ECN marking. This means that some transport protocols will need to of ECN marking. This means that some transport protocols will need to
be updated as a prerequisite for scalable congestion control. The be updated as a prerequisite for Scalable congestion control. The
position for a few well-known transport protocols is given below.</t> position for a few well-known transport protocols is given below.</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>TCP:</dt> <dt>TCP:</dt>
<dd>Support for the accurate ECN feedback <dd>Support for the accurate ECN feedback
requirements <xref target="RFC7560" format="default"/> (such as that requirements <xref target="RFC7560" format="default"/> (such as that
provided provided
by AccECN <xref target="I-D.ietf-tcpm-accurate-ecn" format="default" by AccECN <xref target="I-D.ietf-tcpm-accurate-ecn" format="default"
/>) by />) by
both ends is a prerequisite for scalable congestion control in both ends is a prerequisite for Scalable congestion control in
TCP. Therefore, the presence of ECT(1) in the IP headers even in TCP. Therefore, the presence of ECT(1) in the IP headers even in
one direction of a TCP connection will imply that both ends one direction of a TCP connection will imply that both ends
support accurate ECN feedback. However, the converse does not support accurate ECN feedback. However, the converse does not
apply. So even if both ends support AccECN, either of the two ends apply.
can choose not to use a scalable congestion control, whatever the So even if both ends support AccECN, either of the two ends
other end's choice.</dd> can choose not to use a Scalable congestion control, whatever the
<dt>SCTP:</dt> other end's choice is.</dd>
<dt>SCTP:</dt>
<dd>A suitable ECN feedback mechanism for SCTP <dd>A suitable ECN feedback mechanism for SCTP
could add a chunk to report the number of received CE marks (as could add a chunk to report the number of received CE marks (as
described in a long-expired draft <xref target="I-D.stewart-tsvwg-sc described in a long-expired document <xref target="I-D.stewart-tsvwg
tpecn" format="default"/> or as sketched out in -sctpecn" format="default"/> or as sketched out in
Appendix A of the now obsolete second standards track Appendix <xref target="RFC4960" section="A" sectionFormat="bare"/> o
specification of SCTP <xref target="RFC4960" format="default"/>).</d f the now-obsolete second Standards Track
d> specification of SCTP <xref target="RFC4960" format="default"/>).</d
d>
<dt>RTP over UDP:</dt> <dt>RTP over UDP:</dt>
<dd>A prerequisite for scalable congestion <dd>A prerequisite for Scalable congestion
control is for both (all) ends of one media-level hop to signal control is for both (all) ends of one media-level hop to signal
ECN support <xref target="RFC6679" format="default"/> and use the ne w generic ECN support <xref target="RFC6679" format="default"/> and use the ne w generic
RTCP feedback format of <xref target="RFC8888" format="default"/>. T he presence of RTCP feedback format of <xref target="RFC8888" format="default"/>. T he presence of
ECT(1) implies that both (all) ends of that media-level hop ECT(1) implies that both (all) ends of that media-level hop
support ECN. However, the converse does not apply. So each end of support ECN. However, the converse does not apply. So each end of
a media-level hop can independently choose not to use a scalable a media-level hop can independently choose not to use a Scalable
congestion control, even if both ends support ECN.</dd> congestion control, even if both ends support ECN.</dd>
<dt>QUIC:</dt> <dt>QUIC:</dt>
<dd>Support for sufficiently fine-grained ECN <dd>Support for sufficiently fine-grained ECN
feedback is provided by the v1 IETF QUIC transport <xref target="RFC 9000" format="default"/>.</dd> feedback is provided by IETF QUIC transport v1 <xref target="RFC9000 " format="default"/>.</dd>
<dt>DCCP:</dt> <dt>DCCP:</dt>
<dd>The ACK vector in DCCP <xref target="RFC4340" format="default"/> i <dd>The Acknowledgement (ACK) vector in DCCP <xref target="RFC4340" fo
s already sufficient to report the extent of rmat="default"/> is already sufficient to report the extent of
CE marking as needed by a scalable congestion control.</dd> CE marking as needed by a Scalable congestion control.</dd>
</dl> </dl>
</section> </section>
<section anchor="l4sid_congestion_response" numbered="true" toc="default"> <section anchor="l4sid_congestion_response" numbered="true" toc="default">
<name>Prerequisite Congestion Response</name> <name>Prerequisite Congestion Response</name>
<t>As a condition for a host to send packets with the L4S identifier <t>As a condition for a host to send packets with the L4S identifier
(ECT(1)), it SHOULD implement a congestion control behaviour that (ECT(1)), it <bcp14>SHOULD</bcp14> implement a congestion control behavi our that
ensures that, in steady state, the average duration between induced ensures that, in steady state, the average duration between induced
ECN marks does not increase as flow rate scales up, all other factors ECN marks does not increase as flow rate scales up, all other factors
being equal. This is termed a scalable congestion control. This being equal. This is termed a Scalable congestion control. This
invariant duration ensures that, as flow rate scales, the average invariant duration ensures that, as flow rate scales, the average
period with no feedback information about capacity does not become period with no feedback information about capacity does not become
excessive. It also ensures that queue variations remain small, without excessive. It also ensures that queue variations remain small, without
having to sacrifice utilization.</t> having to sacrifice utilization.</t>
<t>With a congestion control that sawtooths to probe capacity, this <t>With a congestion control that sawtooths to probe capacity, this
duration is called the recovery time, because each time the sawtooth duration is called the recovery time, because each time the sawtooth
yields, on average it takes this time to recover to its previous high yields, on average it takes this time to recover to its previous high
point. A scalable congestion control does not have to sawtooth, but it point. A Scalable congestion control does not have to sawtooth, but it
has to coexist with scalable congestion controls that do.</t> has to coexist with Scalable congestion controls that do.</t>
<t>For instance, for DCTCP <xref target="RFC8257" format="default"/>, TC <t>For instance, for DCTCP <xref target="RFC8257" format="default"/>, TC
P Prague P Prague
<xref target="I-D.briscoe-iccrg-prague-congestion-control" format="defau <xref target="I-D.briscoe-iccrg-prague-congestion-control" format="defau
lt"/>, <xref target="PragueLinux" format="default"/> and the L4S variant of SCRe lt"/> <xref target="PragueLinux" format="default"/>, and the L4S variant of SCRe
AM <xref target="SCReAM-L4S" format="default"/>, <xref target="RFC8298" format=" AM <xref target="SCReAM-L4S" format="default"/> <xref target="RFC8298" format="d
default"/>, the average recovery efault"/>, the average recovery
time is always half a round trip (or half a reference round trip), time is always half a round trip (or half a reference round trip),
whatever the flow rate.</t> whatever the flow rate.</t>
<t>As with all transport behaviours, a detailed specification <t>As with all transport behaviours, a detailed specification
(probably an experimental RFC) is expected for each congestion (probably an Experimental RFC) is expected for each congestion
control, following the guidelines for specifying new congestion control, following the guidelines for specifying new congestion
control algorithms in <xref target="RFC5033" format="default"/>. In addi control algorithms in <xref target="RFC5033" format="default"/>. In addi
tion, it tion, it
is expected to document these L4S-specific matters, specifically the is expected that these L4S-specific matters will be documented, specific
timescale over which the proportionality is averaged, and control of ally the
timescale over which the proportionality is averaged and the control of
burstiness. The recovery time requirement above is worded as a burstiness. The recovery time requirement above is worded as a
'SHOULD' rather than a 'MUST' to allow reasonable flexibility for such "<bcp14>SHOULD</bcp14>" rather than a "<bcp14>MUST</bcp14>" to allow rea sonable flexibility for such
implementations.</t> implementations.</t>
<t>The condition 'all other factors being equal', allows the recovery <t>The condition 'all other factors being equal' allows the recovery
time to be different for different round trip times, as long as it time to be different for different round-trip times, as long as it
does not increase with flow rate for any particular RTT.</t> does not increase with flow rate for any particular RTT.</t>
<t>Saying that the recovery time remains roughly invariant is <t>Saying that the recovery time remains roughly invariant is
equivalent to saying that the number of ECN CE marks per round trip equivalent to saying that the number of ECN CE marks per round trip
remains invariant as flow rate scales, all other factors being equal. remains invariant as flow rate scales, all other factors being equal.
For instance, an average recovery time of half of 1 RTT is equivalent For instance, an average recovery time of half of 1 RTT is equivalent
to 2 ECN marks per round trip. For those familiar with steady-state to 2 ECN marks per round trip. For those familiar with steady-state
congestion response functions, it is also equivalent to say that the congestion response functions, it is also equivalent to say that the
congestion window is inversely proportional to the proportion of bytes congestion window is inversely proportional to the proportion of bytes
in packets marked with the CE codepoint (see section 2 of <xref target=" in packets marked with the CE codepoint (see Section 2 of <xref target="
PI2" format="default"/>).</t> PI2" format="default"/>).</t>
<!--For example, the timescale over which this rough proportionality app
lies will depend on the type of application, ranging
from per packet adjustment through smooth adjustment of encoding over perhaps te
ns of seconds. Low bit-rate flows might
even respond at the timescale of self-admission control solely at the start of e
ach flow. As with any congestion control,
the sender SHOULD also avoid excessive bursts, but this is particularly importan
t with the L4S service.-->
<t>In order to coexist safely with other Internet traffic, a scalable <t>In order to coexist safely with other Internet traffic, a Scalable
congestion control is not allowed to tag its packets with the ECT(1) congestion control is not allowed to tag its packets with the ECT(1)
codepoint unless it complies with the following numbered requirements codepoint unless it complies with the following numbered requirements
and recommendations:</t> and recommendations:</t>
<ol spacing="normal" type="1"><li>A scalable congestion control MUST be
capable of being replaced <ol spacing="normal" type="1"><li anchor="l4sid_Prague_req-replaceable">
A Scalable congestion control <bcp14>MUST</bcp14> be capable of being replaced
by a Classic congestion control (by application and/or by by a Classic congestion control (by application and/or by
administrative control). If a Classic congestion control is administrative control). If a Classic congestion control is
activated, it will not tag its packets with the ECT(1) codepoint activated, it will not tag its packets with the ECT(1) codepoint
(see <xref target="l4sid_sec_replaceable" format="default"/> for rat ionale).</li> (see <xref target="l4sid_sec_replaceable" format="default"/> for rat ionale).</li>
<li>As well as responding to ECN markings, a scalable congestion
control MUST react to packet loss in a way that will coexist <li anchor="l4sid_Prague_req-loss-response">As well as responding to E
safely with Classic congestion controls such as standard CN markings, a Scalable congestion
Reno <xref target="RFC5681" format="default"/>, as required by <xref control <bcp14>MUST</bcp14> react to packet loss in a way that will
target="RFC5033" format="default"/> (see <xref target="l4sid_sec_fallback_on_lo coexist
ss" format="default"/> for rationale).</li> safely with Classic congestion controls
<li> such as standard Reno <xref target="RFC5681" format="default"/>, as r
<t>In uncontrolled environments, monitoring MUST be implemented to equired by <xref target="RFC5033" format="default"/> (see <xref target="l4sid_se
c_fallback_on_loss" format="default"/> for rationale).</li>
<li anchor="l4sid_Prague_req-classic-ecn-response">
<t>In uncontrolled environments, monitoring <bcp14>MUST</bcp14> be i
mplemented to
support detection of problems with an ECN-capable AQM at the path support detection of problems with an ECN-capable AQM at the path
bottleneck that appears not to support L4S and might be in a bottleneck that appears not to support L4S and that might be in a
shared queue. Such monitoring SHOULD be applied to live traffic shared queue. Such monitoring <bcp14>SHOULD</bcp14> be applied to li
ve traffic
that is using Scalable congestion control. Alternatively, that is using Scalable congestion control. Alternatively,
monitoring need not be applied to live traffic, if monitoring with monitoring need not be applied to live traffic, if monitoring with
test traffic has been arranged to cover the paths that live test traffic has been arranged to cover the paths that live
traffic takes through uncontrolled environments. </t> traffic takes through uncontrolled environments. </t>
<t>A function to detect the above problems with an <t>A function to detect the above problems with an
ECN-capable AQM MUST also be implemented and used. The detection ECN-capable AQM <bcp14>MUST</bcp14> also be implemented and used. Th
function SHOULD be capable of making the congestion control adapt e detection
its ECN-marking response in real-time to coexist safely with function <bcp14>SHOULD</bcp14> be capable of making the congestion c
Classic congestion controls such as standard Reno <xref target="RFC5 ontrol adapt
681" format="default"/>, as required by <xref target="RFC5033" format="default"/ its ECN-marking response in real time to coexist safely with
>. This Classic congestion controls such as standard Reno <xref target="RFC5
681" format="default"/>, as required by <xref target="RFC5033" format="default"/
>. This
could be complemented by more detailed offline detection of could be complemented by more detailed offline detection of
potential problems. If only offline detection is used and potential problems. If only offline detection is used and
potential problems with such an AQM are detected on certain paths, potential problems with such an AQM are detected on certain paths,
the scalable congestion control MUST be replaced by a Classic the Scalable congestion control <bcp14>MUST</bcp14> be replaced by a Classic
congestion control, at least for the problem paths. </t> congestion control, at least for the problem paths. </t>
<t>See <xref target="l4sid_congestion_response_rfcs" format="default <t>See <xref target="l4sid_congestion_response_rfcs" format="default
"/>, <xref target="l4sid_sec_fallback_on_classic_CE" format="default"/> and the "/>, <xref target="l4sid_sec_fallback_on_classic_CE" format="default"/>, and the
L4S L4S
operational guidance <xref target="I-D.ietf-tsvwg-l4sops" format="de operational guidance <xref target="I-D.ietf-tsvwg-l4sops" format="de
fault"/> fault"/>
for rationale and explanation.</t> for rationale and explanation.</t>
<t>Note that a
scalable congestion control is not expected to change to setting <t indent="3">Note that a
Scalable congestion control is not expected to change to setting
ECT(0) while it transiently adapts to coexist with Classic ECT(0) while it transiently adapts to coexist with Classic
congestion controls, whereas a replacement congestion control that congestion controls, whereas a replacement congestion control that
solely behaves in the Classic way will set ECT(0).</t> solely behaves in the Classic way will set ECT(0).</t>
</li> </li>
<li>In the range between the minimum likely RTT and typical RTTs <li anchor="l4sid_Prague_req-rtt-independence">In the range between th
expected in the intended deployment scenario, a scalable e minimum likely RTT and typical RTTs
congestion control MUST converge towards a rate that is as expected in the intended deployment scenario, a Scalable
congestion control <bcp14>MUST</bcp14> converge towards a rate that
is as
independent of RTT as is possible without compromising stability independent of RTT as is possible without compromising stability
or utilization (see <xref target="l4sid_sec_RTT_dependence" format=" default"/> for or utilization (see <xref target="l4sid_sec_RTT_dependence" format=" default"/> for
rationale).</li> rationale).</li>
<li>A scalable congestion control SHOULD remain responsive to <li anchor="l4sid_Prague_req-fractional-window">A Scalable congestion control <bcp14>SHOULD</bcp14> remain responsive to
congestion when typical RTTs over the public Internet are congestion when typical RTTs over the public Internet are
significantly smaller because they are no longer inflated by significantly smaller because they are no longer inflated by
queuing delay. It would be preferable for the minimum window of a queuing delay. It would be preferable for the minimum window of a
scalable congestion control to be lower than 1 segment rather than Scalable congestion control to be lower than 1 segment rather than
use the timeout approach described for TCP in S.6.1.2 of the ECN use the timeout approach described for TCP in
spec <xref target="RFC3168" format="default"/> (or an equivalent for <xref target="RFC3168" sectionFormat="of" section="6.1.2">the ECN sp
other ec</xref> (or an equivalent for other
transports). However, a lower minimum is not set as a formal transports). However, a lower minimum is not set as a formal
requirement for L4S experiments (see <xref target="l4sid_sec_min_cwn d" format="default"/> for rationale).</li> requirement for L4S experiments (see <xref target="l4sid_sec_min_cwn d" format="default"/> for rationale).</li>
<li>A scalable congestion control's loss detection SHOULD be <li anchor="l4sid_Prague_req-reordering">A Scalable congestion control 's loss detection <bcp14>SHOULD</bcp14> be
resilient to reordering over an adaptive time interval that scales resilient to reordering over an adaptive time interval that scales
with throughput and adapts to reordering (as in RACK <xref target="R with throughput and adapts to reordering (as in Recent ACK (RACK) <x
FC8985" format="default"/>), as opposed to counting only in fixed units of ref target="RFC8985" format="default"/>), as opposed to counting only in fixed u
packets (as in the 3 DupACK rule of New Reno <xref target="RFC5681" nits of
format="default"/> and <xref target="RFC6675" format="default"/>, which is not packets (as in the 3 Duplicate ACK (DupACK) rule of NewReno <xref ta
rget="RFC5681" format="default"/> <xref target="RFC6675" format="default"/>, whi
ch is not
scalable). As data rates increase (e.g., due to new and/or scalable). As data rates increase (e.g., due to new and/or
improved technology), congestion controls that detect loss by improved technology), congestion controls that detect loss by
counting in units of packets become more likely to incorrectly counting in units of packets become more likely to incorrectly
treat reordering events as congestion-caused loss events (see treat reordering events as congestion-caused loss events (see
<xref target="l4sid_sec_reordering_tolerance" format="default"/> for further <xref target="l4sid_sec_reordering_tolerance" format="default"/> for further
rationale). This requirement does not apply to congestion controls rationale). This requirement does not apply to congestion controls
that are solely used in controlled environments where the network that are solely used in controlled environments where the network
introduces hardly any reordering.</li> introduces hardly any reordering.</li>
<li>A scalable congestion control is expected to limit the queue <li anchor="l4sid_Prague_req-burstiness">A Scalable congestion control is expected to limit the queue
caused by bursts of packets. It would not seem necessary to set caused by bursts of packets. It would not seem necessary to set
the limit any lower than 10% of the minimum RTT expected in a the limit any lower than 10% of the minimum RTT expected in a
typical deployment (e.g. additional queuing of roughly 250 us typical deployment (e.g., additional queuing of roughly 250 us
for the public Internet). This would be converted to a number of for the public Internet). This would be converted to a number of
packets by multiplying by the current average packet rate. Then, packets by multiplying by the current average packet rate. Then,
the queue caused by each burst at the bottleneck link would not the queue caused by each burst at the bottleneck link would not
exceed 250us (under the worst-case assumption that the flow is exceed 250 us (under the worst-case assumption that the flow is
filling the capacity). No normative requirement to limit bursts is filling the capacity). No normative requirement to limit bursts is
given here and, until there is more industry experience from the given here, and until there is more industry experience from the
L4S experiment, it is not even known whether one is needed - it L4S experiment, it is not even known whether one is needed -- it
seems to be in an L4S sender's self-interest to limit bursts.</li> seems to be in an L4S sender's self-interest to limit bursts.</li>
</ol> </ol>
<t>Each sender in a session can use a scalable congestion control <t>Each sender in a session can use a Scalable congestion control
independently of the congestion control used by the receiver(s) when independently of the congestion control used by the receiver(s) when
they send data. Therefore, there might be ECT(1) packets in one they send data. Therefore, there might be ECT(1) packets in one
direction and ECT(0) or Not-ECT in the other.</t> direction and ECT(0) or Not-ECT in the other.</t>
<t>Later (<xref target="l4sid_inclusion_dualq" format="default"/>) this document <t>Later, this document
discusses the conditions for mixing other "'Safe' Unresponsive discusses the conditions for mixing other "'Safe' Unresponsive
Traffic" (e.g. DNS, LDAP, NTP, voice, game sync packets) with L4S Traffic" (e.g., DNS, Lightweight Directory Access Protocol (LDAP), NTP,
traffic. To be clear, although such traffic can share the same queue voice, and game sync packets) with L4S
traffic; see <xref target="l4sid_inclusion_dualq" format="default"/>. To
be clear, although such traffic can share the same queue
as L4S traffic, it is not appropriate for the sender to tag it as as L4S traffic, it is not appropriate for the sender to tag it as
ECT(1), except in the (unlikely) case that it satisfies the above ECT(1), except in the (unlikely) case that it satisfies the above
conditions.</t> conditions.</t>
<section anchor="l4sid_congestion_response_rfcs" numbered="true" toc="de fault"> <section anchor="l4sid_congestion_response_rfcs" numbered="true" toc="de fault">
<name>Guidance on Congestion Response in the RFC Series</name> <name>Guidance on Congestion Response in the RFC Series</name>
<t>RFC 3168 requires the congestion responses to a CE-marked <t><xref target="RFC3168"/> requires the congestion responses to a CE-
packet and a dropped packet to be the same. RFC 8311 is a marked
standards-track update to RFC 3168 intended to enable packet and a dropped packet to be the same. <xref target="RFC8311"/> i
s a
Standards Track update to <xref target="RFC3168"/> that is intended to
enable
experimentation with ECN, including the L4S experiment. experimentation with ECN, including the L4S experiment.
RFC 8311 allows an experimental congestion control's response <xref target="RFC8311"/> allows an experimental congestion control's r esponse
to a CE-marked packet to differ from the response to a dropped to a CE-marked packet to differ from the response to a dropped
packet, provided that the differences are documented in an packet, provided that the differences are documented in an
experimental RFC, such as the present document.</t> Experimental RFC, such as the present document.</t>
<t>BCP 124 <xref target="RFC4774" format="default"/> gives guidance to <t>BCP 124 <xref target="RFC4774" format="default"/> gives guidance
protocol designers, when specifying alternative semantics for the to protocol designers, when specifying alternative semantics for the
ECN field. RFC 8311 explained that it did not need to update IP-ECN field. <xref target="RFC8311"/> explained that it did not need
the best current practice in BCP 124 in order to relax the to update the
'equivalence with drop' requirement because, although BCP 124 best current practice in BCP 124 in order to relax the 'equivalence
quotes the same requirement from RFC 3168, the BCP does not with drop' requirement because, although BCP 124 quotes the same
impose requirements based on it. BCP 124 describes three requirement from <xref target="RFC3168"/>, the BCP does not impose req
options for incremental deployment, with Option 3 (in Section 4.3 of uirements
BCP 124) best matching the L4S case. Option 3's requirement for based on it.
end-nodes is that they respond to CE marks "in a way that is
friendly to flows using IETF-conformant congestion control." This BCP 124 <xref target="RFC4774" format="default"/> describes three optio
echoes other general congestion control requirements in the RFC ns for incremental
series, for example <xref target="RFC5033" format="default"/>, which s deployment, with Option 3 (in <xref target="RFC4774" section="4.3"
ays sectionFormat="of">BCP 124</xref>) best matching the L4S
"...congestion controllers that have a significantly negative impact case. Option 3's requirement for end-nodes is that they respond to
on traffic using standard congestion control may be suspect", or CE marks "in a way that is friendly to flows using IETF-conformant
<xref target="RFC8085" format="default"/> concerning UDP congestion co congestion control." This echoes other general congestion control
ntrol says requirements in the RFC Series, for example, <xref target="RFC5033"
format="default"/> states that "...congestion controllers that have
a significantly negative impact on traffic using standard congestion
control may be suspect" and <xref target="RFC8085"
format="default"/>, which concerns UDP congestion control, states that
"Bulk-transfer applications that choose not to implement TFRC or "Bulk-transfer applications that choose not to implement TFRC or
TCP-like windowing SHOULD implement a congestion control scheme that TCP-like windowing <bcp14>SHOULD</bcp14> implement a congestion
results in bandwidth (capacity) use that competes fairly with TCP control scheme that results in bandwidth (capacity) use that
within an order of magnitude."</t> competes fairly with TCP within an order of magnitude."</t>
<t>The third normative bullet in <xref target="l4sid_congestion_respon
se" format="default"/> above (which concerns L4S <t>The normative Item <xref target="l4sid_Prague_req-classic-ecn-respo
nse" format="counter"/> in <xref target="l4sid_congestion_response" format="defa
ult"/> above (which concerns L4S
response to congestion from a Classic ECN AQM) aims to ensure that response to congestion from a Classic ECN AQM) aims to ensure that
these 'coexistence' requirements are satisfied, but it makes some these 'coexistence' requirements are satisfied, but it makes some
compromises. This subsection highlights and justifies those compromises. This subsection highlights and justifies those
compromises and <xref target="l4sid_sec_fallback_on_classic_CE" format compromises, and <xref target="l4sid_sec_fallback_on_classic_CE" forma
="default"/> t="default"/>
and the L4S operational guidance <xref target="I-D.ietf-tsvwg-l4sops" and the L4S operational guidance <xref target="I-D.ietf-tsvwg-l4sops"
format="default"/> give detailed analysis, examples format="default"/> give detailed analysis, examples,
and references (the normative text in that bullet takes precedence and references (the normative text in that bullet takes precedence
if any informative elaboration leads to ambiguity). The approach is if any informative elaboration leads to ambiguity). The approach is
based on an assessment of the risk of harm, which is a combination based on an assessment of the risk of harm, which is a combination
of the prevalence of the conditions necessary for harm to occur, and of the prevalence of the conditions necessary for harm to occur, and
the potential severity of the harm if they do. </t> the potential severity of the harm if they do. </t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Prevalence:</dt> <dt>Prevalence:</dt>
<dd> <dd>
<t>There are three cases:</t> <t>There are three cases:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Drop Tail: Coexistence between L4S and Classic flows is <li>Drop Tail: Coexistence between L4S and Classic flows is
not in doubt where the bottleneck does not support any form not in doubt where the bottleneck does not support any form
of ECN, which has remained by far the most prevalent case of ECN, which has remained by far the most prevalent case
since the ECN RFC was published in 2001.</li> since the ECN spec <xref target="RFC3168" format="default"/> w as published in 2001.</li>
<li>L4S: Coexistence is not in doubt if the bottleneck <li>L4S: Coexistence is not in doubt if the bottleneck
supports L4S.</li> supports L4S.</li>
<li> <li>
<t>Classic ECN <xref target="RFC3168" format="default"/>: The <t>Classic ECN: The
compromises centre around cases where the bottleneck compromises centre around cases where the bottleneck
supports Classic ECN but not L4S. But it depends on which supports Classic ECN <xref target="RFC3168" format="default"/>
sub-case:</t> but not L4S.
But it depends on which sub-case:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Shared Queue with Classic ECN: At the time of <li>Shared Queue with Classic ECN: At the time of
writing, the members of the Transport Working group are writing, the members of the Transport Working Group are
not aware of any current deployments of single-queue not aware of any current deployments of single-queue
Classic ECN bottlenecks in the Internet. Nonetheless, at Classic ECN bottlenecks in the Internet. Nonetheless, at
the scale of the Internet, rarity need not imply small the scale of the Internet, rarity need not imply small
numbers, nor that there will be rarity in the numbers nor that there will be rarity in the
future.</li> future.</li>
<li> <li>
<t>Per-Flow-queues with Classic ECN: Most AQMs with <t>Per-Flow Queues with Classic ECN: Most AQMs with
per-flow-queuing (FQ) deployed from 2012 onwards had per-flow queuing deployed from 2012 onwards had
Classic ECN enabled by default, specifically Classic ECN enabled by default, specifically
FQ-CoDel <xref target="RFC8290" format="default"/> and FQ-CoDel <xref target="RFC8290" format="default"/> and
COBALT <xref target="COBALT" format="default"/>. But the c COBALT <xref target="COBALT" format="default"/>. But the c
ompromises ompromises
only apply to the second of two further sub-cases:</t> only apply to the second of two further sub-cases:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>With per-flow-queuing, co-existence between <li>With per-flow queuing, coexistence between
Classic and L4S flows is not normally a problem, Classic and L4S flows is not normally a problem,
because different flows are not meant to be in the because different flows are not meant to be in the
same queue (BCP 124 <xref target="RFC4774" format="def same queue (BCP 124 <xref target="RFC4774" format="def
ault"/> did not foresee the introduction ault"/> did not foresee the introduction
of per-flow-queuing, which appeared as a potential of per-flow queuing, which appeared as a potential
isolation technique some eight years after the BCP isolation technique some eight years after the BCP
was published).</li> was published).</li>
<li>However, the isolation between L4S and Classic <li>However, the isolation between L4S and Classic
flows is not perfect in cases where the hashes of flows is not perfect in cases where the hashes of
flow IDs collide or where multiple flows within a flow identifiers (IDs) collide or where multiple flows
layer-3 VPN are encapsulated within one flow ID.</li> within a
Layer 3 VPN are encapsulated within one flow ID.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>To summarize, the coexistence problem is confined to <t>To summarize, the coexistence problem is confined to
cases of imperfect flow isolation in an FQ, or in potential cases of imperfect flow isolation in an FQ or in potential
cases where a Classic ECN AQM has been deployed in a shared cases where a Classic ECN AQM has been deployed in a shared
queue (see the L4S operational guidance <xref target="I-D.ietf-tsv wg-l4sops" format="default"/> for further details including queue (see the L4S operational guidance <xref target="I-D.ietf-tsv wg-l4sops" format="default"/> for further details including
recent surveys attempting to quantify prevalence). Further, if recent surveys attempting to quantify prevalence). Further, if
one of these cases does occur, the coexistence problem does not one of these cases does occur, the coexistence problem does not
arise unless sources of Classic and L4S flows are simultaneously arise unless sources of Classic and L4S flows are simultaneously
sharing the same bottleneck queue (e.g. different sharing the same bottleneck queue (e.g., different
applications in the same household) and flows of each type have applications in the same household), and flows of each type have
to be large enough to coincide for long enough for any to be large enough to coincide for long enough for any
throughput imbalance to have developed. Therefore, how often the throughput imbalance to have developed. Therefore, how often the
coexistence problem arises in practice is listed in <xref target=" l4sid_expts" format="default"/> as an open question that L4S experiments coexistence problem arises in practice is listed in <xref target=" l4sid_expts" format="default"/> as an open question that L4S experiments
will need to answer.</t> will need to answer.</t>
</dd> </dd>
<dt>Severity:</dt> <dt>Severity:</dt>
<dd>Where long-running L4S and Classic flows <dd>Where long-running L4S and Classic flows
coincide in a shared queue, testing of one L4S congestion coincide in a shared queue, testing of one L4S congestion
control (TCP Prague) has found that the imbalance in average control (TCP Prague) has found that the imbalance in average
throughput between an L4S and a Classic flow can reach 25:1 in throughput between an L4S and a Classic flow can reach 25:1 in
favour of L4S in the worst case <xref target="ecn-fallback" format ="default"/>. However, when capacity is most scarce, favour of L4S in the worst case <xref target="ecn-fallback" format ="default"/>. However, when capacity is most scarce,
the Classic flow gets a higher proportion of the link, for the Classic flow gets a higher proportion of the link, for
instance over a 4 Mb/s link the throughput ratio is below ~10:1 instance, over a 4 Mb/s link the throughput ratio is below ~10:1
over paths with a base RTT below 100 ms, and falls below ~5:1 over paths with a base RTT below 100 ms, and it falls below ~5:1
for base RTTs below 20ms.</dd> for base RTTs below 20 ms.</dd>
</dl> </dl>
<t>These throughput ratios can clearly fall well outside current RFC <t>These throughput ratios can clearly fall well outside current RFC
guidance on coexistence. However, the tendency towards leaving a guidance on coexistence. However, the tendency towards leaving a
greater share for Classic flows at lower link rate and the very greater share for Classic flows at lower link rate and the very
limited prevalence of the conditions necessary for harm to occur led limited prevalence of the conditions necessary for harm to occur led
to the possibility of allowing the RFC requirements to be to the possibility of allowing the RFC requirements to be
compromised, albeit briefly:</t> compromised, albeit briefly:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The recommended approach is still to detect and adapt to a <li>The recommended approach is still to detect and adapt to a
Classic ECN AQM in real-time, which is fully consistent with all Classic ECN AQM in real time, which is fully consistent with all
the RFCs on coexistence. In other words, the "SHOULD"s in the the RFCs on coexistence. In other words, the "<bcp14>SHOULD</bcp14
third bullet of <xref target="l4sid_congestion_response" format="d >"s in
efault"/> above Item <xref target="l4sid_Prague_req-classic-ecn-response" format="
expect the sender to implement something similar to the proof of counter"/> of <xref target="l4sid_congestion_response" format="default"/> above
concept code that detects the presence of a Classic ECN AQM and expect the sender to implement something similar to the proof-of-c
oncept
code that detects the presence of a Classic ECN AQM and
falls back to a Classic congestion response within a few round falls back to a Classic congestion response within a few round
trips <xref target="ecn-fallback" format="default"/>. However, alt hough this trips <xref target="ecn-fallback" format="default"/>. However, alt hough this
code reliably detects a Classic ECN AQM, the current code can code reliably detects a Classic ECN AQM, the current code can
also wrongly categorize an L4S AQM as Classic, most often in also wrongly categorize an L4S AQM as Classic, most often in
cases when link rate is low or RTT is high. Although this is the cases when link rate is low or RTT is high. Although this is the
safe way round, and although implementers are expected to be safe way round, and although implementers are expected to be
able to improve on this proof of concept, concerns have been able to improve on this proof of concept, concerns have been
raised that implementers might lose faith in such detection and raised that implementers might lose faith in such detection and
disable it.</li> disable it.</li>
<li>Therefore the third bullet in <xref target="l4sid_congestion_res <li>Item <xref target="l4sid_Prague_req-classic-ecn-response" format
ponse" format="default"/> above allows a compromise ="counter"/> in <xref target="l4sid_congestion_response" format="default"/> abov
where coexistence could diverge from the requirements in the RFC e therefore allows a compromise
Series briefly, but mandatory monitoring is required, in order where coexistence could briefly diverge from the requirements in t
he RFC
Series, but mandatory monitoring is required in order
to detect such cases and trigger remedial action. This approach to detect such cases and trigger remedial action. This approach
tolerates a brief divergence from the RFCs given the likely low tolerates a brief divergence from the RFCs given the likely low
prevalence and given harm here means a flow progresses more prevalence and given harm here means a flow progresses more
slowly than otherwise, but it does progress. The L4S operational slowly than it would otherwise, but it does progress. The L4S oper
guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/> o ational
utlines a guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/> o
range of example remedial actions that include alterations utlines a
either to the sender or to the network. However, the final range of example remedial actions that include alterations to
normative requirement in the third bullet of <xref target="l4sid_c either the sender or the network. However, the final
ongestion_response" format="default"/> above places ultimate normative requirement in Item <xref target="l4sid_Prague_req-class
ic-ecn-response" format="counter"/> of <xref target="l4sid_congestion_response"
format="default"/> above places ultimate
responsibility for remedial action on the sender. If coexistence responsibility for remedial action on the sender. If coexistence
problems with a Classic ECN AQM are detected (implying they have problems with a Classic ECN AQM are detected (implying they have
not been resolved by the network), it says the sender "MUST" not been resolved by the network), it states that the sender "<bcp
revert to a Classic congestion control."</li> 14>MUST</bcp14>"
revert to a Classic congestion control.</li>
</ul> </ul>
<t><xref target="I-D.ietf-tsvwg-l4sops" format="default"/> also gives example <t><xref target="I-D.ietf-tsvwg-l4sops" format="default"/> also gives example
ways in which L4S congestion controls can be rolled out initially in ways in which L4S congestion controls can be rolled out initially in
lower risk scenarios.</t> lower-risk scenarios.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Filtering or Smoothing of ECN Feedback</name> <name>Filtering or Smoothing of ECN Feedback</name>
<t><xref target="l4sid_Semantics" format="default"/> below specifies tha t an L4S AQM is <t><xref target="l4sid_Semantics" format="default"/> below specifies tha t an L4S AQM is
expected to signal L4S ECN immediately, to avoid introducing delay due expected to signal L4S ECN immediately, to avoid introducing delay due
to filtering or smoothing. This contrasts with a Classic AQM, which to filtering or smoothing. This contrasts with a Classic AQM, which
filters out variations in the queue before signalling ECN marking or filters out variations in the queue before signalling ECN marking or
drop. In the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" for mat="default"/>, responsibility for smoothing out drop. In the L4S architecture <xref target="RFC9330" format="default"/>, responsibility for smoothing out
these variations shifts to the sender's congestion control.</t> these variations shifts to the sender's congestion control.</t>
<t>This shift of responsibility has the advantage that each sender can <t>This shift of responsibility has the advantage that each sender can
smooth variations over a timescale proportionate to its own RTT. smooth variations over a timescale proportionate to its own RTT.
Whereas, in the Classic approach, the network doesn't know the RTTs of Whereas, in the Classic approach, the network doesn't know the RTTs of
any of the flows, so it has to smooth out variations for a worst-case any of the flows, so it has to smooth out variations for a worst-case
RTT to ensure stability. For all the typical flows with shorter RTT RTT to ensure stability. For all the typical flows with shorter RTTs
than the worst-case, this makes congestion control unnecessarily than the worst-case, this makes congestion control unnecessarily
sluggish.</t> sluggish.</t>
<t>This also gives an L4S sender the choice not to smooth, depending <t>This also gives an L4S sender the choice not to smooth, depending
on its context (start-up, congestion avoidance, etc.). Therefore, this on its context (start-up, congestion avoidance, etc.). Therefore, this
document places no requirement on an L4S congestion control to smooth document places no requirement on an L4S congestion control to smooth
out variations in any particular way. Implementers are encouraged to out variations in any particular way. Implementers are encouraged to
openly publish the approach they take to smoothing, and the results openly publish the approach they take to smoothing as well as results
and experience they gain during the L4S experiment.</t> and experience they gain during the L4S experiment.</t>
</section> </section>
</section> </section>
<section anchor="l4sid_network_req" numbered="true" toc="default"> <section anchor="l4sid_network_req" numbered="true" toc="default">
<name>Network Node Behaviour</name> <name>Network Node Behaviour</name>
<t/>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Classification and Re-Marking Behaviour</name> <name>Classification and Re-Marking Behaviour</name>
<t>A network node that implements the L4S service:</t> <t>A network node that implements the L4S service:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>MUST classify arriving ECT(1) packets for L4S treatment, unless <li><bcp14>MUST</bcp14> classify arriving ECT(1) packets for L4S treat
overridden by another classifier (e.g., see <xref target="l4sid_excl ment, unless
usion_dualq" format="default"/>);</li> overridden by another classifier (e.g., see <xref target="l4sid_excl
usion_dualq" format="default"/>).</li>
<li> <li>
<t>MUST classify arriving CE packets for L4S treatment as well, <t><bcp14>MUST</bcp14> classify arriving CE packets for L4S treatmen t as well,
unless overridden by another classifier or unless the exception unless overridden by another classifier or unless the exception
referred to next applies;</t> referred to next applies.</t>
<t>CE packets might <t>CE packets might
have originated as ECT(1) or ECT(0), but the above rule to have originated as ECT(1) or ECT(0), but the above rule to
classify them as if they originated as ECT(1) is the safe choice classify them as if they originated as ECT(1) is the safe choice
(see <xref target="l4sid_ECT1_CE" format="default"/> for rationale). The exception (see <xref target="l4sid_ECT1_CE" format="default"/> for rationale). The exception
is where some flow-aware in-network mechanism happens to be is where some flow-aware in-network mechanism happens to be
available for distinguishing CE packets that originated as ECT(0), available for distinguishing CE packets that originated as ECT(0),
as described in <xref target="l4sid_identification_transport_aware" format="default"/>, but there is no as described in <xref target="l4sid_identification_transport_aware" format="default"/>, but there is no
implication that such a mechanism is necessary.</t> implication that such a mechanism is necessary.</t>
</li> </li>
</ul> </ul>
<t>An L4S AQM treatment follows similar codepoint transition rules to <t>An L4S AQM treatment follows similar codepoint transition rules to
those in RFC 3168. Specifically, the ECT(1) codepoint MUST NOT be those in <xref target="RFC3168"/>. Specifically, the ECT(1) codepoint <b
changed to any other codepoint than CE, and CE MUST NOT be changed to cp14>MUST NOT</bcp14> be
any other codepoint. An ECT(1) packet is classified as ECN-capable changed to any codepoint other than CE, and CE <bcp14>MUST NOT</bcp14> b
and, if congestion increases, an L4S AQM algorithm will increasingly e changed to
mark the ECN field as CE, otherwise forwarding packets unchanged as any other codepoint. An ECT(1) packet is classified as 'ECN-capable',
and if congestion increases, an L4S AQM algorithm will increasingly
mark the IP-ECN field as CE, otherwise forwarding packets unchanged as
ECT(1). Necessary conditions for an L4S marking treatment are defined ECT(1). Necessary conditions for an L4S marking treatment are defined
in <xref target="l4sid_Semantics" format="default"/>.</t> in <xref target="l4sid_Semantics" format="default"/>.</t>
<t>Under persistent overload an L4S marking treatment MUST begin <t>Under persistent overload, an L4S marking treatment
applying drop to L4S traffic until the overload episode has subsided, <bcp14>MUST</bcp14> begin applying drop to L4S traffic until the
as recommended for all AQM methods in <xref target="RFC7567" format="def overload episode has subsided, as recommended for all AQM methods in
ault"/> <xref target="RFC7567" sectionFormat="of" section="4.2.1"/>, which
(Section 4.2.1), which follows the similar advice in RFC 3168 follows the similar advice in <xref target="RFC3168"
(Section 7). During overload, it MUST apply the same drop probability sectionFormat="of" section="7"/>. During overload, it
to L4S traffic as it would to Classic traffic.</t> <bcp14>MUST</bcp14> apply the same drop probability to L4S traffic as
it would to Classic traffic.</t>
<t>Where an L4S AQM is transport-aware, this requirement could be <t>Where an L4S AQM is transport-aware, this requirement could be
satisfied by using drop in only the most overloaded individual satisfied by using drop in only the most overloaded individual
per-flow AQMs. In a DualQ with flow-aware queue protection per-flow AQMs. In a DualQ with flow-aware queue protection
(e.g. <xref target="I-D.briscoe-docsis-q-protection" format="default"/>) , this (e.g., <xref target="I-D.briscoe-docsis-q-protection" format="default"/> ), this
could be achieved by redirecting packets in those flows contributing could be achieved by redirecting packets in those flows contributing
most to the overload out of the L4S queue so that they are subjected most to the overload out of the L4S queue so that they are subjected
to drop in the Classic queue.</t> to drop in the Classic queue.</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>For backward compatibility in uncontrolled environments, a network <t>For backward compatibility in uncontrolled environments, a network
node that implements the L4S treatment MUST also implement an AQM node that implements the L4S treatment <bcp14>MUST</bcp14> also implemen t an AQM
treatment for the Classic service as defined in <xref target="l4sid_Term inology" format="default"/>. This Classic AQM treatment need not mark treatment for the Classic service as defined in <xref target="l4sid_Term inology" format="default"/>. This Classic AQM treatment need not mark
ECT(0) packets, but if it does, see <xref target="l4sid_Semantics" forma t="default"/> ECT(0) packets, but if it does, see <xref target="l4sid_Semantics" forma t="default"/>
for the strengths of the markings relative to drop. It MUST classify for the strengths of the markings relative to drop. It <bcp14>MUST</bcp1 4> classify
arriving ECT(0) and Not-ECT packets for treatment by this Classic AQM arriving ECT(0) and Not-ECT packets for treatment by this Classic AQM
(for the DualQ Coupled AQM, see the extensive discussion on (for the DualQ Coupled AQM; see the extensive discussion on
classification in Sections 2.3 and 2.5.1.1 of <xref target="I-D.ietf-tsv classification in Sections <xref target="RFC9332" section="2.3"
wg-aqm-dualq-coupled" format="default"/>).</t> sectionFormat="bare"/> and <xref target="RFC9332" section="2.5.1.1"
<t>In case unforeseen problems arise with the L4S experiment, it MUST sectionFormat="bare"/> of <xref target="RFC9332" format="default"/>).</t>
<t>In case unforeseen problems arise with the L4S experiment, it <bcp14>
MUST</bcp14>
be possible to configure an L4S implementation to disable the L4S be possible to configure an L4S implementation to disable the L4S
treatment. Once disabled, all packets of all ECN codepoints will treatment.
receive Classic treatment and ECT(1) packets MUST be treated as if Once disabled, ECT(1) packets <bcp14>MUST</bcp14> be treated as if
they were Not-ECT.</t> they were Not-ECT.</t>
</section> </section>
<section anchor="l4sid_Semantics" numbered="true" toc="default"> <section anchor="l4sid_Semantics" numbered="true" toc="default">
<name>The Strength of L4S CE Marking Relative to Drop</name> <name>The Strength of L4S CE Marking Relative to Drop</name>
<t>The relative strengths of L4S CE and drop are irrelevant where AQMs <t>The relative strengths of L4S CE and drop are irrelevant where AQMs
are implemented in separate queues per-application-flow, which are are implemented in separate queues per application-flow, which are
then explicitly scheduled (e.g. with an FQ scheduler as in then explicitly scheduled (e.g., with an FQ scheduler as in
FQ-CoDel <xref target="RFC8290" format="default"/>). Nonetheless, the re FQ-CoDel <xref target="RFC8290" format="default"/>). Nonetheless, the re
lationship lationship
between them needs to be defined for the coupling between L4S and between them needs to be defined for the coupling between L4S and
Classic congestion signals in a DualQ Coupled AQM <xref target="I-D.ietf -tsvwg-aqm-dualq-coupled" format="default"/>, as below.</t> Classic congestion signals in a DualQ Coupled AQM <xref target="RFC9332" format="default"/>, as indicated below.</t>
<t>Unless an AQM node schedules application flows explicitly, the <t>Unless an AQM node schedules application flows explicitly, the
likelihood that the AQM drops a Not-ECT Classic packet (p_C) MUST be likelihood that the AQM drops a Not-ECT Classic packet (p_C) <bcp14>MUST </bcp14> be
roughly proportional to the square of the likelihood that it would 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</t> have marked it if it had been an L4S packet (p_L). That is:</t>
<ul empty="true" spacing="normal">
<li>p_C ~= (p_L / k)^2</li> <t indent="3">p_C ~= (p_L / k)<sup>2</sup></t>
</ul>
<t>The constant of proportionality (k) does not have to be <t>The constant of proportionality (k) does not have to be
standardized for interoperability, but a value of 2 is RECOMMENDED. standardized for interoperability, but a value of 2 is <bcp14>RECOMMENDE D</bcp14>.
The term 'likelihood' is used above to allow for marking and dropping The term 'likelihood' is used above to allow for marking and dropping
to be either probabilistic or deterministic.</t> to be either probabilistic or deterministic.</t>
<t>This formula ensures that Scalable and Classic flows will converge <t>This formula ensures that Scalable and Classic flows will converge
to roughly equal congestion windows, for the worst case of Reno to roughly equal congestion windows, for the worst case of Reno
congestion control. This is because the congestion windows of Scalable congestion control. This is because the congestion windows of Scalable
and Classic congestion controls are inversely proportional to p_L and and Classic congestion controls are inversely proportional to p_L and
sqrt(p_C) respectively. So squaring p_C in the above formula sqrt(p_C), respectively. So squaring p_C in the above formula
counterbalances the square root that characterizes Reno-friendly counterbalances the square root that characterizes Reno-friendly
flows.</t> flows.</t>
<t>Note that, contrary to RFC 3168, an AQM implementing the L4S <aside><t>Note that, contrary to <xref target="RFC3168" format="default" />, an AQM implementing the L4S
and Classic treatments does not mark an ECT(1) packet under the same and Classic treatments does not mark an ECT(1) packet under the same
conditions that it would have dropped a Not-ECT packet, as allowed by conditions that it would have dropped a Not-ECT packet, as allowed by
<xref target="RFC8311" format="default"/>, which updates RFC 3168. Howev <xref target="RFC8311" format="default"/>, which updates <xref target="R
er, if it FC3168" format="default"/>.
marks ECT(0) packets, it does so under the same conditions that it However, if it
would have dropped a Not-ECT packet <xref target="RFC3168" format="defau marks ECT(0) packets, it does so under the same conditions that it would
lt"/>.<!--KDS: replace "a Not-ECT packet" have dropped a
by "a packet", as any drop should be classic, and also ECT(0),(1) or CE Not-ECT packet <xref target="RFC3168" format="default"/>.
packets can be dropped
BB: But that's not the intended meaning. Yes, a packet with any ECN field can be </t></aside>
dropped, but this rule is just about <t>Also, in the L4S architecture <xref target="RFC9330" format="default"
what /would/ have been done /if/ the ECN field had been one specific value (Not- />, the sender, not the network, is
ECT). responsible for smoothing out variations in the queue. So an L4S AQM
</t> <bcp14>MUST</bcp14> signal congestion as soon as possible. Then, an L4S
<t>Also, In the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" sender
format="default"/>, the sender, not the network, is
responsible for smoothing out variations in the queue. So, an L4S AQM
MUST signal congestion as soon as possible. Then, an L4S sender
generally interprets CE marking as an unsmoothed signal.</t> generally interprets CE marking as an unsmoothed signal.</t>
<t>This requirement does not prevent an L4S AQM from mixing in <t>This requirement does not prevent an L4S AQM from mixing in
additional congestion signals that are smoothed, such as the signals additional congestion signals that are smoothed, such as the signals
from a Classic smoothed AQM that are coupled with unsmoothed L4S from a Classic smoothed AQM that are coupled with unsmoothed L4S
signals in the coupled DualQ <xref target="I-D.ietf-tsvwg-aqm-dualq-coup signals in the coupled DualQ <xref target="RFC9332" format="default"/>,
led" format="default"/>. But only as long as the but only as long as the
onset of congestion can be signalled immediately, and can be onset of congestion can be signalled immediately and can be
interpreted by the sender as if it has been signalled immediately, interpreted by the sender as if it has been signalled immediately,
which is important for interoperability</t> which is important for interoperability</t>
</section> </section>
<section anchor="l4sid_identification_transport_aware" numbered="true" toc ="default"> <section anchor="l4sid_identification_transport_aware" numbered="true" toc ="default">
<name>Exception for L4S Packet Identification by Network Nodes with Tran sport-Layer Awareness</name> <name>Exception for L4S Packet Identification by Network Nodes with Tran sport-Layer Awareness</name>
<!--This section doesn't fit very well here. It would be better as an Ap
pendix, 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 detri
mental 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 L4S packet classification, a network node does not <t>To implement L4S packet classification, a network node does not
need to identify transport-layer flows. Nonetheless, if an L4S network need to identify transport-layer flows. Nonetheless, if an L4S network
node classifies packets by their transport-layer flow ID and their ECN node classifies packets by their transport-layer flow ID and their ECN
field, and if all the ECT packets in a flow have been ECT(0), the node field, and if all the ECT packets in a flow have been ECT(0), the node
MAY classify any CE packets in the same flow as if they were Classic <bcp14>MAY</bcp14> classify any CE packets in the same flow as if they w
ECT(0) packets. In all other cases, a network node MUST classify all ere Classic
ECT(0) packets. In all other cases, a network node <bcp14>MUST</bcp14> c
lassify all
CE packets as if they were ECT(1) packets. Examples of such other CE packets as if they were ECT(1) packets. Examples of such other
cases are: i) if no ECT packets have yet been identified in a flow; 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 ii) if it is not desirable for a network node to identify
transport-layer flows; or iii) if some ECT packets in a flow have been transport-layer flows; or iii) if some ECT packets in a flow have been
ECT(1) (this advice will need to be verified as part of L4S ECT(1) (this advice will need to be verified as part of L4S
experiments).</t> experiments).</t>
</section> </section>
<section anchor="l4sid_other_IDs" numbered="true" toc="default"> <section anchor="l4sid_other_IDs" numbered="true" toc="default">
<name>Interaction of the L4S Identifier with other Identifiers</name> <name>Interaction of the L4S Identifier with Other Identifiers</name>
<t>The examples in this section concern how additional identifiers <t>The examples in this section concern how additional identifiers
might complement the L4S identifier to classify packets between might complement the L4S identifier to classify packets between
class-based queues. Firstly <xref target="l4sid_iother_IDs_dualq" format class-based queues. Firstly, <xref target="l4sid_iother_IDs_dualq" forma
="default"/> t="default"/>
considers two queues, L4S and Classic, as in the Coupled DualQ considers two queues, L4S and Classic, as in the DualQ Coupled
AQM <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" format="default"/>, AQM <xref target="RFC9332" format="default"/>, either
either
alone (<xref target="l4sid_inclusion_dualq" format="default"/>) or withi n a larger alone (<xref target="l4sid_inclusion_dualq" format="default"/>) or withi n a larger
queuing hierarchy (<xref target="l4sid_exclusion_dualq" format="default" />). Then <xref target="l4sid_iother_IDs_fq" format="default"/> considers scheme s that might combine queuing hierarchy (<xref target="l4sid_exclusion_dualq" format="default" />). Then, <xref target="l4sid_iother_IDs_fq" format="default"/> considers schem es that might combine
per-flow 5-tuples with other identifiers.</t> per-flow 5-tuples with other identifiers.</t>
<section anchor="l4sid_iother_IDs_dualq" numbered="true" toc="default"> <section anchor="l4sid_iother_IDs_dualq" numbered="true" toc="default">
<name>DualQ Examples of Other Identifiers Complementing L4S Identifier s</name> <name>DualQ Examples of Other Identifiers Complementing L4S Identifier s</name>
<t/>
<section anchor="l4sid_inclusion_dualq" numbered="true" toc="default"> <section anchor="l4sid_inclusion_dualq" numbered="true" toc="default">
<name>Inclusion of Additional Traffic with L4S</name> <name>Inclusion of Additional Traffic with L4S</name>
<t>In a typical case for the public Internet a network element <t>In a typical case for the public Internet, a network element
that implements L4S in a shared queue might want to classify some that implements L4S in a shared queue might want to classify some
low-rate but unresponsive traffic (e.g. DNS, LDAP, NTP, low-rate but unresponsive traffic (e.g., DNS, LDAP, NTP,
voice, game sync packets) into the low latency queue to mix with voice, and game sync packets) into the low-latency queue to mix with
L4S traffic. In this case it would not be appropriate to call the L4S traffic. In this case, it would not be appropriate to call the
queue an L4S queue, because it is shared by L4S and non-L4S queue an L4S queue, because it is shared by L4S and non-L4S
traffic. Instead, it will be called the low latency or L queue. traffic. Instead, it will be called the low-latency or L queue.
The L queue then offers two different treatments:</t> The L queue then offers two different treatments:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The L4S treatment, which is a combination of the L4S AQM <li>the L4S treatment, which is a combination of the L4S AQM
treatment and a priority scheduling treatment;</li> treatment and a priority scheduling treatment, and</li>
<li>The low latency treatment, which is solely the priority <li>the low-latency treatment, which is solely the priority
scheduling treatment, without ECN-marking by the AQM.</li> scheduling treatment, without ECN marking by the AQM.</li>
</ul> </ul>
<t>To identify packets for just the scheduling treatment, it would <t>To identify packets for just the scheduling treatment, it would
be inappropriate to use the L4S ECT(1) identifier, because such be inappropriate to use the L4S ECT(1) identifier, because such
traffic is unresponsive to ECN marking. Examples of relevant traffic is unresponsive to ECN marking. Examples of relevant
non-ECN identifiers are:</t> non-ECN identifiers are:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>address ranges of specific applications or hosts configured <li>address ranges of specific applications or hosts configured
to be, or known to be, safe, e.g. hard-coded IoT devices to be, or known to be, safe, e.g., hard-coded Internet of Things
sending low intensity traffic;</li> (IoT) devices
sending low-intensity traffic;</li>
<li>certain low data-volume applications or protocols <li>certain low data-volume applications or protocols
(e.g. ARP, DNS);</li> (e.g., ARP and DNS); and</li>
<li>specific Diffserv codepoints that indicate traffic with <li>specific Diffserv codepoints that indicate traffic with
limited burstiness such as the EF (Expedited limited burstiness such as the EF <xref target="RFC3246" format=
Forwarding <xref target="RFC3246" format="default"/>), "default"/>,
Voice-Admit <xref target="RFC5865" format="default"/> or propose VOICE-ADMIT <xref target="RFC5865" format="default"/>, or propos
d NQB ed
(Non-Queue-Building <xref target="I-D.ietf-tsvwg-nqb" format="de Non-Queue-Building (NQB) <xref target="I-D.ietf-tsvwg-nqb" forma
fault"/>) t="default"/>
service classes or equivalent local-use DSCPs (see <xref target= service classes or equivalent Local-use DSCPs (see <xref target=
"I-D.briscoe-tsvwg-l4s-diffserv" format="default"/>).</li> "I-D.briscoe-tsvwg-l4s-diffserv" format="default"/>).</li>
</ul> </ul>
<t>To be clear, classifying into the L queue based on application <t>To be clear, classifying into the L queue based on application-la
layer identification (e.g. DNS) is an example of a local yer
identification (e.g., DNS) is an example of a local
optimization, not a recommendation. Applications will not be able optimization, not a recommendation. Applications will not be able
to rely on such unsolicited optimization. A more reliable approach to rely on such unsolicited optimization. A more reliable approach
would be for the sender to set an appropriate IP layer identifier, would be for the sender to set an appropriate IP-layer identifier,
such as one of the above Diffserv codepoints.</t> such as one of the above Diffserv codepoints.</t>
<t>In summary, a network element that implements L4S in a shared <t>In summary, a network element that implements L4S in a shared
queue MAY classify additional types of packets into the L queue queue <bcp14>MAY</bcp14> classify additional types of packets into t
based on identifiers other than the ECN field, but the types he L queue
SHOULD be 'safe' to mix with L4S traffic, where 'safe' is based on identifiers other than the IP-ECN field, but the types
<bcp14>SHOULD</bcp14> be 'safe' to mix with L4S traffic, where 'safe
' is
explained in <xref target="l4sid_safe_unresponsive" format="default" />.</t> explained in <xref target="l4sid_safe_unresponsive" format="default" />.</t>
<t>A packet that carries one of these non-ECN identifiers to <t>A packet that carries one of these non-ECN identifiers to
classify it into the L queue would not be subject to the L4S ECN classify it into the L queue would not be subject to the L4S ECN-mar
marking treatment, unless it also carried an ECT(1) or CE king
codepoint. The specification of an L4S AQM MUST define the treatment, unless it also carried an ECT(1) or CE
codepoint.
The specification of an L4S AQM <bcp14>MUST</bcp14> define the
behaviour for packets with unexpected combinations of codepoints, behaviour for packets with unexpected combinations of codepoints,
e.g. a non-ECN-based classifier for the L queue, but ECT(0) e.g., a non-ECN-based classifier for the L queue but with ECT(0)
in the ECN field (for examples see section 2.5.1.1 of the DualQ in the IP-ECN field (for examples with appropriate behaviours, see S
spec <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" format="default ection <xref target="RFC9332" section="2.5.1.1"
"/>).</t> sectionFormat="bare"/> of the DualQ
spec <xref target="RFC9332" format="default"/>).</t>
<t>For clarity, non-ECN identifiers, such as the examples itemized <t>For clarity, non-ECN identifiers, such as the examples itemized
above, might be used by some network operators who believe they above, might be used by some network operators who believe they
identify non-L4S traffic that would be safe to mix with L4S identify non-L4S traffic that would be safe to mix with L4S
traffic. They are not alternative ways for a host to indicate that traffic. They are not alternative ways for a host to indicate that
it is sending L4S packets. Only the ECT(1) ECN codepoint indicates it is sending L4S packets.
Only the ECT(1) ECN codepoint indicates
to a network element that a host is sending L4S packets (and CE to a network element that a host is sending L4S packets (and CE
indicates that it could have originated as ECT(1)). Specifically indicates that it could have originated as ECT(1)). Specifically,
ECT(1) indicates that the host claims its behaviour satisfies the ECT(1) indicates that the host claims its behaviour satisfies the
prerequisite transport requirements in <xref target="l4sid_transport _req" format="default"/>.</t> prerequisite transport requirements in <xref target="l4sid_transport _req" format="default"/>.</t>
<t>In order to include non-L4S packets in the L queue, a network
node MUST NOT alter Not-ECT or ECT(0) in the IP-ECN field to an <t>In order to include non-L4S packets in the L queue, a network
node <bcp14>MUST NOT</bcp14> change Not-ECT or ECT(0) in the IP-ECN
field into an
L4S identifier. This ensures that these codepoints survive for any L4S identifier. This ensures that these codepoints survive for any
potential use later on the network path. If a non-compliant or potential use later on the network path. If a non-compliant or
malicious network node did swap ECT(0) to ECT(1), the packet could malicious network node did swap ECT(0) to ECT(1), the packet could
subsequently be ECN-marked by a downstream L4S AQM, but the sender subsequently be ECN-marked by a downstream L4S AQM, but the sender
would respond to congestion indications thinking it had sent a would respond to congestion indications thinking it had sent a
Classic packet. This could result in the flow yielding excessively Classic packet. This could result in the flow yielding excessively
to other L4S flows sharing the downstream bottleneck.</t> to other L4S flows sharing the downstream bottleneck.</t>
<section anchor="l4sid_safe_unresponsive" numbered="true" toc="defau lt"> <section anchor="l4sid_safe_unresponsive" numbered="true" toc="defau lt">
<name>'Safe' Unresponsive Traffic</name> <name>'Safe' Unresponsive Traffic</name>
<t>The above section requires unresponsive traffic to be 'safe' <t>The above section requires unresponsive traffic to be 'safe'
to mix with L4S traffic. Ideally this means that the sender to mix with L4S traffic. Ideally, this means that the sender
never sends any sequence of packets at a rate that exceeds the never sends any sequence of packets at a rate that exceeds the
available capacity of the bottleneck link. However, typically an available capacity of the bottleneck link. However, typically an
unresponsive transport does not even know the bottleneck unresponsive transport does not even know the bottleneck
capacity of the path, let alone its available capacity. capacity of the path, let alone its available capacity.
Nonetheless, an application can be considered safe enough if it Nonetheless, an application can be considered safe enough if it
paces packets out (not necessarily completely regularly) such paces packets out (not necessarily with absolute regularity) such
that its maximum instantaneous rate from packet to packet stays that its maximum instantaneous rate from packet to packet stays
well below a typical broadband access rate.</t> well below a typical broadband access rate.</t>
<t>This is a vague but useful definition, because many low <t>This is a vague but useful definition, because many low-latency
latency applications of interest, such as DNS, voice, game sync applications of interest, such as DNS, voice, game sync
packets, RPC, ACKs, keep-alives, could match this packets, RPC, ACKs, and keep-alives, could match this
description.</t> description.</t>
<t>Low rate streams such as voice and game sync packets, might <t>Low-rate streams, such as voice and game sync packets, might
not use continuously adapting ECN-based congestion control, but not use continuously adapting ECN-based congestion control, but
they ought to at least use a 'circuit-breaker' style of they ought to at least use a 'circuit-breaker' style of
congestion response <xref target="RFC8083" format="default"/>. If the volume congestion response <xref target="RFC8083" format="default"/>. If the volume
of traffic from unresponsive applications is high enough to of traffic from unresponsive applications is high enough to
overload the link, this will at least protect the capacity overload the link, this will at least protect the capacity
available to responsive applications. However, queuing delay in available to responsive applications. However, queuing delay in
the L queue will probably rise to that controlled by the Classic the L queue would probably then rise to the typically higher level
(drop-based) AQM. If a network operator considers that such targeted by
a Classic (drop-based) AQM. If a network operator considers that s
uch
self-restraint is not enough, it might want to police the L self-restraint is not enough, it might want to police the L
queue (see Section 8.2 of the L4S architecture <xref target="I-D.i queue (see Section <xref target="RFC9330" section="8.2"
etf-tsvwg-l4s-arch" format="default"/>).</t> sectionFormat="bare"/> of the L4S architecture <xref target="RFC9330" format="de
fault"/>).</t>
</section> </section>
</section> </section>
<section anchor="l4sid_exclusion_dualq" numbered="true" toc="default"> <section anchor="l4sid_exclusion_dualq" numbered="true" toc="default">
<name>Exclusion of Traffic From L4S Treatment</name> <name>Exclusion of Traffic from L4S Treatment</name>
<t>To extend the above example, an operator might want to exclude <t>To extend the above example, an operator might want to exclude
some traffic from the L4S treatment for a policy reason, some traffic from the L4S treatment for a policy reason,
e.g. security (traffic from malicious sources) or commercial e.g., security (traffic from malicious sources) or commercial
(e.g. initially the operator may wish to confine the benefits (e.g., the operator may wish to initially confine the benefits
of L4S to business customers).</t> of L4S to business customers).</t>
<t>In this exclusion case, the classifier MUST classify on the
relevant locally-used identifiers (e.g. source addresses) <t>In this exclusion case, the classifier <bcp14>MUST</bcp14> classi
fy on the
relevant locally used identifiers (e.g., source addresses)
before classifying the non-matching traffic on the end-to-end L4S before classifying the non-matching traffic on the end-to-end L4S
ECN identifier.</t> ECN identifier.</t>
<t>A network node MUST NOT alter the end-to-end L4S ECN identifier <t>A network node <bcp14>MUST NOT</bcp14> alter the end-to-end L4S E CN identifier
from L4S to Classic, because an operator decision to exclude from L4S to Classic, because an operator decision to exclude
certain traffic from L4S treatment is local-only. The end-to-end certain traffic from L4S treatment is local-only. The end-to-end
L4S identifier then survives for other operators to use, or L4S identifier then survives for other operators to use, or
indeed, they can apply their own policy, independently based on indeed, they can apply their own policy, independently based on
their own choice of locally-used identifiers. This approach also their own choice of locally used identifiers. This approach also
allows any operator to remove its locally-applied exclusions in allows any operator to remove its locally applied exclusions in
future, e.g. if it wishes to widen the benefit of the L4S future, e.g., if it wishes to widen the benefit of the L4S
treatment to all its customers. If a non-compliant or malicious treatment to all its customers. If a non-compliant or malicious
network node did swap ECT(1) to ECT(0), the packet could network node did swap ECT(1) to ECT(0), the packet could
subsequently be ECN-marked by a downstream Classic ECN AQM. L4S subsequently be ECN-marked by a downstream Classic ECN AQM. L4S
senders are required to detect and handle such treatment (<xref targ et="l4sid_congestion_response" format="default"/> item 3), but that does not senders are required to detect and handle such treatment (see Item < xref target="l4sid_Prague_req-classic-ecn-response" format="counter"/> in <xref target="l4sid_congestion_response" format="default"/>), but that does not
make this swap OK, because such detection is not known to be make this swap OK, because such detection is not known to be
perfect or immediate.</t> perfect or immediate.</t>
<t>A network node that supports L4S but excludes certain packets <t>A network node that supports L4S but excludes certain packets
carrying the L4S identifier from L4S treatment MUST still apply carrying the L4S identifier from L4S treatment <bcp14>MUST</bcp14> s till apply
marking or dropping that is compatible with an L4S congestion marking or dropping that is compatible with an L4S congestion
response. For instance, it could either drop such packets with the response.
same likelihood as Classic packets or it could ECN-mark them with For instance, it could either drop such packets with the
a likelihood appropriate to L4S traffic (e.g. the coupled same likelihood as Classic packets or ECN-mark them with
probability in a DualQ coupled AQM) but aiming for the Classic a likelihood appropriate to L4S traffic (e.g., the coupled
delay target. It MUST NOT ECN-mark such packets with a Classic probability in a DualQ Coupled AQM) but aiming for the Classic
delay target. It <bcp14>MUST NOT</bcp14> ECN-mark such packets with
a Classic
marking probability, which could confuse the sender.</t> marking probability, which could confuse the sender.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Generalized Combination of L4S and Other Identifiers</name> <name>Generalized Combination of L4S and Other Identifiers</name>
<t>L4S concerns low latency, which it can provide for all traffic <t>L4S concerns low latency, which it can provide for all traffic
without differentiation and without <em>necessarily</em> without differentiation and without <em>necessarily</em>
affecting bandwidth allocation. Diffserv provides for affecting bandwidth allocation. Diffserv provides for
differentiation of both bandwidth and low latency, but its control differentiation of both bandwidth and low latency, but its control
of latency depends on its control of bandwidth. The two can be of latency depends on its control of bandwidth.
L4S and Diffserv can be
combined if a network operator wants to control bandwidth combined if a network operator wants to control bandwidth
allocation but it also wants to provide low latency - for any allocation but also wants to provide low latency, i.e., for any
amount of traffic within one of these allocations of bandwidth amount of traffic within one of these allocations of bandwidth
(rather than only providing low latency by limiting bandwidth) (rather than only providing low latency by limiting bandwidth)
<xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="default"/>.</t > <xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="default"/>.</t >
<t>The DualQ examples so far have been framed in the context of <t>The DualQ examples so far have been framed in the context of
providing the default Best Efforts Per-Hop Behaviour (PHB) using providing the default Best Effort Per-Hop Behaviour (PHB) using
two queues - a Low Latency (L) queue and a Classic (C) Queue. This two queues -- a low-latency (L) queue and a Classic (C) queue. This
single DualQ structure is expected to be the most common and single DualQ structure is expected to be the most common and
useful arrangement. But, more generally, an operator might choose useful arrangement. But, more generally, an operator might choose
to control bandwidth allocation through a hierarchy of Diffserv to control bandwidth allocation through a hierarchy of Diffserv
PHBs at a node, and to offer one (or more) of these PHBs using a PHBs at a node and to offer one (or more) of these PHBs using a
pair of queues for a low latency and a Classic variant of the pair of queues for a low latency and a Classic variant of the
PHB.</t> PHB.</t>
<t>In the first case, if we assume that a network element provides <t>In the first case, if we assume that a network element provides
no PHBs except the DualQ, if a packet carries ECT(1) or CE, the no PHBs except the DualQ, if a packet carries ECT(1) or CE, the
network element would classify it for the L4S treatment network element would classify it for the L4S treatment
irrespective of its DSCP. And, if a packet carried (say) the EF irrespective of its DSCP. And, if a packet carried (for example) the EF
DSCP, the network element could classify it into the L queue DSCP, the network element could classify it into the L queue
irrespective of its ECN codepoint. However, where the DualQ is in irrespective of its ECN codepoint. However, where the DualQ is in
a hierarchy of other PHBs, the classifier would classify some a hierarchy of other PHBs, the classifier would classify some
traffic into other PHBs based on DSCP before classifying between traffic into other PHBs based on DSCP before classifying between
the low latency and Classic queues (based on ECT(1), CE and the low-latency and Classic queues (based on ECT(1), CE, and
perhaps also the EF DSCP or other identifiers as in the above perhaps also the EF DSCP or other identifiers as in the above
example). <xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="defa ult"/> gives a example). <xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="defa ult"/> gives a
number of examples of such arrangements to address various number of examples of such arrangements to address various
requirements.</t> requirements.</t>
<t><xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="default"/> describes how <t><xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="default"/> describes how
an operator might use L4S to offer low latency as well as using an operator might use L4S to offer low latency as well as
Diffserv for bandwidth differentiation. It identifies two main Diffserv for bandwidth differentiation. It identifies two main
types of approach, which can be combined: the operator might split types of approach, which can be combined: the operator might split
certain Diffserv PHBs between L4S and a corresponding Classic certain Diffserv PHBs between L4S and a corresponding Classic
service. Or it might split the L4S and/or the Classic service into service. Or it might split the L4S and/or the Classic service into
multiple Diffserv PHBs. In either of these cases, a packet would multiple Diffserv PHBs. In either of these cases, a packet would
have to be classified on its Diffserv and ECN codepoints.</t> have to be classified on its Diffserv and ECN codepoints.</t>
<t>In summary, there are numerous ways in which the L4S ECN <t>In summary, there are numerous ways in which the L4S ECN
identifier (ECT(1) and CE) could be combined with other identifier (ECT(1) and CE) could be combined with other
identifiers to achieve particular objectives. The following identifiers to achieve particular objectives. The following
categorization articulates those that are valid, but it is not categorization articulates those that are valid, but it is not
necessarily exhaustive. Those tagged 'Recommended-standard-use' necessarily exhaustive. Those tagged as 'Recommended-standard-use'
could be set by the sending host or a network. Those tagged could be set by the sending host or a network. Those tagged
'Local-use' would only be set by a network:</t> as 'Local-use' would only be set by a network:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Identifiers Complementing the L4S Identifier</t> <t>Identifiers Complementing the L4S Identifier</t>
<ol spacing="normal" type="a"><li> <ol spacing="normal" type="a"><li>
<t>Including More Traffic in the L Queue</t> <t>Including More Traffic in the L Queue</t>
<t>(Could use Recommended-standard-use or <t>(could use Recommended-standard-use or
Local-use identifiers)</t> Local-use identifiers)</t>
</li> </li>
<li> <li>
<t>Excluding Certain Traffic from the L Queue</t> <t>Excluding Certain Traffic from the L Queue</t>
<t>(Local-use only)</t> <t>(Local-use only)</t>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>Identifiers to place L4S classification in a PHB <t>Identifiers to Place L4S Classification in a PHB
Hierarchy</t> Hierarchy</t>
<t>(Could use <t>(could use
Recommended-standard-use or Local-use identifiers)</t> Recommended-standard-use or Local-use identifiers)</t>
<ol spacing="normal" type="a"><li>PHBs Before L4S ECN Classifica <ol spacing="normal" type="A"><li>PHBs before L4S ECN Classifica
tion</li> tion</li>
<li>PHBs After L4S ECN Classification</li> <li>PHBs after L4S ECN Classification</li>
</ol> </ol>
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="l4sid_iother_IDs_fq" numbered="true" toc="default"> <section anchor="l4sid_iother_IDs_fq" numbered="true" toc="default">
<name>Per-Flow Queuing Examples of Other Identifiers Complementing L4S <name>Per-flow Queuing Examples of Other Identifiers Complementing L4S
Identifiers</name> Identifiers</name>
<t>At a node with per-flow queueing (e.g. FQ-CoDel <xref target="RFC82 <t>At a node with per-flow queuing (e.g., FQ-CoDel <xref target="RFC82
90" format="default"/>), the L4S identifier could complement the Layer-4 90" format="default"/>), the L4S identifier could complement the transport-layer
flow ID as a further level of flow granularity (i.e. Not-ECT flow ID as a further level of flow granularity (i.e., Not-ECT
and ECT(0) queued separately from ECT(1) and CE packets). "Risk of and ECT(0) queued separately from ECT(1) and CE packets).
reordering Classic CE packets" in <xref target="l4sid_ECT1_CE" format= In <xref target="l4sid_ECT1_CE" format="default"/>, the "Risk of
"default"/> reordering Classic CE packets within a flow" discusses the resulting
discusses the resulting ambiguity if packets originally marked ambiguity if packets originally set to
ECT(0) are marked CE by an upstream AQM before they arrive at a node ECT(0) are marked CE by an upstream AQM before they arrive at a node
that classifies CE as L4S. It argues that the risk of reordering is that classifies CE as L4S. It argues that the risk of reordering is
vanishingly small and the consequence of such a low level of vanishingly small, and the consequence of such a low level of
reordering is minimal.</t> reordering is minimal.</t>
<t>Alternatively, it could be assumed that it is not in a flow's own <t>Alternatively, it could be assumed that it is not in a flow's own
interest to mix Classic and L4S identifiers. Then the AQM could use interest to mix Classic and L4S identifiers. Then, the AQM could use
the ECN field to switch itself between a Classic and an L4S AQM the IP-ECN field to switch itself between a Classic and an L4S AQM
behaviour within one per-flow queue. For instance, for ECN-capable behaviour within one per-flow queue. For instance, for ECN-capable
packets, the AQM might consist of a simple marking threshold and an packets, the AQM might consist of a simple marking threshold, and an
L4S ECN identifier might simply select a shallower threshold than a L4S ECN identifier might simply select a shallower threshold than a
Classic ECN identifier would.</t> Classic ECN identifier would.</t>
</section> </section>
</section> </section>
<section anchor="l4sid_bursts_links" numbered="true" toc="default"> <section anchor="l4sid_bursts_links" numbered="true" toc="default">
<name>Limiting Packet Bursts from Links</name> <name>Limiting Packet Bursts from Links</name>
<t>As well as senders needing to limit packet bursts (<xref target="l4si d_congestion_response" format="default"/>), links need to limit the degree <t>As well as senders needing to limit packet bursts (<xref target="l4si d_congestion_response" format="default"/>), links need to limit the degree
of burstiness they introduce. In both cases (senders and links) this of burstiness they introduce. In both cases (senders and links), this
is a tradeoff, because batch-handling of packets is done for good is a trade-off, because batch-handling of packets is done for good
reason, e.g. processing efficiency or to make efficient use of reason, e.g., for processing efficiency or to make efficient use of
medium acquisition delay. Some take the attitude that there is no medium acquisition delay. Some take the attitude that there is no
point reducing burst delay at the sender below that introduced by point reducing burst delay at the sender below that introduced by
links (or vice versa). However, delay reduction proceeds by cutting links (or vice versa). However, delay reduction proceeds by cutting
down 'the longest pole in the tent', which turns the spotlight on the down 'the longest pole in the tent', which turns the spotlight on the
next longest, and so on.</t> next longest, and so on.</t>
<t>This document does not set any quantified requirements for links to <t>This document does not set any quantified requirements for links to
limit burst delay, primarily because link technologies are outside the limit burst delay, primarily because link technologies are outside the
remit of L4S specifications. Nonetheless, the following two remit of L4S specifications. Nonetheless, the following two
subsections outline opportunities for addressing bursty links in the subsections outline opportunities for addressing bursty links in the
process of L4S implementation and deployment.</t> process of L4S implementation and deployment.</t>
<section anchor="l4sid_bursts_links_l4s" numbered="true" toc="default"> <section anchor="l4sid_bursts_links_l4s" numbered="true" toc="default">
<name>Limiting Packet Bursts from Links Fed by an L4S AQM</name> <name>Limiting Packet Bursts from Links Fed by an L4S AQM</name>
<t>It would not make sense to implement an L4S AQM that feeds into a <t>It would not make sense to implement an L4S AQM that feeds into a
particular link technology without also reviewing opportunities to particular link technology without also reviewing opportunities to
reduce any form of burst delay introduced by that link technology. reduce any form of burst delay introduced by that link technology.
This would at least limit the bursts that the link would otherwise This would at least limit the bursts that the link would otherwise
introduce into the onward traffic, which would cause jumpy feedback introduce into the onward traffic, which would cause jumpy feedback
to the sender as well as potential extra queuing delay downstream. to the sender as well as potential extra queuing delay downstream.
This document does not presume to even give guidance on an This document does not presume to even give guidance on an
appropriate target for such burst delay until there is more industry appropriate target for such burst delay until there is more industry
experience of L4S. However, as suggested in <xref target="l4sid_conges tion_response" format="default"/> it would not seem necessary to experience of L4S. However, as suggested in <xref target="l4sid_conges tion_response" format="default"/>, it would not seem necessary to
limit bursts lower than roughly 10% of the minimum base RTT expected limit bursts lower than roughly 10% of the minimum base RTT expected
in the typical deployment scenario (e.g. 250 us burst duration in the typical deployment scenario (e.g., 250 us burst duration
for links within the public Internet).</t> for links within the public Internet).</t>
</section> </section>
<section anchor="l4sid_bursts_links_l4s_upstream" numbered="true" toc="d efault"> <section anchor="l4sid_bursts_links_l4s_upstream" numbered="true" toc="d efault">
<name>Limiting Packet Bursts from Links Upstream of an L4S AQM</name> <name>Limiting Packet Bursts from Links Upstream of an L4S AQM</name>
<t>The initial scope of the L4S experiment is to deploy L4S AQMs at <t>The initial scope of the L4S experiment is to deploy L4S AQMs at
bottlenecks and L4S congestion controls at senders. This is expected bottlenecks and L4S congestion controls at senders. This is expected
to highlight interactions with the most bursty upstream links and to highlight interactions with the most bursty upstream links and
lead operators to tune down the burstiness of those links in their lead operators to tune down the burstiness of those links in their
network that are configurable, or failing that, to have to networks that are configurable or, failing that, to have to
compromise on the delay target of some L4S AQMs. It might also compromise on the delay target of some L4S AQMs. It might also
require specific redesign work relevant to the most problematic link require specific redesign work relevant to the most problematic link
types. Such knock-on effects of initial L4S deployment would all be types. Such knock-on effects of initial L4S deployment would all be a
part of the learning from the L4S experiment.</t> part of the learning from the L4S experiment.</t>
<t>The details of such link changes are beyond the scope of the <t>The details of such link changes are beyond the scope of the
present document. Nonetheless, where L4S technology is being present document.
Nonetheless, where L4S technology is being
implemented on an outgoing interface of a device, it would make implemented on an outgoing interface of a device, it would make
sense to consider opportunities for reducing bursts arriving at sense to consider opportunities for reducing bursts arriving at
other incoming interface(s). For instance, where an L4S AQM is other incoming interfaces. For instance, where an L4S AQM is
implemented to feed into the upstream WAN interface of a home implemented to feed into the upstream WAN interface of a home
gateway, there would be opportunities to alter the Wi-Fi profiles gateway, there would be opportunities to alter the Wi-Fi profiles
sent out of any Wi-Fi interfaces from the same device, in order to sent out of any Wi-Fi interfaces from the same device, in order to
mitigate incoming bursts of aggregated Wi-Fi frames from other Wi-Fi mitigate incoming bursts of aggregated Wi-Fi frames from other Wi-Fi
stations.</t> stations.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="l4sid_encaps" numbered="true" toc="default"> <section anchor="l4sid_encaps" numbered="true" toc="default">
<name>Behaviour of Tunnels and Encapsulations</name> <name>Behaviour of Tunnels and Encapsulations</name>
<section anchor="l4sid_encaps_no_change" numbered="true" toc="default"> <section anchor="l4sid_encaps_no_change" numbered="true" toc="default">
<name>No Change to ECN Tunnels and Encapsulations in General</name> <name>No Change to ECN Tunnels and Encapsulations in General</name>
<t>The L4S identifier is expected to work through and within any <t>The L4S identifier is expected to work through and within any
tunnel without modification, as long as the tunnel propagates the ECN tunnel without modification, as long as the tunnel propagates the ECN
field in any of the ways that have been defined since the first field in any of the ways that have been defined since the first
variant in the year 2001 <xref target="RFC3168" format="default"/>. L4S will also variant in the year 2001 <xref target="RFC3168" format="default"/>. L4S will also
work with (but does not rely on) any of the more recent updates to ECN work with (but does not rely on) any of the more recent updates to ECN
propagation in <xref target="RFC4301" format="default"/>, <xref target=" RFC6040" format="default"/> or propagation in <xref target="RFC4301" format="default"/>, <xref target=" RFC6040" format="default"/>, or
<xref target="I-D.ietf-tsvwg-rfc6040update-shim" format="default"/>. How ever, it is <xref target="I-D.ietf-tsvwg-rfc6040update-shim" format="default"/>. How ever, it is
likely that some tunnels still do not implement ECN propagation at likely that some tunnels still do not implement ECN propagation at
all. In these cases, L4S will work through such tunnels, but within all. In these cases, L4S will work through such tunnels, but within
them the outer header of L4S traffic will appear as Classic.</t> them the outer header of L4S traffic will appear as Classic.</t>
<t>AQMs are typically implemented where an IP-layer buffer feeds into <t>AQMs are typically implemented where an IP-layer buffer feeds into
a lower layer, so they are agnostic to link layer encapsulations. a lower layer, so they are agnostic to link-layer encapsulations.
Where a bottleneck link is not IP-aware, the L4S identifier is still Where a bottleneck link is not IP-aware, the L4S identifier is still
expected to work within any lower layer encapsulation without expected to work within any lower-layer encapsulation without
modification, as long it propagates the ECN field as defined for the modification, as long it propagates the IP-ECN field as defined for the
link technology, for example for MPLS <xref target="RFC5129" format="def link technology, for example, for MPLS <xref target="RFC5129" format="de
ault"/> or fault"/> or Transparent
TRILL <xref target="I-D.ietf-trill-ecn-support" format="default"/>. In s Interconnection of Lots of Links (TRILL) <xref target="I-D.ietf-trill-ec
ome of n-support" format="default"/>. In some of
these cases, e.g. layer-3 Ethernet switches, the AQM accesses the these cases, e.g., Layer 3 Ethernet switches, the AQM accesses the
IP layer header within the outer encapsulation, so again the L4S IP-layer header within the outer encapsulation, so again the L4S
identifier is expected to work without modification. Nonetheless, the identifier is expected to work without modification. Nonetheless, the
programme to define ECN for other lower layers is still in programme to define ECN for other lower layers is still in
progress <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" format="defa ult"/>.</t> progress <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" format="defa ult"/>.</t>
</section> </section>
<section anchor="l4sid_VPN_anti-replay" numbered="true" toc="default"> <section anchor="l4sid_VPN_anti-replay" numbered="true" toc="default">
<name>VPN Behaviour to Avoid Limitations of Anti-Replay</name> <name>VPN Behaviour to Avoid Limitations of Anti-Replay</name>
<t>If a mix of L4S and Classic packets is sent into the same security <t>If a mix of L4S and Classic packets is sent into the same security
association (SA) of a virtual private network (VPN), and if the VPN association (SA) of a VPN, and if the VPN
egress is employing the optional anti-replay feature, it could egress is employing the optional anti-replay feature, it could
inappropriately discard Classic packets (or discard the records in inappropriately discard Classic packets (or discard the records in
Classic packets) by mistaking their greater queuing delay for a replay Classic packets) by mistaking their greater queuing delay for a replay
attack (see "Dropped Packets for Tunnels with Replay Protection attack (see "Dropped Packets for Tunnels with Replay Protection
Enabled" in <xref target="Heist21" format="default"/> for the potential performance Enabled" in <xref target="Heist21" format="default"/> for the potential performance
impact). This known problem is common to both IPsec <xref target="RFC430 1" format="default"/> and DTLS <xref target="RFC9147" format="default"/> VPNs, g iven impact). This known problem is common to both IPsec <xref target="RFC430 1" format="default"/> and DTLS <xref target="RFC9147" format="default"/> VPNs, g iven
they use similar anti-replay window mechanisms. The mechanism used can they use similar anti-replay window mechanisms. The mechanism used can
only check for replay within its window, so if the window is smaller only check for replay within its window, so if the window is smaller
than the degree of reordering, it can only assume there might be a than the degree of reordering, it can only assume there might be a
replay attack and discard all the packets behind the trailing edge of replay attack and discard all the packets behind the trailing edge of
the window. The specifications of IPsec AH <xref target="RFC4302" format the window. The specifications of IPsec Authentication Header (AH)
="default"/> and ESP <xref target="RFC4303" format="default"/> suggest that <xref target="RFC4302" format="default"/> and Encapsulating Security Pay
load (ESP) <xref target="RFC4303" format="default"/> suggest that
an implementer scales the size of the anti-replay window with an implementer scales the size of the anti-replay window with
interface speed, and DTLS v1.3 <xref target="RFC9147" format="default"/> interface speed, and DTLS v1.3 <xref target="RFC9147" format="default"/>
says "The states that "The
receiver SHOULD pick a window large enough to handle any plausible receiver <bcp14>SHOULD</bcp14> pick a window large enough to handle any
plausible
reordering, which depends on the data rate." However, in practice, the reordering, which depends on the data rate." However, in practice, the
size of a VPN's anti-replay window is not always scaled size of a VPN's anti-replay window is not always scaled
appropriately.</t> appropriately.</t>
<t>If a VPN carrying traffic participating in the L4S experiment <t>If a VPN carrying traffic participating in the L4S experiment
experiences inappropriate replay detection, the foremost remedy would experiences inappropriate replay detection, the foremost remedy would
be to ensure that the egress is configured to comply with the above be to ensure that the egress is configured to comply with the above
window-sizing requirements.</t> window-sizing requirements.</t>
<t>If an implementation of a VPN egress does not support a <t>If an implementation of a VPN egress does not support a
sufficiently large anti-replay window, e.g. due to hardware sufficiently large anti-replay window, e.g., due to hardware
limitations, one of the temporary alternatives listed in order of limitations, one of the temporary alternatives listed in order of
preference below might be feasible instead:</t> preference below might be feasible instead:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the VPN can be configured to classify packets into different <li>If the VPN can be configured to classify packets into different
SAs indexed by DSCP, apply the appropriate locally defined DSCPs SAs indexed by DSCP, apply the appropriate locally defined DSCPs
to Classic and L4S packets. The DSCPs could be applied by the to Classic and L4S packets. The DSCPs could be applied by the
network (based on the least significant bit of the ECN field), or network (based on the least-significant bit of the IP-ECN field), or
by the sending host. Such DSCPs would only need to survive as far by the sending host. Such DSCPs would only need to survive as far
as the VPN ingress.</li> as the VPN ingress.</li>
<li> <li>
<t>If the above is not possible and it is necessary to use L4S, <t>If the above is not possible and it is necessary to use L4S,
either of the following might be appropriate as a last either of the following might be appropriate as a last
resort:</t> resort:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>disable anti-replay protection at the VPN egress, after <li>disable anti-replay protection at the VPN egress, after
considering the security implications (it is mandatory to considering the security implications (it is mandatory to
allow the anti-replay facility to be disabled in both IPsec allow the anti-replay facility to be disabled in both IPsec
and DTLS);</li> and DTLS), or</li>
<li>configure the tunnel ingress not to propagate ECN to the <li>configure the tunnel ingress not to propagate ECN to the
outer, which would lose the benefits of L4S and Classic ECN outer, which would lose the benefits of L4S and Classic ECN
over the VPN.</li> over the VPN.</li>
</ul> </ul>
</li> </li>
<!--ToDo: Perhaps better to delete this whole third bullet.-->
</ul> </ul>
<t>Modification to VPN implementations is outside the present scope, <t>Modification to VPN implementations is outside the present scope,
which is why this section has so far focused on reconfiguration. which is why this section has so far focused on reconfiguration.
Although this document does not define any requirements for VPN Although this document does not define any requirements for VPN
implementations, determining whether there is a need for such implementations, determining whether there is a need for such
requirements could be one aspect of L4S experimentation.</t> requirements could be one aspect of L4S experimentation.</t>
</section> </section>
</section> </section>
<section anchor="l4sid_expts" numbered="true" toc="default"> <section anchor="l4sid_expts" numbered="true" toc="default">
<name>L4S Experiments</name> <name>L4S Experiments</name>
<t>This section describes open questions that L4S Experiments ought to <t>This section describes open questions that L4S experiments ought to
focus on. This section also documents outstanding open issues that will focus on. This section also documents outstanding open issues that will
need to be investigated as part of L4S experimentation, given they could need to be investigated as part of L4S experimentation, given they could
not be fully resolved during the WG phase. It also lists metrics that not be fully resolved during the working group phase. It also lists metric s that
will need to be monitored during experiments (summarizing text elsewhere will need to be monitored during experiments (summarizing text elsewhere
in L4S documents) and finally lists some potential future directions in L4S documents) and finally lists some potential future directions
that researchers might wish to investigate.</t> that researchers might wish to investigate.</t>
<t>In addition to this section, the DualQ spec <xref target="I-D.ietf-tsvw
g-aqm-dualq-coupled" format="default"/> sets operational and <t>In addition to this section, i) the DualQ spec <xref target="RFC9332" f
management requirements for experiments with DualQ Coupled AQMs; and ormat="default"/> sets operational and
General operational and management requirements for experiments with L4S management requirements for experiments with DualQ Coupled AQMs, and
congestion controls are given in <xref target="l4sid_transport_req" format ii) general operational and management requirements for experiments with L
="default"/> 4S
and <xref target="l4sid_network_req" format="default"/> above, e.g. co-exi congestion controls are given in Sections <xref target="l4sid_transport_re
stence and q" format="counter"/>
scaling requirements, incremental deployment arrangements.</t> and <xref target="l4sid_network_req" format="counter"/> above, e.g., coexi
<t>The specification of each scalable congestion control will need to stence and
scaling requirements and incremental deployment arrangements.</t>
<t>The specification of each Scalable congestion control will need to
include protocol-specific requirements for configuration and monitoring include protocol-specific requirements for configuration and monitoring
performance during experiments. Appendix A of the guidelines in <xref targ performance during experiments.
et="RFC5706" format="default"/> provides a helpful checklist.</t>
<xref target="RFC5706" sectionFormat="of" section="A"/> provides a helpful
checklist.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Open Questions</name> <name>Open Questions</name>
<t>L4S experiments would be expected to answer the following <t>L4S experiments would be expected to answer the following
questions:</t> questions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Have all the parts of L4S been deployed, and if so, what <t>Have all the parts of L4S been deployed, and if so, what
proportion of paths support it?</t> proportion of paths support it?</t>
<ul spacing="normal"> <ul spacing="normal">
<li>What types of L4S AQMs were deployed, e.g. FQ, coupled <li>What types of L4S AQMs were deployed, e.g., FQ, coupled
DualQ, uncoupled DualQ, other? And how prevalent was each?</li> DualQ, uncoupled DualQ, other? And how prevalent was each?</li>
<li>Are the signalling patterns emitted by the deployed AQMs in <li>Are the signalling patterns emitted by the deployed AQMs in
any way different from those expected when the Prague any way different from those expected when the Prague
requirements for endpoints were written?</li> requirements for endpoints were written?</li>
</ul> </ul>
</li> </li>
<li>Does use of L4S over the Internet result in significantly <li>Does use of L4S over the Internet result in a significantly
improved user experience?</li> improved user experience?</li>
<li>Has L4S enabled novel interactive applications?</li> <li>Has L4S enabled novel interactive applications?</li>
<li> <li>
<t>Did use of L4S over the Internet result in improvements to the <t>Did use of L4S over the Internet result in improvements to the
following metrics:</t> following metrics:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>queue delay (mean and 99th percentile) under various <li>queue delay (mean and 99th percentile) under various
loads;</li> loads;</li>
<li>utilization;</li> <li>utilization;</li>
<li>starvation / fairness;</li> <li>starvation / fairness; and</li>
<li>scaling range of flow rates and RTTs?</li> <li>scaling range of flow rates and RTTs?</li>
</ul> </ul>
</li> </li>
<li>How dependent was the performance of L4S service on the <li>How dependent was the performance of L4S service on the
bottleneck bandwidth or the path RTT?</li> bottleneck bandwidth or the path RTT?</li>
<li>How much do bursty links in the Internet affect L4S performance <li>How much do bursty links in the Internet affect L4S performance
(see "Underutilization with Bursty Links" in <xref target="Heist21" format="default"/>) and how prevalent are they? How much (see "Underutilization with Bursty Links" in <xref target="Heist21" format="default"/>) and how prevalent are they? How much
limitation of burstiness from upstream links was needed and/or was limitation of burstiness from upstream links was needed and/or was
realized - both at senders and at links, especially radio links or realized -- both at senders and at links, especially radio links -- or
how much did L4S target delay have to be increased to accommodate how much did L4S target delay have to be increased to accommodate
the bursts (see bullet #7 in <xref target="l4sid_congestion_response the bursts (see Item <xref target="l4sid_Prague_req-burstiness" form
" format="default"/> and <xref target="l4sid_bursts_links_l4s_upstream" format=" at="counter"/> in <xref target="l4sid_congestion_response"/> and see <xref targe
default"/>)?</li> t="l4sid_bursts_links_l4s_upstream"/>)?</li>
<li>Is the initial experiment with mis-marked bursty traffic at <li>Is the initial experiment with mis-identified bursty traffic at
high RTT (see "Underutilization with Bursty Traffic" in <xref target high RTT (see "Underutilization with Bursty Traffic" in <xref target
="Heist21" format="default"/>) indicative of similar problems at lower RTTs ="Heist21" format="default"/>) indicative of similar problems at lower RTTs,
and, if so, how effective is the suggested remedy in Appendix A.1 and if so, how effective is the suggested remedy in <xref target="RF
of the DualQ spec <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" fo C9332" format="default" section="A.1" sectionFormat="of">the DualQ spec</xref> (
rmat="default"/> (or possible other or possible other
remedies)?</li> remedies)?</li>
<li> <li>
<t>Was per-flow queue protection typically (un)necessary? </t> <t>Was per-flow queue protection typically (un)necessary? </t>
<ul spacing="normal"> <ul spacing="normal">
<li>How well did overload protection or queue protection <li>How well did overload protection or queue protection
work?</li> work?</li>
</ul> </ul>
</li> </li>
<li>How well did L4S flows coexist with Classic flows when sharing <li><t>How well did L4S flows coexist with Classic flows when sharing
a bottleneck?</li> a bottleneck?</t>
<li>
<ul spacing="normal"> <ul spacing="normal">
<li>How frequently did problems arise?</li> <li>How frequently did problems arise?</li>
<li>What caused any coexistence problems, and were any problems <li>What caused any coexistence problems, and were any problems
due to single-queue Classic ECN AQMs (this assumes due to single-queue Classic ECN AQMs (this assumes
single-queue Classic ECN AQMs can be distinguished from FQ single-queue Classic ECN AQMs can be distinguished from FQ
ones)?</li> ones)?</li>
</ul> </ul>
</li> </li>
<li>How prevalent were problems with the L4S service due to tunnels <li>How prevalent were problems with the L4S service due to tunnels/en
/ encapsulations that do not support ECN decapsulation?</li> capsulations
that do not support ECN decapsulation?</li>
<li>How easy was it to implement a fully compliant L4S congestion <li>How easy was it to implement a fully compliant L4S congestion
control, over various different transport protocols (TCP, QUIC, control, over various different transport protocols (TCP, QUIC,
RMCAT, etc.)?</li> RMCAT, etc.)?</li>
</ul> </ul>
<t>Monitoring for harm to other traffic, specifically bandwidth <t>Monitoring for harm to other traffic, specifically bandwidth
starvation or excess queuing delay, will need to be conducted starvation or excess queuing delay, will need to be conducted
alongside all early L4S experiments. It is hard, if not impossible, alongside all early L4S experiments. It is hard, if not impossible,
for an individual flow to measure its impact on other traffic. So such for an individual flow to measure its impact on other traffic. So such
monitoring will need to be conducted using bespoke monitoring across monitoring will need to be conducted using bespoke monitoring across
flows and/or across classes of traffic.</t> flows and/or across classes of traffic.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Open Issues</name> <name>Open Issues</name>
<ul spacing="normal"> <ul spacing="normal">
<li>What is the best way forward to deal with L4S over single-queue <li>What is the best way forward to deal with L4S over single-queue
Classic ECN AQM bottlenecks, given current problems with Classic ECN AQM bottlenecks, given current problems with
misdetecting L4S AQMs as Classic ECN AQMs? See the L4S operational misdetecting L4S AQMs as Classic ECN AQMs? See the L4S operational
guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/>.</l guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/>.</l
i> i>
<li>Fixing the poor Interaction between current L4S congestion <li>Fixing the poor interaction between current L4S congestion
controls and CoDel with only Classic ECN support during flow controls and CoDel with only Classic ECN support during flow
startup. Originally, this was due to a bug in the initialization startup.
of the congestion EWMA in the Linux implementation of TCP Prague. Originally, this was due to a bug in the initialization
of the congestion average in the
Linux implementation of TCP Prague.
That was quickly fixed, which removed the main performance impact, That was quickly fixed, which removed the main performance impact,
but further improvement would be useful (either by modifying but further improvement would be useful (by modifying either
CoDel, Scalable congestion controls, or both).</li> CoDel or Scalable congestion controls, or both).</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Future Potential</name> <name>Future Potential</name>
<t>Researchers might find that L4S opens up the following interesting <t>Researchers might find that L4S opens up the following interesting
areas for investigation:</t> areas for investigation:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Potential for faster convergence time and tracking of available <li>potential for faster convergence time and tracking of available
capacity;</li> capacity;</li>
<li>Potential for improvements to particular link technologies, and <li>potential for improvements to particular link technologies and
cross-layer interactions with them;</li> cross-layer interactions with them;</li>
<li>Potential for using virtual queues, e.g. to further reduce <li>potential for using virtual queues, e.g., to further reduce
latency jitter, or to leave headroom for capacity variation in latency jitter or to leave headroom for capacity variation in
radio networks;</li> radio networks;</li>
<li>Development and specification of reverse path congestion <li>development and specification of reverse path congestion
control using L4S building blocks (e.g. AccECN, QUIC);</li> control using L4S building blocks (e.g., AccECN or QUIC);</li>
<li>Once queuing delay is cut down, what becomes the <li>once queuing delay is cut down, what becomes the
'second-longest pole in the tent' (other than the speed of 'second-longest pole in the tent' (other than the speed of
light)?</li> light)?</li>
<li>Novel alternatives to the existing set of L4S AQMs;</li> <li>novel alternatives to the existing set of L4S AQMs; and</li>
<li>Novel applications enabled by L4S.</li> <li>novel applications enabled by L4S.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="l4sid_IANA" numbered="true" toc="default"> <section anchor="l4sid_IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The 01 codepoint of the ECN Field of the IP header is specified by <t>The semantics of the 01 codepoint of the ECN field of the IP header are
the present Experimental RFC. The process for an experimental RFC to specified by
this Experimental RFC. The process for an Experimental RFC to
assign this codepoint in the IP header (v4 and v6) is documented in assign this codepoint in the IP header (v4 and v6) is documented in
Proposed Standard <xref target="RFC8311" format="default"/>, which updates the Proposed Proposed Standard <xref target="RFC8311" format="default"/>, which updates the Proposed
Standard <xref target="RFC3168" format="default"/>.</t> Standard <xref target="RFC3168" format="default"/>.</t>
<t>When the present document is published as an RFC, IANA is asked to
update the 01 entry in the registry, "ECN Field (Bits 6-7)" to the <t>IANA has updated the 01 entry in the "ECN Field (Bits 6-7)" registry (s
following (see ee <eref target="https://www.iana.org/assignments/dscp-registry/" brackets="angl
https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#ecn-fie e"/>) as
ld follows:</t>
):</t>
<table align="center"> <table align="center">
<name>ECN Field (Bits 6-7) Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Binary</th> <th align="left">Binary</th>
<th align="left">Keyword</th> <th align="left">Keyword</th>
<th align="left">References</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">01</td> <td align="left">01</td>
<td align="left">ECT(1) (ECN-Capable Transport(1))[1]</td> <td align="left">ECT(1) (ECN-Capable Transport(1))[1]</td>
<td align="left"> <td align="left">
<xref target="RFC8311" format="default"/> [RFC Errata 5399] <xref target="RFC8311" format="default"/> [RFC Errata 5399]
[RFCXXXX]</td> RFC 9331</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>[XXXX is the number that the RFC Editor assigns to the <t>[1] ECT(1) is for experimental use only <xref target="RFC8311" sectio
present document (this sentence to be removed by the RFC Editor)].</t> n="4.2" sectionFormat="comma"/></t>
</section> </section>
<section anchor="l4sid_Security_Considerations" numbered="true" toc="default "> <section anchor="l4sid_Security_Considerations" numbered="true" toc="default ">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Approaches to assure the integrity of signals using the new <t>Approaches to assure the integrity of signals using the new
identifier are introduced in <xref target="l4sid_competing_integrity" form identifier are introduced in <xref target="l4sid_competing_integrity" form
at="default"/>. See the security considerations in at="default"/>. See the security considerations in
the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" format="defaul the L4S architecture <xref target="RFC9330" format="default"/> for
t"/> for further discussion of misuse of the identifier, as well as extensive
further discussion of mis-use of the identifier, as well as extensive
discussion of policing rate and latency in regard to L4S.</t> discussion of policing rate and latency in regard to L4S.</t>
<t>Defining ECT(1) as the L4S identifier introduces a difference between <t>Defining ECT(1) as the L4S identifier introduces a difference between
the effects of ECT0 and ECT1 that RFC 3168 previously defined as the effects of ECT(0) and ECT(1) that <xref target="RFC3168" format="defau lt"/> previously defined as
distinct but with equivalent effect. For L4S ECN, a network node is distinct but with equivalent effect. For L4S ECN, a network node is
still required not to swap one to the other, even if the network still required not to swap one to the other, even if the network
operator chooses to locally apply the treatment associated with the operator chooses to locally apply the treatment associated with the
opposite codepoint (see Sections <xref format="counter" target="l4sid_incl usion_dualq"/> and <xref format="counter" target="l4sid_exclusion_dualq"/>). The se sections also describe the opposite codepoint (see Sections <xref format="counter" target="l4sid_incl usion_dualq"/> and <xref format="counter" target="l4sid_exclusion_dualq"/>). The se sections also describe the
potential effects if a non-compliant or malicious network node does swap potential effects if a non-compliant or malicious network node does swap
one to the other. The present specification does not change the effects one to the other. The present specification does not change the effects
of other unexpected transitions of the ECN field, which are still as of other unexpected transitions of the IP-ECN field, which are still as
described in Section 18 of RFC 3168.</t> described in <xref target="RFC3168" sectionFormat="of" section="18"/>.</t>
<t>If the anti-replay window of a VPN egress is too small, it will <t>If the anti-replay window of a VPN egress is too small, it will
mistake deliberate delay differences as a replay attack, and discard mistake deliberate delay differences as a replay attack and discard
higher delay packets (e.g. Classic) carried within the same higher-delay packets (e.g., Classic) carried within the same
security association (SA) as low delay packets (e.g. L4S). <xref target="l security association (SA) as low-delay packets (e.g., L4S). <xref target="
4sid_VPN_anti-replay" format="default"/> recommends that VPNs used in L4S l4sid_VPN_anti-replay" format="default"/> recommends that VPNs used in L4S
experiments are configured with a sufficiently large anti-replay window, experiments are configured with a sufficiently large anti-replay window,
as required by the relevant specifications. It also discusses other as required by the relevant specifications. It also discusses other
alternatives.</t> alternatives.</t>
<t>If a user taking part in the L4S experiment sets up a VPN without <t>If a user taking part in the L4S experiment sets up a VPN without
being aware of the above advice, and if the user allows anyone to send being aware of the above advice, and if the user allows anyone to send
traffic into their VPN, they would open up a DoS vulnerability in which traffic into their VPN, they would open up a DoS vulnerability in which
an attacker could induce the VPN's anti-replay mechanism to discard an attacker could induce the VPN's anti-replay mechanism to discard
enough of the user's Classic (C) traffic (if they are receiving any) to enough of the user's Classic (C) traffic (if they are receiving any) to
cause a significant rate reduction. While the user is actively cause a significant rate reduction. While the user is actively
downloading C traffic, the attacker sends C traffic into the VPN to fill downloading C traffic, the attacker sends C traffic into the VPN to fill
the remainder of the bottleneck link, then sends intermittent L4S the remainder of the bottleneck link, then sends intermittent L4S
packets to maximize the chance of exceeding the VPN's replay window. The packets to maximize the chance of exceeding the VPN's replay window. The
user can prevent this attack by following the recommendations in <xref tar user can prevent this attack by following the recommendations in <xref tar
get="l4sid_VPN_anti-replay" format="default"/>.<!--ToDo: I'm not sure this para get="l4sid_VPN_anti-replay" format="default"/>.
is warranted.
It's a bit lame to say there's an attack if you don't follow advice, and the sol
ution to the attack is to follow the advice.-->
</t> </t>
<t>The recommendation to detect loss in time units prevents the <t>The recommendation to detect loss in time units prevents the
ACK-splitting attacks described in <xref target="Savage-TCP" format="defau lt"/>.</t> ACK-splitting attacks described in <xref target="Savage-TCP" format="defau lt"/>.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<displayreference target="I-D.ietf-tcpm-accurate-ecn" to="ACCECN"/>
<displayreference target="I-D.ietf-tsvwg-ecn-encap-guidelines" to="ECN-ENCAP"/>
<displayreference target="I-D.ietf-tsvwg-rfc6040update-shim" to="ECN-SHIM"/>
<displayreference target="I-D.ietf-trill-ecn-support" to="TRILL-ECN-SUPPORT"/>
<displayreference target="I-D.stewart-tsvwg-sctpecn" to="SCTP-ECN"/>
<displayreference target="I-D.briscoe-tsvwg-l4s-diffserv" to="L4S-DIFFSERV"/>
<displayreference target="I-D.ietf-tsvwg-nqb" to="NQB-PHB"/>
<displayreference target="I-D.ietf-tsvwg-l4sops" to="L4SOPS"/>
<displayreference target="I-D.ietf-tcpm-generalized-ecn" to="ECN++"/>
<displayreference target="I-D.sridharan-tcpm-ctcp" to="CTCP"/>
<displayreference target="I-D.briscoe-docsis-q-protection" to="DOCSIS-QPROT"/>
<displayreference target="I-D.briscoe-iccrg-prague-congestion-control" to="PRAGU
E-CC"/>
<displayreference target="I-D.cardwell-iccrg-bbr-congestion-control" to="BBR-CC"
/>
<displayreference target="I-D.mathis-iccrg-relentless-tcp" to="RELENTLESS"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<front> xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.
le> xml"/>
<author initials="S." surname="Bradner" fullname="S. Bradner"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4774.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6679.
<date year="1997" month="March"/> xml"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3
168" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP<
/title>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishn
an">
<organization/>
</author>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization/>
</author>
<date year="2001" month="September"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congesti
on Notification) to TCP and IP, including ECN's use of two bits in the IP header
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="RFC4774" target="https://www.rfc-editor.org/info/rfc4
774" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml">
<front>
<title>Specifying Alternate Semantics for the Explicit Congestion No
tification (ECN) Field</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<date year="2006" month="November"/>
<abstract>
<t>There have been a number of proposals for alternate semantics f
or the Explicit Congestion Notification (ECN) field in the IP header RFC 3168.
This document discusses some of the issues in defining alternate semantics for t
he ECN field, and specifies requirements for a safe coexistence in an Internet t
hat could include routers that do not understand the defined alternate semantics
. This document evolved as a result of discussions with the authors of one rece
nt proposal for such alternate semantics. This document specifies an Internet B
est Current Practices for the Internet Community, and requests discussion and su
ggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="124"/>
<seriesInfo name="RFC" value="4774"/>
<seriesInfo name="DOI" value="10.17487/RFC4774"/>
</reference>
<reference anchor="RFC6679" target="https://www.rfc-editor.org/info/rfc6
679" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<front>
<title>Explicit Congestion Notification (ECN) for RTP over UDP</titl
e>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization/>
</author>
<author initials="I." surname="Johansson" fullname="I. Johansson">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<author initials="P." surname="O'Hanlon" fullname="P. O'Hanlon">
<organization/>
</author>
<author initials="K." surname="Carlberg" fullname="K. Carlberg">
<organization/>
</author>
<date year="2012" month="August"/>
<abstract>
<t>This memo specifies how Explicit Congestion Notification (ECN)
can be used with the Real-time Transport Protocol (RTP) running over UDP, using
the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP
Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedb
ack message for timely reporting of congestion events, and a Session Traversal U
tilities for NAT (STUN) extension used in the optional initialisation method usi
ng Interactive Connectivity Establishment (ICE). Signalling and procedures for
negotiation of capabilities and initialisation methods are also defined. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6679"/>
<seriesInfo name="DOI" value="10.17487/RFC6679"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2
474" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers</title>
<author initials="K." surname="Nichols" fullname="K. Nichols">
<organization/>
</author>
<author initials="S." surname="Blake" fullname="S. Blake">
<organization/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization/>
</author>
<date year="1998" month="December"/>
<abstract>
<t>This document defines the IP header field, called the DS (for d
ifferentiated services) field. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2474"/>
<seriesInfo name="DOI" value="10.17487/RFC2474"/>
</reference>
<reference anchor="RFC2309" target="https://www.rfc-editor.org/info/rfc2
309" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<front>
<title>Recommendations on Queue Management and Congestion Avoidance
in the Internet</title>
<author initials="B." surname="Braden" fullname="B. Braden">
<organization/>
</author>
<author initials="D." surname="Clark" fullname="D. Clark">
<organization/>
</author>
<author initials="J." surname="Crowcroft" fullname="J. Crowcroft">
<organization/>
</author>
<author initials="B." surname="Davie" fullname="B. Davie">
<organization/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<author initials="D." surname="Estrin" fullname="D. Estrin">
<organization/>
</author>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization/>
</author>
<author initials="G." surname="Minshall" fullname="G. Minshall">
<organization/>
</author>
<author initials="C." surname="Partridge" fullname="C. Partridge">
<organization/>
</author>
<author initials="L." surname="Peterson" fullname="L. Peterson">
<organization/>
</author>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishn
an">
<organization/>
</author>
<author initials="S." surname="Shenker" fullname="S. Shenker">
<organization/>
</author>
<author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
<organization/>
</author>
<author initials="L." surname="Zhang" fullname="L. Zhang">
<organization/>
</author>
<date year="1998" month="April"/>
<abstract>
<t>This memo presents two recommendations to the Internet communit
y concerning measures to improve and preserve Internet performance. It presents
a strong recommendation for testing, standardization, and widespread deployment
of active queue management in routers, to improve the performance of today's In
ternet. It also urges a concerted effort of research, measurement, and ultimate
deployment of router mechanisms to protect the Internet from flows that are not
sufficiently responsive to congestion notification. This memo provides informa
tion for the Internet community. It does not specify an Internet standard of an
y kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2309"/>
<seriesInfo name="DOI" value="10.17487/RFC2309"/>
</reference>
<reference anchor="RFC3540" target="https://www.rfc-editor.org/info/rfc3
540" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3540.xml">
<front>
<title>Robust Explicit Congestion Notification (ECN) Signaling with
Nonces</title>
<author initials="N." surname="Spring" fullname="N. Spring">
<organization/>
</author>
<author initials="D." surname="Wetherall" fullname="D. Wetherall">
<organization/>
</author>
<author initials="D." surname="Ely" fullname="D. Ely">
<organization/>
</author>
<date year="2003" month="June"/>
<abstract>
<t>This note describes the Explicit Congestion Notification (ECN)-
nonce, an optional addition to ECN that protects against accidental or malicious
concealment of marked packets from the TCP sender. It improves the robustness
of congestion control by preventing receivers from exploiting ECN to gain an unf
air share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transpor
t (ECT)codepoints in the ECN field of the IP header, and requires a flag in the
TCP header. It is computationally efficient for both routers and hosts. This m
emo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3540"/>
<seriesInfo name="DOI" value="10.17487/RFC3540"/>
</reference>
<reference anchor="RFC3246" target="https://www.rfc-editor.org/info/rfc3
246" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3246.xml">
<front>
<title>An Expedited Forwarding PHB (Per-Hop Behavior)</title>
<author initials="B." surname="Davie" fullname="B. Davie">
<organization/>
</author>
<author initials="A." surname="Charny" fullname="A. Charny">
<organization/>
</author>
<author initials="J.C.R." surname="Bennet" fullname="J.C.R. Bennet">
<organization/>
</author>
<author initials="K." surname="Benson" fullname="K. Benson">
<organization/>
</author>
<author initials="J.Y." surname="Le Boudec" fullname="J.Y. Le Boudec
">
<organization/>
</author>
<author initials="W." surname="Courtney" fullname="W. Courtney">
<organization/>
</author>
<author initials="S." surname="Davari" fullname="S. Davari">
<organization/>
</author>
<author initials="V." surname="Firoiu" fullname="V. Firoiu">
<organization/>
</author>
<author initials="D." surname="Stiliadis" fullname="D. Stiliadis">
<organization/>
</author>
<date year="2002" month="March"/>
<abstract>
<t>This document defines a PHB (per-hop behavior) called Expedited
Forwarding (EF). The PHB is a basic building block in the Differentiated Servi
ces architecture. EF is intended to provide a building block for low delay, low
jitter and low loss services by ensuring that the EF aggregate is served at a c
ertain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3246"/>
<seriesInfo name="DOI" value="10.17487/RFC3246"/>
</reference>
<reference anchor="RFC3649" target="https://www.rfc-editor.org/info/rfc3
649" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml">
<front>
<title>HighSpeed TCP for Large Congestion Windows</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<date year="2003" month="December"/>
<abstract>
<t>The proposals in this document are experimental. While they ma
y be deployed in the current Internet, they do not represent a consensus that th
is is the best method for high-speed congestion control. In particular, we note
that alternative experimental proposals are likely to be forthcoming, and it is
not well understood how the proposals in this document will interact with such
alternative proposals. This document proposes HighSpeed TCP, a modification to
TCP's congestion control mechanism for use with TCP connections with large conge
stion windows. The congestion control mechanisms of the current Standard TCP co
nstrains the congestion windows that can be achieved by TCP in realistic environ
ments. For example, for a Standard TCP connection with 1500-byte packets and a
100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would req
uire an average congestion window of 83,333 segments, and a packet drop rate of
at most one congestion event every 5,000,000,000 packets (or equivalently, at mo
st one congestion event every 1 2/3 hours). This is widely acknowledged as an u
nrealistic constraint. To address his limitation of TCP, this document proposes
HighSpeed TCP, and solicits experimentation and feedback from the wider communi
ty.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3649"/>
<seriesInfo name="DOI" value="10.17487/RFC3649"/>
</reference>
<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4
301" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization/>
</author>
<author initials="K." surname="Seo" fullname="K. Seo">
<organization/>
</author>
<date year="2005" month="December"/>
<abstract>
<t>This document describes an updated version of the "Security Arc
hitecture for IP", which is designed to provide security services for traffic at
the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
</reference>
<reference anchor="RFC4302" target="https://www.rfc-editor.org/info/rfc4
302" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml">
<front>
<title>IP Authentication Header</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization/>
</author>
<date year="2005" month="December"/>
<abstract>
<t>This document describes an updated version of the IP Authentica
tion Header (AH), which is designed to provide authentication services in IPv4 a
nd IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="4302"/>
<seriesInfo name="DOI" value="10.17487/RFC4302"/>
</reference>
<reference anchor="RFC4303" target="https://www.rfc-editor.org/info/rfc4
303" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization/>
</author>
<date year="2005" month="December"/>
<abstract>
<t>This document describes an updated version of the Encapsulating
Security Payload (ESP) protocol, which is designed to provide a mix of security
services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin
authentication, connectionless integrity, an anti-replay service (a form of par
tial sequence integrity), and limited traffic flow confidentiality. This docume
nt obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4303"/>
<seriesInfo name="DOI" value="10.17487/RFC4303"/>
</reference>
<reference anchor="RFC4340" target="https://www.rfc-editor.org/info/rfc4
340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<front>
<title>Datagram Congestion Control Protocol (DCCP)</title>
<author initials="E." surname="Kohler" fullname="E. Kohler">
<organization/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/>
</author>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<date year="2006" month="March"/>
<abstract>
<t>The Datagram Congestion Control Protocol (DCCP) is a transport
protocol that provides bidirectional unicast connections of congestion-controlle
d unreliable datagrams. DCCP is suitable for applications that transfer fairly
large amounts of data and that can benefit from control over the tradeoff betwee
n timeliness and reliability. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4340"/>
<seriesInfo name="DOI" value="10.17487/RFC4340"/>
</reference>
<reference anchor="RFC4341" target="https://www.rfc-editor.org/info/rfc4
341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4341.xml">
<front>
<title>Profile for Datagram Congestion Control Protocol (DCCP) Conge
stion Control ID 2: TCP-like Congestion Control</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="E." surname="Kohler" fullname="E. Kohler">
<organization/>
</author>
<date year="2006" month="March"/>
<abstract>
<t>This document contains the profile for Congestion Control Ident
ifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Contro
l Protocol (DCCP). CCID 2 should be used by senders who would like to take adva
ntage of the available bandwidth in an environment with rapidly changing conditi
ons, and who are able to adapt to the abrupt changes in the congestion window ty
pical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion contr
ol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4341"/>
<seriesInfo name="DOI" value="10.17487/RFC4341"/>
</reference>
<reference anchor="RFC4342" target="https://www.rfc-editor.org/info/rfc4
342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4342.xml">
<front>
<title>Profile for Datagram Congestion Control Protocol (DCCP) Conge
stion Control ID 3: TCP-Friendly Rate Control (TFRC)</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="E." surname="Kohler" fullname="E. Kohler">
<organization/>
</author>
<author initials="J." surname="Padhye" fullname="J. Padhye">
<organization/>
</author>
<date year="2006" month="March"/>
<abstract>
<t>This document contains the profile for Congestion Control Ident
ifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Pr
otocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sendin
g rate, possibly with Explicit Congestion Notification (ECN), while minimizing a
brupt rate changes. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4342"/>
<seriesInfo name="DOI" value="10.17487/RFC4342"/>
</reference>
<reference anchor="RFC5033" target="https://www.rfc-editor.org/info/rfc5
033" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5033.xml">
<front>
<title>Specifying New Congestion Control Algorithms</title>
<author initials="S." surname="Floyd" fullname="S. Floyd">
<organization/>
</author>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization/>
</author>
<date year="2007" month="August"/>
<abstract>
<t>The IETF's standard congestion control schemes have been widely
shown to be inadequate for various environments (e.g., high-speed networks). R
ecent research has yielded many alternate congestion control schemes that signif
icantly differ from the IETF's congestion control principles. Using these new c
ongestion control schemes in the global Internet has possible ramifications to b
oth the traffic using the new congestion control and to traffic using the curren
tly standardized congestion control. Therefore, the IETF must proceed with caut
ion when dealing with alternate congestion control proposals. The goal of this
document is to provide guidance for considering alternate congestion control alg
orithms within the IETF. This document specifies an Internet Best Current Pract
ices for the Internet Community, and requests discussion and suggestions for imp
rovements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="133"/>
<seriesInfo name="RFC" value="5033"/>
<seriesInfo name="DOI" value="10.17487/RFC5033"/>
</reference>
<reference anchor="RFC5129" target="https://www.rfc-editor.org/info/rfc5
129" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml">
<front>
<title>Explicit Congestion Marking in MPLS</title>
<author initials="B." surname="Davie" fullname="B. Davie">
<organization/>
</author>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization/>
</author>
<author initials="J." surname="Tay" fullname="J. Tay">
<organization/>
</author>
<date year="2008" month="January"/>
<abstract>
<t>RFC 3270 defines how to support the Diffserv architecture in MP
LS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS hea
der. DSCPs may be encoded in the EXP field, while other uses of that field are
not precluded. RFC 3270 makes no statement about how Explicit Congestion Notifi
cation (ECN) marking might be encoded in the MPLS header. This document defines
how an operator might define some of the EXP codepoints for explicit congestion
notification, without precluding other uses. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5129"/>
<seriesInfo name="DOI" value="10.17487/RFC5129"/>
</reference>
<!-- <?rfc include='reference.RFC.5238'?>
<?rfc include='reference.RFC.5415'?>
<?rfc include='reference.RFC.5764'?>
<?rfc include='reference.RFC.6083'?>
<reference anchor="RFC5348" target="https://www.rfc-editor.org/info/rfc534 <!-- [I-D.ietf-tsvwg-aqm-dualq-coupled]; companion document 9332 - title matches
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml"> as of 1/17/23 -->
<front> <reference anchor='RFC9332' target='https://www.rfc-editor.org/info/rfc9332'>
<title>TCP Friendly Rate Control (TFRC): Protocol Specification</tit <front>
le> <title>Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Los
<author initials="S." surname="Floyd" fullname="S. Floyd"> s, and Scalable Throughput (L4S)</title>
<organization/> <author initials='K' surname='De Schepper' fullname='Koen De Schepper'>
</author> <organization />
<author initials="M." surname="Handley" fullname="M. Handley"> </author>
<organization/> <author initials='B' surname='Briscoe' fullname='Bob Briscoe' role="editor">
</author> <organization />
<author initials="J." surname="Padhye" fullname="J. Padhye"> </author>
<organization/> <author initials='G' surname='White' fullname='Greg White'>
</author> <organization />
<author initials="J." surname="Widmer" fullname="J. Widmer"> </author>
<organization/> <date month="January" year="2023"/>
</author> </front>
<date year="2008" month="September"/> <seriesInfo name="RFC" value="9332"/>
<abstract> <seriesInfo name="DOI" value="10.17487/RFC9332"/>
<t>This document specifies TCP Friendly Rate Control (TFRC). TFRC </reference>
is a congestion control mechanism for unicast flows operating in a best-effort
Internet environment. It is reasonably fair when competing for bandwidth with T <!-- [I-D.ietf-tsvwg-l4s-arch]; companion document 9330 - title matches as of 1/
CP flows, but has a much lower variation of throughput over time compared with T 17/23 -->
CP, making it more suitable for applications such as streaming media where a rel <reference anchor='RFC9330' target='https://www.rfc-editor.org/info/rfc9330'>
atively smooth sending rate is of importance.</t> <front>
<t>This document obsoletes RFC 3448 and updates RFC 4342. [STANDA <title>Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Ar
RDS-TRACK]</t> chitecture</title>
</abstract> <author initials='B' surname='Briscoe' fullname='Bob Briscoe' role='editor' />
</front> <author initials='K' surname='De Schepper' fullname='Koen De Schepper' />
<seriesInfo name="RFC" value="5348"/> <author initials='M' surname='Bagnulo' fullname='Marcelo Bagnulo' />
<seriesInfo name="DOI" value="10.17487/RFC5348"/> <author initials='G' surname='White' fullname='Greg White' />
</reference> <date month="January" year="2023"/>
<reference anchor="RFC5622" target="https://www.rfc-editor.org/info/rfc5 </front>
622" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5622.xml"> <seriesInfo name="RFC" value="9330"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC9330"/>
<title>Profile for Datagram Congestion Control Protocol (DCCP) Conge </reference>
stion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)</title>
<author initials="S." surname="Floyd" fullname="S. Floyd"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3540.
<author initials="E." surname="Kohler" fullname="E. Kohler"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3246.
</author> xml"/>
<date year="2009" month="August"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3649.
<abstract> xml"/>
<t>This document specifies a profile for Congestion Control Identi <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.
fier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Dat xml"/>
agram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and u <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4302.
ses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send sm xml"/>
all packets. CCID 4 is considered experimental because TFRC-SP is itself experi <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.
mental, and is not proposed for widespread deployment in the global Internet at xml"/>
this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.
s per second (bps) as a TCP flow using packets of up to 1500 bytes but experienc xml"/>
ing the same level of congestion. CCID 4 is for use for senders that send small <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4341.
packets and would like a TCP- friendly sending rate, possibly with Explicit Con xml"/>
gestion Notification (ECN), while minimizing abrupt rate changes. This memo def <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4342.
ines an Experimental Protocol for the Internet community.</t> xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5033.
</front> xml"/>
<seriesInfo name="RFC" value="5622"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5129.
<seriesInfo name="DOI" value="10.17487/RFC5622"/> xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5348.
<reference anchor="RFC5865" target="https://www.rfc-editor.org/info/rfc5 xml"/>
865" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5865.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5622.
<front> xml"/>
<title>A Differentiated Services Code Point (DSCP) for Capacity-Admi <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5865.
tted Traffic</title> xml"/>
<author initials="F." surname="Baker" fullname="F. Baker"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5562.
<author initials="J." surname="Polk" fullname="J. Polk"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.
</author> xml"/>
<author initials="M." surname="Dolly" fullname="M. Dolly"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5706.
<organization/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.
<date year="2010" month="May"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6077.
<t>This document requests one Differentiated Services Code Point ( xml"/>
DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-ti <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6660.
me traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Beh xml"/>
avior. This traffic is also admitted by the network using a Call Admission Cont <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6675.
rol (CAC) procedure involving authentication, authorization, and capacity admiss xml"/>
ion. This differs from a real-time traffic class that conforms to the Expedited <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7560.
Forwarding Per-Hop Behavior but is not subject to capacity admission or subject xml"/>
to very coarse capacity admission. [STANDARDS-TRACK]</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7567.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7713.
<seriesInfo name="RFC" value="5865"/> xml"/>
<seriesInfo name="DOI" value="10.17487/RFC5865"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.
</reference> xml"/>
<reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8033.
960" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8083.
<title>Stream Control Transmission Protocol</title> xml"/>
<author initials="R." surname="Stewart" fullname="R. Stewart" role=" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.
editor"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
</author> xml"/>
<date year="2007" month="September"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8290.
<abstract> xml"/>
<t>This document obsoletes RFC 2960 and RFC 3309. It describes th <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8298.
e Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Pu xml"/>
blic Switched Telephone Network (PSTN) signaling messages over IP networks, but
is capable of broader applications.</t> <!-- [I-D.ietf-tcpm-accurate-ecn] IESG state I-D Exists as of 1/17/23-->
<t>SCTP is a reliable transport protocol operating on top of a con <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tc
nectionless packet network such as IP. It offers the following services to its pm-accurate-ecn.xml"/>
users:</t>
<t>-- acknowledged error-free non-duplicated transfer of user dat <!-- [I-D.ietf-tsvwg-ecn-encap-guidelines] Expired as of 1/17/23 -->
a,</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ts
<t>-- data fragmentation to conform to discovered path MTU size,< vwg-ecn-encap-guidelines.xml"/>
/t>
<t>-- sequenced delivery of user messages within multiple streams <!-- [I-D.ietf-tsvwg-rfc6040update-shim] Expired as of 1/17/23 -->
, with an option for order-of-arrival delivery of individual user messages,</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ts
<t>-- optional bundling of multiple user messages into a single S vwg-rfc6040update-shim.xml"/>
CTP packet, and</t>
<t>-- network-level fault tolerance through supporting of multi-h <!-- [I-D.ietf-trill-ecn-support] in MISSREF state as of 1/17/23. xi:include
oming at either or both ends of an association.</t> incorrectly shows Eastlake's name as "D. E. Eastlake" but author name
<t> The design of SCTP includes appropriate congestion avoidance b preferences show he wants "D. Eastlake 3rd" -->
ehavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]</t <reference anchor="I-D.ietf-trill-ecn-support">
> <front>
</abstract> <title>TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit C
</front> ongestion Notification) Support</title>
<seriesInfo name="RFC" value="4960"/> <author initials="D." surname="Eastlake 3rd" fullname="Donald Eastlake 3rd">
<seriesInfo name="DOI" value="10.17487/RFC4960"/> <organization>Huawei</organization>
</reference> </author>
<reference anchor="RFC5562" target="https://www.rfc-editor.org/info/rfc5 <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
562" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5562.xml"> <organization>CableLabs</organization>
<front> </author>
<title>Adding Explicit Congestion Notification (ECN) Capability to T <date month="February" day="25" year="2018"/>
CP's SYN/ACK Packets</title> </front>
<author initials="A." surname="Kuzmanovic" fullname="A. Kuzmanovic"> <seriesInfo name="Internet-Draft" value="draft-ietf-trill-ecn-support-07"/>
<organization/> </reference>
</author>
<author initials="A." surname="Mondal" fullname="A. Mondal"> <!-- [I-D.stewart-tsvwg-sctpecn] IESG state Expired as of 1/17/23. xi:include in
<organization/> correctly
</author> shows Stewart's name as "R. R. Stewart" when the draft only has
<author initials="S." surname="Floyd" fullname="S. Floyd"> "R. Stewart" -->
<organization/> <reference anchor="I-D.stewart-tsvwg-sctpecn">
</author> <front>
<author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishn <title>ECN for Stream Control Transmission Protocol (SCTP)</title>
an"> <author initials="R." surname="Stewart" fullname="Randall R. Stewart">
<organization/> <organization>Adara Networks</organization>
</author> </author>
<date year="2009" month="June"/> <author initials="M." surname="Tüxen" fullname="Michael Tüxen">
<abstract> <organization>Muenster Univ. of Appl. Sciences</organization>
<t>The proposal in this document is Experimental. While it may be </author>
deployed in the current Internet, it does not represent a consensus that this i <author initials="X." surname="Dong" fullname="Xuesong Dong">
s the best possible mechanism for the use of Explicit Congestion Notification (E <organization>Huawei</organization>
CN) in TCP SYN/ACK packets.</t> </author>
<t>This document describes an optional, experimental modification <date month="January" day="15" year="2014"/>
to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 s </front>
pecifies setting an ECN-Capable codepoint on data packets, but not on SYN and SY <seriesInfo name="Internet-Draft" value="draft-stewart-tsvwg-sctpecn-05"/>
N/ACK packets. However, because of the high cost to the TCP transfer of having </reference>
a SYN/ACK packet dropped, with the resulting retransmission timeout, this docume
nt describes the use of ECN for the SYN/ACK packet itself, when sent in response <!-- [I-D.briscoe-tsvwg-l4s-diffserv] IESG state Expired as of 1/17/23. xi:inclu
to a SYN packet with the two ECN flags set in the TCP header, indicating a will de wrong date: -->
ingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can b <reference anchor="I-D.briscoe-tsvwg-l4s-diffserv">
e of great benefit to the TCP connection, avoiding the severe penalty of a retra <front>
nsmission timeout for a connection that has not yet started placing a load on th <title>Interactions between Low Latency, Low Loss, Scalable Throughput (L4S)
e network. The TCP responder (the sender of the SYN/ACK packet) must reply to a and Differentiated Services</title>
report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is no <author fullname="Bob Briscoe" surname="Briscoe" initials="B">
t ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP respo <organization>CableLabs</organization>
nder reduces its initial congestion window from two, three, or four segments to </author>
one segment, thereby reducing the subsequent load from that connection on the ne <date month="November" day="1" year="2018"/>
twork. If instead the SYN/ACK packet is dropped, or for some other reason the T </front>
CP responder does not receive an acknowledgement in the specified time, the TCP <seriesInfo name="Internet-Draft" value="draft-briscoe-tsvwg-l4s-diffserv-02"/
responder follows TCP standards for a dropped SYN/ACK packet (setting the retran >
smission timer). This memo defines an Experimental Protocol for the Internet co </reference>
mmunity.</t>
</abstract> <!-- [I-D.ietf-tsvwg-nqb] IESG state I-D Exists.-->
</front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ts
<seriesInfo name="RFC" value="5562"/> vwg-nqb.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC5562"/>
</reference> <!-- [I-D.ietf-tsvwg-l4sops] IESG state I-D Exists as of 1/17/23. xi:incl
<reference anchor="RFC5681" target="https://www.rfc-editor.org/info/rfc5 ude missing editor role-->
681" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"> <reference anchor="I-D.ietf-tsvwg-l4sops">
<front> <front>
<title>TCP Congestion Control</title> <title>Operational Guidance for Deployment of L4S in the Internet
<author initials="M." surname="Allman" fullname="M. Allman"> </title>
<organization/> <author fullname="Greg White" surname="White" initials="G" role="editor">
</author> <organization>CableLabs</organization>
<author initials="V." surname="Paxson" fullname="V. Paxson"> </author>
<organization/> <date month="April" day="28" year="2022"/>
</author> </front>
<author initials="E." surname="Blanton" fullname="E. Blanton"> <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-l4sops-03"/>
<organization/> </reference>
</author>
<date year="2009" month="September"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8311.
<abstract> xml"/>
<t>This document defines TCP's four intertwined congestion control
algorithms: slow start, congestion avoidance, fast retransmit, and fast recover <!-- [I-D.ietf-tcpm-generalized-ecn] IESG state I-D Exists as of 1/1/7/23 -->
y. In addition, the document specifies how TCP should begin transmission after <xi:include
a relatively long idle period, as well as discussing various acknowledgment gene href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tcpm-gener
ration methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t> alized-ecn.xml"/>
</abstract>
</front> <reference anchor="ARED01" target="https://www.icsi.berkeley.edu/icsi/no
<seriesInfo name="RFC" value="5681"/> de/2032">
<seriesInfo name="DOI" value="10.17487/RFC5681"/>
</reference>
<reference anchor="RFC5706" target="https://www.rfc-editor.org/info/rfc5
706" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5706.xml">
<front>
<title>Guidelines for Considering Operations and Management of New P
rotocols and Protocol Extensions</title>
<author initials="D." surname="Harrington" fullname="D. Harrington">
<organization/>
</author>
<date year="2009" month="November"/>
<abstract>
<t>New protocols or protocol extensions are best designed with due
consideration of the functionality needed to operate and manage the protocols.
Retrofitting operations and management is sub-optimal. The purpose of this docu
ment is to provide guidance to authors and reviewers of documents that define ne
w protocols or protocol extensions regarding aspects of operations and managemen
t that should be considered. This memo provides information for the Internet co
mmunity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5706"/>
<seriesInfo name="DOI" value="10.17487/RFC5706"/>
</reference>
<reference anchor="RFC6040" target="https://www.rfc-editor.org/info/rfc6
040" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml">
<front>
<title>Tunnelling of Explicit Congestion Notification</title>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization/>
</author>
<date year="2010" month="November"/>
<abstract>
<t>This document redefines how the explicit congestion notificatio
n (ECN) field of the IP header should be constructed on entry to and exit from a
ny IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP
tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulat
ion, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously
unused combinations of inner and outer headers. The new rules ensure the ECN fi
eld is correctly propagated across a tunnel whether it is used to signal one or
two severity levels of congestion; whereas before, only one severity level was s
upported. Tunnel endpoints can be updated in any order without affecting pre-ex
isting uses of the ECN field, thus ensuring backward compatibility. Nonetheless
, operators wanting to support two severity levels (e.g., for pre-congestion not
ification -- PCN) can require compliance with this new specification. A thoroug
h analysis of the reasoning for these changes and the implications is included.
In the unlikely event that the new rules do not meet a specific need, RFC 4774
gives guidance on designing alternate ECN semantics, and this document extends t
hat to include tunnelling issues. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6040"/>
<seriesInfo name="DOI" value="10.17487/RFC6040"/>
</reference>
<reference anchor="RFC6077" target="https://www.rfc-editor.org/info/rfc6
077" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6077.xml">
<front>
<title>Open Research Issues in Internet Congestion Control</title>
<author initials="D." surname="Papadimitriou" fullname="D. Papadimit
riou" role="editor">
<organization/>
</author>
<author initials="M." surname="Welzl" fullname="M. Welzl">
<organization/>
</author>
<author initials="M." surname="Scharf" fullname="M. Scharf">
<organization/>
</author>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization/>
</author>
<date year="2011" month="February"/>
<abstract>
<t>This document describes some of the open problems in Internet c
ongestion control that are known today. This includes several new challenges th
at are becoming important as the network grows, as well as some issues that have
been known for many years. These challenges are generally considered to be ope
n research topics that may require more study or application of innovative techn
iques before Internet-scale solutions can be confidently engineered and deployed
. This document is not an Internet Standards Track specification; it is publis
hed for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6077"/>
<seriesInfo name="DOI" value="10.17487/RFC6077"/>
</reference>
<reference anchor="RFC6660" target="https://www.rfc-editor.org/info/rfc6
660" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml">
<front>
<title>Encoding Three Pre-Congestion Notification (PCN) States in th
e IP Header Using a Single Diffserv Codepoint (DSCP)</title>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization/>
</author>
<author initials="T." surname="Moncaster" fullname="T. Moncaster">
<organization/>
</author>
<author initials="M." surname="Menth" fullname="M. Menth">
<organization/>
</author>
<date year="2012" month="July"/>
<abstract>
<t>The objective of Pre-Congestion Notification (PCN) is to protec
t the quality of service (QoS) of inelastic flows within a Diffserv domain. The
overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN
-packets are appropriately marked when certain configured rates are exceeded. E
gress nodes pass information about these PCN-marks to Decision Points that then
decide whether to admit or block new flow requests or to terminate some already
admitted flows during serious pre-congestion.</t>
<t>This document specifies how PCN-marks are to be encoded into th
e IP header by reusing the Explicit Congestion Notification (ECN) codepoints wit
hin a PCN-domain. The PCN wire protocol for non-IP protocol headers will need t
o be defined elsewhere. Nonetheless, this document clarifies the PCN encoding f
or MPLS in an informational appendix. The encoding for IP provides for up to th
ree different PCN marking states using a single Diffserv codepoint (DSCP): not-m
arked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it i
s called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS
-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6660"/>
<seriesInfo name="DOI" value="10.17487/RFC6660"/>
</reference>
<reference anchor="RFC6675" target="https://www.rfc-editor.org/info/rfc6
675" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6675.xml">
<front>
<title>A Conservative Loss Recovery Algorithm Based on Selective Ack
nowledgment (SACK) for TCP</title>
<author initials="E." surname="Blanton" fullname="E. Blanton">
<organization/>
</author>
<author initials="M." surname="Allman" fullname="M. Allman">
<organization/>
</author>
<author initials="L." surname="Wang" fullname="L. Wang">
<organization/>
</author>
<author initials="I." surname="Jarvinen" fullname="I. Jarvinen">
<organization/>
</author>
<author initials="M." surname="Kojo" fullname="M. Kojo">
<organization/>
</author>
<author initials="Y." surname="Nishida" fullname="Y. Nishida">
<organization/>
</author>
<date year="2012" month="August"/>
<abstract>
<t>This document presents a conservative loss recovery algorithm f
or TCP that is based on the use of the selective acknowledgment (SACK) TCP optio
n. The algorithm presented in this document conforms to the spirit of the curre
nt congestion control specification (RFC 5681), but allows TCP senders to recove
r more effectively when multiple segments are lost from a single flight of data.
This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6675"/>
<seriesInfo name="DOI" value="10.17487/RFC6675"/>
</reference>
<reference anchor="RFC7560" target="https://www.rfc-editor.org/info/rfc7
560" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7560.xml">
<front>
<title>Problem Statement and Requirements for Increased Accuracy in
Explicit Congestion Notification (ECN) Feedback</title>
<author initials="M." surname="Kuehlewind" fullname="M. Kuehlewind"
role="editor">
<organization/>
</author>
<author initials="R." surname="Scheffenegger" fullname="R. Scheffene
gger">
<organization/>
</author>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization/>
</author>
<date year="2015" month="August"/>
<abstract>
<t>Explicit Congestion Notification (ECN) is a mechanism where net
work nodes can mark IP packets, instead of dropping them, to indicate congestion
to the endpoints. An ECN-capable receiver will feed this information back to t
he sender. ECN is specified for TCP in such a way that it can only feed back on
e congestion signal per Round-Trip Time (RTT). In contrast, ECN for other trans
port protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN fe
edback. Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Cent
er TCP (DCTCP)) need more accurate ECN feedback in the case where more than one
marking is received in one RTT. This document specifies requirements for an upd
ate to the TCP protocol to provide more accurate ECN feedback.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7560"/>
<seriesInfo name="DOI" value="10.17487/RFC7560"/>
</reference>
<reference anchor="RFC7567" target="https://www.rfc-editor.org/info/rfc7
567" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml">
<front>
<title>IETF Recommendations Regarding Active Queue Management</title
>
<author initials="F." surname="Baker" fullname="F. Baker" role="edit
or">
<organization/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst" ro
le="editor">
<organization/>
</author>
<date year="2015" month="July"/>
<abstract>
<t>This memo presents recommendations to the Internet community co
ncerning measures to improve and preserve Internet performance. It presents a s
trong recommendation for testing, standardization, and widespread deployment of
active queue management (AQM) in network devices to improve the performance of t
oday's Internet. It also urges a concerted effort of research, measurement, and
ultimate deployment of AQM mechanisms to protect the Internet from flows that a
re not sufficiently responsive to congestion notification.</t>
<t>Based on 15 years of experience and new research, this document
replaces the recommendations of RFC 2309.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="197"/>
<seriesInfo name="RFC" value="7567"/>
<seriesInfo name="DOI" value="10.17487/RFC7567"/>
</reference>
<reference anchor="RFC7713" target="https://www.rfc-editor.org/info/rfc7
713" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml">
<front>
<title>Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and
Requirements</title>
<author initials="M." surname="Mathis" fullname="M. Mathis">
<organization/>
</author>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization/>
</author>
<date year="2015" month="December"/>
<abstract>
<t>This document describes an abstract mechanism by which senders
inform the network about the congestion recently encountered by packets in the s
ame flow. Today, network elements at any layer may signal congestion to the rec
eiver by dropping packets or by Explicit Congestion Notification (ECN) markings,
and the receiver passes this information back to the sender in transport-layer
feedback. The mechanism described here enables the sender to also relay this co
ngestion information back into the network in-band at the IP layer, such that th
e total amount of congestion from all elements on the path is revealed to all IP
elements along the path, where it could, for example, be used to provide input
to traffic management. This mechanism is called Congestion Exposure, or ConEx.
The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (R
FC 6789), provides the entry point to the set of ConEx documentation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7713"/>
<seriesInfo name="DOI" value="10.17487/RFC7713"/>
</reference>
<reference anchor="RFC5925" target="https://www.rfc-editor.org/info/rfc5
925" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml">
<front>
<title>The TCP Authentication Option</title>
<author initials="J." surname="Touch" fullname="J. Touch">
<organization/>
</author>
<author initials="A." surname="Mankin" fullname="A. Mankin">
<organization/>
</author>
<author initials="R." surname="Bonica" fullname="R. Bonica">
<organization/>
</author>
<date year="2010" month="June"/>
<abstract>
<t>This document specifies the TCP Authentication Option (TCP-AO),
which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO spe
cifies the use of stronger Message Authentication Codes (MACs), protects against
replays even for long-lived TCP connections, and provides more details on the a
ssociation of security with TCP connections than TCP MD5. TCP-AO is compatible
with either a static Master Key Tuple (MKT) configuration or an external, out-of
-band MKT management mechanism; in either case, TCP-AO also protects connections
when using the same MKT across repeated instances of a connection, using traffi
c keys derived from the MKT, and coordinates MKT changes between endpoints. The
result is intended to support current infrastructure uses of TCP MD5, such as t
o protect long-lived connections (as used, e.g., in BGP and LDP), and to support
a larger set of MACs with minimal other system and operational changes. TCP-AO
uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5
are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fu
lly compatible with the proposed requirements for the replacement of TCP MD5. [
STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5925"/>
<seriesInfo name="DOI" value="10.17487/RFC5925"/>
</reference>
<reference anchor="RFC8033" target="https://www.rfc-editor.org/info/rfc8
033" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8033.xml">
<front>
<title>Proportional Integral Controller Enhanced (PIE): A Lightweigh
t Control Scheme to Address the Bufferbloat Problem</title>
<author initials="R." surname="Pan" fullname="R. Pan">
<organization/>
</author>
<author initials="P." surname="Natarajan" fullname="P. Natarajan">
<organization/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization/>
</author>
<author initials="G." surname="White" fullname="G. White">
<organization/>
</author>
<date year="2017" month="February"/>
<abstract>
<t>Bufferbloat is a phenomenon in which excess buffers in the netw
ork cause high latency and latency variation. As more and more interactive appl
ications (e.g., voice over IP, real-time video streaming, and financial transact
ions) run in the Internet, high latency and latency variation degrade applicatio
n performance. There is a pressing need to design intelligent queue management
schemes that can control latency and latency variation, and hence provide desira
ble quality of service to users.</t>
<t>This document presents a lightweight active queue management de
sign called "PIE" (Proportional Integral controller Enhanced) that can effective
ly control the average queuing latency to a target value. Simulation results, th
eoretical analysis, and Linux testbed results have shown that PIE can ensure low
latency and achieve high link utilization under various congestion situations.
The design does not require per-packet timestamps, so it incurs very little ove
rhead and is simple enough to implement in both hardware and software.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8033"/>
<seriesInfo name="DOI" value="10.17487/RFC8033"/>
</reference>
<reference anchor="RFC8083" target="https://www.rfc-editor.org/info/rfc8
083" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml">
<front>
<title>Multimedia Congestion Control: Circuit Breakers for Unicast R
TP Sessions</title>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<author initials="V." surname="Singh" fullname="V. Singh">
<organization/>
</author>
<date year="2017" month="March"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is widely used in teleph
ony, video conferencing, and telepresence applications. Such applications are o
ften run on best-effort UDP/IP networks. If congestion control is not implement
ed in these applications, then network congestion can lead to uncontrolled packe
t loss and a resulting deterioration of the user's multimedia experience. The c
ongestion control algorithm acts as a safety measure by stopping RTP flows from
using excessive resources and protecting the network from overload. At the time
of this writing, however, while there are several proprietary solutions, there
is no standard algorithm for congestion control of interactive RTP flows.</t>
<t>This document does not propose a congestion control algorithm.
It instead defines a minimal set of RTP circuit breakers: conditions under whic
h an RTP sender needs to stop transmitting media data to protect the network fro
m excessive congestion. It is expected that, in the absence of long-lived exces
sive congestion, RTP applications running on best-effort IP networks will be abl
e to operate without triggering these circuit breakers. To avoid triggering the
RTP circuit breaker, any Standards Track congestion control algorithms defined
for RTP will need to operate within the envelope set by these RTP circuit breake
r algorithms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8083"/>
<seriesInfo name="DOI" value="10.17487/RFC8083"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
<front>
<title>UDP Usage Guidelines</title>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization/>
</author>
<author initials="G." surname="Shepherd" fullname="G. Shepherd">
<organization/>
</author>
<date year="2017" month="March"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This documen
t provides guidelines on the use of UDP for the designers of applications, tunne
ls, and other protocols that use UDP. Congestion control guidelines are a prima
ry focus, but the document also provides guidance on other topics, including mes
sage sizes, reliability, checksums, middlebox traversal, the use of Explicit Con
gestion Notification (ECN), Differentiated Services Code Points (DSCPs), and por
ts.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8290" target="https://www.rfc-editor.org/info/rfc8
290" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8290.xml">
<front>
<title>The Flow Queue CoDel Packet Scheduler and Active Queue Manage
ment Algorithm</title>
<author initials="T." surname="Hoeiland-Joergensen" fullname="T. Hoe
iland-Joergensen">
<organization/>
</author>
<author initials="P." surname="McKenney" fullname="P. McKenney">
<organization/>
</author>
<author initials="D." surname="Taht" fullname="D. Taht">
<organization/>
</author>
<author initials="J." surname="Gettys" fullname="J. Gettys">
<organization/>
</author>
<author initials="E." surname="Dumazet" fullname="E. Dumazet">
<organization/>
</author>
<date year="2018" month="January"/>
<abstract>
<t>This memo presents the FQ-CoDel hybrid packet scheduler and Act
ive Queue Management (AQM) algorithm, a powerful tool for fighting bufferbloat a
nd reducing latency.</t>
<t>FQ-CoDel mixes packets from multiple flows and reduces the impa
ct of head-of-line blocking from bursty traffic. It provides isolation for low-
rate traffic such as DNS, web, and videoconferencing traffic. It improves utili
sation across the networking fabric, especially for bidirectional traffic, by ke
eping queue lengths short, and it can be implemented in a memory- and CPU-effici
ent fashion across a wide range of hardware.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8290"/>
<seriesInfo name="DOI" value="10.17487/RFC8290"/>
</reference>
<reference anchor="RFC8298" target="https://www.rfc-editor.org/info/rfc8
298" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8298.xml">
<front>
<title>Self-Clocked Rate Adaptation for Multimedia</title>
<author initials="I." surname="Johansson" fullname="I. Johansson">
<organization/>
</author>
<author initials="Z." surname="Sarker" fullname="Z. Sarker">
<organization/>
</author>
<date year="2017" month="December"/>
<abstract>
<t>This memo describes a rate adaptation algorithm for conversatio
nal media services such as interactive video. The solution conforms to the pack
et conservation principle and uses a hybrid loss-and-delay- based congestion con
trol algorithm. The algorithm is evaluated over both simulated Internet bottlen
eck scenarios as well as in a Long Term Evolution (LTE) system simulator and is
shown to achieve both low latency and high video throughput in these scenarios.<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="8298"/>
<seriesInfo name="DOI" value="10.17487/RFC8298"/>
</reference>
<reference anchor="I-D.ietf-tcpm-accurate-ecn" target="https://datatrack
er.ietf.org/api/v1/doc/document/draft-ietf-tcpm-accurate-ecn/" xml:base="https:/
/bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tcpm-accurate-ecn.xml">
<front>
<title>More Accurate ECN Feedback in TCP</title>
<author fullname="Bob Briscoe"/>
<author fullname="Mirja Kühlewind"/>
<author fullname="Richard Scheffenegger"/>
<date day="25" month="July" year="2022"/>
<abstract>
<t>Explicit Congestion Notification (ECN) is a mechanism where net
work
nodes can mark IP packets instead of dropping them to indicate
incipient congestion to the end-points. Receivers with an ECN-
capable transport protocol feed back this information to the sender.
ECN was originally specified for TCP in such a way that only one
feedback signal can be transmitted per Round-Trip Time (RTT). Recent
new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP
(DCTCP) or Low Latency Low Loss Scalable Throughput (L4S) need more
accurate ECN feedback information whenever more than one marking is
received in one RTT. This document updates the original ECN
specification to specify a scheme to provide more than one feedback
signal per RTT in the TCP header. Given TCP header space is scarce,
it allocates a reserved header bit previously assigned to the ECN-
Nonce. It also overloads the two existing ECN flags in the TCP
header. The resulting extra space is exploited to feed back the IP-
ECN field received during the 3-way handshake as well. Supplementary
feedback information can optionally be provided in a new TCP option,
which is never used on the TCP SYN. The document also specifies the
treatment of this updated TCP wire protocol by middleboxes.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-accurate-ecn-
20"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-ecn-encap-guidelines" target="https://
datatracker.ietf.org/api/v1/doc/document/draft-ietf-tsvwg-ecn-encap-guidelines/"
xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-e
cn-encap-guidelines.xml">
<front>
<title>Guidelines for Adding Congestion Notification to Protocols th
at Encapsulate IP</title>
<author fullname="Bob Briscoe"/>
<author fullname="John Kaippallimalil"/>
<date day="11" month="July" year="2022"/>
<abstract>
<t>The purpose of this document is to guide the design of congesti
on
notification in any lower layer or tunnelling protocol that
encapsulates IP. The aim is for explicit congestion signals to
propagate consistently from lower layer protocols into IP. Then the
IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the
transport layer (L4). Following these guidelines should assure
interworking among IP layer and lower layer congestion notification
mechanisms, whether specified by the IETF or other standards bodies.
This document updates the advice to subnetwork designers about ECN in
RFC 3819.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-encap-gu
idelines-17"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-rfc6040update-shim" target="https://da
tatracker.ietf.org/api/v1/doc/document/draft-ietf-tsvwg-rfc6040update-shim/" xml
:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-rfc60
40update-shim.xml">
<front>
<title>Propagating Explicit Congestion Notification Across IP Tunnel
Headers Separated by a Shim</title>
<author fullname="Bob Briscoe"/>
<date day="11" month="July" year="2022"/>
<abstract>
<t>RFC 6040 on "Tunnelling of Explicit Congestion Notification" ma
de the
rules for propagation of ECN consistent for all forms of IP in IP
tunnel. This specification updates RFC 6040 to clarify that its
scope includes tunnels where two IP headers are separated by at least
one shim header that is not sufficient on its own for wide area
packet forwarding. It surveys widely deployed IP tunnelling
protocols that use such shim header(s) and updates the specifications
of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE,
Teredo and AMT). This specification also updates RFC 6040 with
configuration requirements needed to make any legacy tunnel ingress
safe.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-rfc6040updat
e-shim-15"/>
</reference>
<reference anchor="I-D.ietf-trill-ecn-support" target="https://datatrack
er.ietf.org/api/v1/doc/document/draft-ietf-trill-ecn-support/" xml:base="https:/
/bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-trill-ecn-support.xml">
<front>
<title>TRILL (TRansparent Interconnection of Lots of Links): ECN (Ex
plicit Congestion Notification) Support</title>
<author fullname="Donald E. Eastlake"/>
<author fullname="Bob Briscoe"/>
<date day="25" month="February" year="2018"/>
<abstract>
<t>Explicit congestion notification (ECN) allows a forwarding elem
ent to
notify downstream devices, including the destination, of the onset of
congestion without having to drop packets. This can improve network
efficiency through better congestion control without packet drops.
This document extends ECN to TRILL (TRansparent Interconnection of
Lots of Links) switches, including integration with IP ECN, and
provides for ECN marking in the TRILL Header Extension Flags Word
(see RFC 7179).</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-trill-ecn-support-
07"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-aqm-dualq-coupled" target="https://dat
atracker.ietf.org/api/v1/doc/document/draft-ietf-tsvwg-aqm-dualq-coupled/" xml:b
ase="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-aqm-dua
lq-coupled.xml">
<front>
<title>DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Thr
oughput (L4S)</title>
<author fullname="Koen De Schepper"/>
<author fullname="Bob Briscoe"/>
<author fullname="Greg White"/>
<date day="7" month="July" year="2022"/>
<abstract>
<t>This specification defines a framework for coupling the Active
Queue
Management (AQM) algorithms in two queues intended for flows with
different responses to congestion. This provides a way for the
Internet to transition from the scaling problems of standard TCP
Reno-friendly ('Classic') congestion controls to the family of
'Scalable' congestion controls. These are designed for consistently
very Low queuing Latency, very Low congestion Loss and Scaling of
per-flow throughput (L4S) by using Explicit Congestion Notification
(ECN) in a modified way. Until the Coupled DualQ, these L4S senders
could only be deployed where a clean-slate environment could be
arranged, such as in private data centres. The coupling acts like a
semi-permeable membrane: isolating the sub-millisecond average
queuing delay and zero congestion loss of L4S from Classic latency
and loss; but pooling the capacity between any combination of
Scalable and Classic flows with roughly equivalent throughput per
flow. The DualQ achieves this indirectly, without having to inspect
transport layer flow identifiers and without compromising the
performance of the Classic traffic, relative to a single queue. The
DualQ design has low complexity and requires no configuration for the
public Internet.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-aqm-dualq-co
upled-24"/>
</reference>
<reference anchor="I-D.stewart-tsvwg-sctpecn" target="https://www.ietf.o
rg/archive/id/draft-stewart-tsvwg-sctpecn-05.txt" xml:base="https://bib.ietf.org
/public/rfc/bibxml-ids/reference.I-D.stewart-tsvwg-sctpecn.xml">
<front>
<title>ECN for Stream Control Transmission Protocol (SCTP)</title>
<author fullname="Randall R. Stewart"/>
<author fullname="Michael Tuexen"/>
<author fullname="Xuesong Dong"/>
<date day="15" month="January" year="2014"/>
<abstract>
<t>This document describes the addition of the ECN to the Stream C
ontrol Transmission Protocol (SCTP).</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-stewart-tsvwg-sctpecn-0
5"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-l4s-arch" target="https://datatracker.
ietf.org/api/v1/doc/document/draft-ietf-tsvwg-l4s-arch/" xml:base="https://bib.i
etf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-l4s-arch.xml">
<front>
<title>Low Latency, Low Loss, Scalable Throughput (L4S) Internet Ser
vice: Architecture</title>
<author fullname="Bob Briscoe"/>
<author fullname="Koen De Schepper"/>
<author fullname="Marcelo Bagnulo"/>
<author fullname="Greg White"/>
<date day="27" month="July" year="2022"/>
<abstract>
<t>This document describes the L4S architecture, which enables Int
ernet
applications to achieve Low queuing Latency, Low Loss, and Scalable
throughput (L4S). The insight on which L4S is based is that the root
cause of queuing delay is in the congestion controllers of senders,
not in the queue itself. With the L4S architecture all Internet
applications could (but do not have to) transition away from
congestion control algorithms that cause substantial queuing delay,
to a new class of congestion controls that induce very little
queuing, aided by explicit congestion signalling from the network.
This new class of congestion controls can provide low latency for
capacity-seeking flows, so applications can achieve both high
bandwidth and low latency.</t>
<t>The architecture primarily concerns incremental deployment. It
defines mechanisms that allow the new class of L4S congestion
controls to coexist with 'Classic' congestion controls in a shared
network. These mechanisms aim to ensure that the latency and
throughput performance using an L4S-compliant congestion controller
is usually much better (and rarely worse) than performance would have
been using a 'Classic' congestion controller, and that competing
flows continuing to use 'Classic' controllers are typically not
impacted by the presence of L4S. These characteristics are important
to encourage adoption of L4S congestion control algorithms and L4S
compliant network elements.</t>
<t>The L4S architecture consists of three components: network supp
ort to
isolate L4S traffic from classic traffic; protocol features that
allow network elements to identify L4S traffic; and host support for
L4S congestion controls. The protocol is defined separately as an
experimental change to Explicit Congestion Notification (ECN).</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-l4s-arch-19"
/>
</reference>
<reference anchor="I-D.briscoe-tsvwg-l4s-diffserv" target="https://datat
racker.ietf.org/api/v1/doc/document/draft-briscoe-tsvwg-l4s-diffserv/" xml:base=
"https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.briscoe-tsvwg-l4s-diff
serv.xml">
<front>
<title>Interactions between Low Latency, Low Loss, Scalable Throughp
ut (L4S) and Differentiated Services</title>
<author fullname="Bob Briscoe"/>
<date day="2" month="July" year="2018"/>
<abstract>
<t>L4S and Diffserv offer somewhat overlapping services (low laten
cy and
low loss), but bandwidth allocation is out of scope for L4S.
Therefore there is scope for the two approaches to complement each
other, but also to conflict. This informational document explains
how the two approaches interact, how they can be arranged to
complement each other and in which cases one can stand alone without
needing the other.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-briscoe-tsvwg-l4s-diffs
erv-02"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-nqb" target="https://datatracker.ietf.
org/api/v1/doc/document/draft-ietf-tsvwg-nqb/" xml:base="https://bib.ietf.org/pu
blic/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-nqb.xml">
<front>
<title>A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Different
iated Services</title>
<author fullname="Greg White"/>
<author fullname="Thomas Fossati"/>
<date day="4" month="March" year="2022"/>
<abstract>
<t>This document specifies properties and characteristics of a Non
-
Queue-Building Per-Hop Behavior (NQB PHB). The purpose of this NQB
PHB is to provide a separate queue that enables smooth, low-data-
rate, application-limited traffic flows, which would ordinarily share
a queue with bursty and capacity-seeking traffic, to avoid the
latency, latency variation and loss caused by such traffic. This PHB
is implemented without prioritization and without rate policing,
making it suitable for environments where the use of either these
features may be restricted. The NQB PHB has been developed primarily
for use by access network segments, where queuing delays and queuing
loss caused by Queue-Building protocols are manifested, but its use
is not limited to such segments. In particular, applications to
cable broadband links, Wi-Fi links, and mobile network radio and core
segments are discussed. This document recommends a specific
Differentiated Services Code Point (DSCP) to identify Non-Queue-
Building flows.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-nqb-10"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-l4sops" target="https://datatracker.ie
tf.org/api/v1/doc/document/draft-ietf-tsvwg-l4sops/" xml:base="https://bib.ietf.
org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-l4sops.xml">
<front>
<title>Operational Guidance for Deployment of L4S in the Internet</t
itle>
<author fullname="Greg White"/>
<date day="28" month="April" year="2022"/>
<abstract>
<t>This document is intended to provide guidance in order to ensur
e
successful deployment of Low Latency Low Loss Scalable throughput
(L4S) in the Internet. Other L4S documents provide guidance for
running an L4S experiment, but this document is focused solely on
potential interactions between L4S flows and flows using the original
('Classic') ECN over a Classic ECN bottleneck link. The document
discusses the potential outcomes of these interactions, describes
mechanisms to detect the presence of Classic ECN bottlenecks, and
identifies opportunities to prevent and/or detect and resolve
fairness problems in such networks. This guidance is aimed at
operators of end-systems, operators of networks, and researchers.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-l4sops-03"/>
</reference>
<reference anchor="RFC8311" target="https://www.rfc-editor.org/info/rfc8
311" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml">
<front>
<title>Relaxing Restrictions on Explicit Congestion Notification (EC
N) Experimentation</title>
<author initials="D." surname="Black" fullname="D. Black">
<organization/>
</author>
<date year="2018" month="January"/>
<abstract>
<t>This memo updates RFC 3168, which specifies Explicit Congestion
Notification (ECN) as an alternative to packet drops for indicating network con
gestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimen
tation towards benefits beyond just removal of loss. This memo summarizes the a
nticipated areas of experimentation and updates RFC 3168 to enable experimentati
on in these areas. An Experimental RFC in the IETF document stream is required
to take advantage of any of these enabling updates. In addition, this memo make
s related updates to the ECN specifications for RTP in RFC 6679 and for the Data
gram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo
also records the conclusion of the ECN nonce experiment in RFC 3540 and provide
s the rationale for reclassification of RFC 3540 from Experimental to Historic;
this reclassification enables new experimental use of the ECT(1) codepoint.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8311"/>
<seriesInfo name="DOI" value="10.17487/RFC8311"/>
</reference>
<reference anchor="I-D.ietf-tcpm-generalized-ecn" target="https://datatr
acker.ietf.org/api/v1/doc/document/draft-ietf-tcpm-generalized-ecn/" xml:base="h
ttps://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tcpm-generalized-ec
n.xml">
<front>
<title>ECN++: Adding Explicit Congestion Notification (ECN) to TCP C
ontrol Packets</title>
<author fullname="Marcelo Bagnulo"/>
<author fullname="Bob Briscoe"/>
<date day="27" month="July" year="2022"/>
<abstract>
<t>This document describes an experimental modification to ECN whe
n used
with TCP. It allows the use of ECN on the following TCP packets:
SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-generalized-e
cn-10"/>
</reference>
<reference anchor="ARED01" target="https://www.icir.org/floyd/red.html">
<front> <front>
<title>Adaptive RED: An Algorithm for Increasing the Robustness of <title>Adaptive RED: An Algorithm for Increasing the Robustness of
RED's Active Queue Management</title> RED's Active Queue Management</title>
<author fullname="Sally Floyd" initials="S." surname="Floyd"> <author fullname="Sally Floyd" initials="S." surname="Floyd">
<organization>ACIRI</organization> <organization>ACIRI</organization>
</author> </author>
<author fullname="Ramakrishna Gummadi" initials="R." surname="Gummad i"> <author fullname="Ramakrishna Gummadi" initials="R." surname="Gummad i">
<organization>ACIRI</organization> <organization>ACIRI</organization>
</author> </author>
<author fullname="S. Shenker" initials="S." surname="Shenker"> <author fullname="S. Shenker" initials="S." surname="Shenker">
<organization>ACIRI</organization> <organization>ACIRI</organization>
</author> </author>
<date month="August" year="2001"/> <date month="August" year="2001"/>
</front> </front>
<seriesInfo name="ACIRI Technical Report" value=""/> <refcontent>ACIRI Technical Report 301</refcontent>
</reference>
<reference anchor="RFC8257" target="https://www.rfc-editor.org/info/rfc8
257" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8257.xml">
<front>
<title>Data Center TCP (DCTCP): TCP Congestion Control for Data Cent
ers</title>
<author initials="S." surname="Bensley" fullname="S. Bensley">
<organization/>
</author>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization/>
</author>
<author initials="P." surname="Balasubramanian" fullname="P. Balasub
ramanian">
<organization/>
</author>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization/>
</author>
<author initials="G." surname="Judd" fullname="G. Judd">
<organization/>
</author>
<date year="2017" month="October"/>
<abstract>
<t>This Informational RFC describes Data Center TCP (DCTCP): a TCP
congestion control scheme for data-center traffic. DCTCP extends the Explicit
Congestion Notification (ECN) processing to estimate the fraction of bytes that
encounter congestion rather than simply detecting that some congestion has occur
red. DCTCP then scales the TCP congestion window based on this estimate. This
method achieves high-burst tolerance, low latency, and high throughput with shal
low- buffered switches. This memo also discusses deployment issues related to t
he coexistence of DCTCP and conventional TCP, discusses the lack of a negotiatin
g mechanism between sender and receiver, and presents some possible mitigations.
This memo documents DCTCP as currently implemented by several major operating
systems. DCTCP, as described in this specification, is applicable to deployment
s in controlled environments like data centers, but it must not be deployed over
the public Internet without additional measures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8257"/>
<seriesInfo name="DOI" value="10.17487/RFC8257"/>
</reference>
<reference anchor="RFC8312" target="https://www.rfc-editor.org/info/rfc8
312" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8312.xml">
<front>
<title>CUBIC for Fast Long-Distance Networks</title>
<author initials="I." surname="Rhee" fullname="I. Rhee">
<organization/>
</author>
<author initials="L." surname="Xu" fullname="L. Xu">
<organization/>
</author>
<author initials="S." surname="Ha" fullname="S. Ha">
<organization/>
</author>
<author initials="A." surname="Zimmermann" fullname="A. Zimmermann">
<organization/>
</author>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization/>
</author>
<author initials="R." surname="Scheffenegger" fullname="R. Scheffene
gger">
<organization/>
</author>
<date year="2018" month="February"/>
<abstract>
<t>CUBIC is an extension to the current TCP standards. It differs
from the current TCP standards only in the congestion control algorithm on the
sender side. In particular, it uses a cubic function instead of a linear window
increase function of the current TCP standards to improve scalability and stabi
lity under fast and long-distance networks. CUBIC and its predecessor algorithm
have been adopted as defaults by Linux and have been used for many years. This
document provides a specification of CUBIC to enable third-party implementation
s and to solicit community feedback through experimentation on the performance o
f CUBIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8312"/>
<seriesInfo name="DOI" value="10.17487/RFC8312"/>
</reference>
<reference anchor="RFC8511" target="https://www.rfc-editor.org/info/rfc8
511" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8511.xml">
<front>
<title>TCP Alternative Backoff with ECN (ABE)</title>
<author initials="N." surname="Khademi" fullname="N. Khademi">
<organization/>
</author>
<author initials="M." surname="Welzl" fullname="M. Welzl">
<organization/>
</author>
<author initials="G." surname="Armitage" fullname="G. Armitage">
<organization/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization/>
</author>
<date year="2018" month="December"/>
<abstract>
<t>Active Queue Management (AQM) mechanisms allow for burst tolera
nce while enforcing short queues to minimise the time that packets spend enqueue
d at a bottleneck. This can cause noticeable performance degradation for TCP co
nnections traversing such a bottleneck, especially if there are only a few flows
or their bandwidth-delay product (BDP) is large. The reception of a Congestion
Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an
AQM mechanism is used at the bottleneck, and the bottleneck network queue is the
refore likely to be short. Feedback of this signal allows the TCP sender-side E
CN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a
smaller amount than the congestion control algorithm's reaction to inferred pack
et loss. Therefore, this specification defines an experimental change to the TCP
reaction specified in RFC 3168, as permitted by RFC 8311.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8511"/>
<seriesInfo name="DOI" value="10.17487/RFC8511"/>
</reference>
<reference anchor="RFC8985" target="https://www.rfc-editor.org/info/rfc8
985" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8985.xml">
<front>
<title>The RACK-TLP Loss Detection Algorithm for TCP</title>
<author initials="Y." surname="Cheng" fullname="Y. Cheng">
<organization/>
</author>
<author initials="N." surname="Cardwell" fullname="N. Cardwell">
<organization/>
</author>
<author initials="N." surname="Dukkipati" fullname="N. Dukkipati">
<organization/>
</author>
<author initials="P." surname="Jha" fullname="P. Jha">
<organization/>
</author>
<date year="2021" month="February"/>
<abstract>
<t>This document presents the RACK-TLP loss detection algorithm fo
r TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgmen
ts (SACKs) and has two parts. Recent Acknowledgment (RACK) starts fast recovery
quickly using time-based inferences derived from acknowledgment (ACK) feedback,
and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK
feedback to avoid retransmission timeout (RTO) events. Compared to the widely u
sed duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losse
s more efficiently when there are application-limited flights of data, lost retr
ansmissions, or data packet reordering events. It is intended to be an alternati
ve to the DupAck threshold approach.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8985"/>
<seriesInfo name="DOI" value="10.17487/RFC8985"/>
</reference>
<reference anchor="RFC8888" target="https://www.rfc-editor.org/info/rfc8
888" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8888.xml">
<front>
<title>RTP Control Protocol (RTCP) Feedback for Congestion Control</
title>
<author initials="Z." surname="Sarker" fullname="Z. Sarker">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<author initials="V." surname="Singh" fullname="V. Singh">
<organization/>
</author>
<author initials="M." surname="Ramalho" fullname="M. Ramalho">
<organization/>
</author>
<date year="2021" month="January"/>
<abstract>
<t>An effective RTP congestion control algorithm requires more fin
e-grained feedback on packet loss, timing, and Explicit Congestion Notification
(ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender
Report (SR) and Receiver Report (RR) packets. This document describes an RTCP fe
edback message intended to enable congestion control for interactive real-time t
raffic using RTP. The feedback message is designed for use with a sender-based c
ongestion control algorithm, in which the receiver of an RTP flow sends back to
the sender RTCP feedback packets containing the information the sender needs to
perform congestion control.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8888"/>
<seriesInfo name="DOI" value="10.17487/RFC8888"/>
</reference>
<reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9
000" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author initials="J." surname="Iyengar" fullname="J. Iyengar" role="
editor">
<organization/>
</author>
<author initials="M." surname="Thomson" fullname="M. Thomson" role="
editor">
<organization/>
</author>
<date year="2021" month="May"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC9001" target="https://www.rfc-editor.org/info/rfc9
001" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml">
<front>
<title>Using TLS to Secure QUIC</title>
<author initials="M." surname="Thomson" fullname="M. Thomson" role="
editor">
<organization/>
</author>
<author initials="S." surname="Turner" fullname="S. Turner" role="ed
itor">
<organization/>
</author>
<date year="2021" month="May"/>
<abstract>
<t>This document describes how Transport Layer Security (TLS) is u
sed to secure QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9001"/>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference>
<reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9
147" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization/>
</author>
<author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization/>
</author>
<date year="2022" month="April"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="I-D.sridharan-tcpm-ctcp" target="https://datatracker.
ietf.org/api/v1/doc/document/draft-sridharan-tcpm-ctcp/" xml:base="https://bib.i
etf.org/public/rfc/bibxml-ids/reference.I-D.sridharan-tcpm-ctcp.xml">
<front>
<title>Compound TCP: A New TCP Congestion Control for High-Speed and
Long Distance Networks</title>
<author fullname="Murali Sridharan"/>
<author fullname="Kun Tan"/>
<author fullname="Deepak Bansal"/>
<author fullname="Dave Thaler"/>
<date day="29" month="October" year="2007"/>
<abstract>
<t>Compound TCP (CTCP) is a modification to TCP's congestion contr
ol &#13;
mechanism for use with TCP connections with large congestion windows. &#13;
This document describes the Compound TCP algorithm in detail, and &#13;
solicits experimentation and feedback from the wider community. The &#13;
key idea behind CTCP is to add a scalable delay-based component to the &#13;
standard TCP's loss-based congestion control. The sending rate of CTCP &#13;
is controlled by both loss and delay components. The delay-based &#13;
component has a scalable window increasing rule that not only &#13;
efficiently uses the link capacity, but on sensing queue build up, &#13;
proactively reduces the sending rate.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-sridharan-tcpm-ctcp-02"
/>
</reference>
<reference anchor="I-D.briscoe-docsis-q-protection" target="https://data
tracker.ietf.org/api/v1/doc/document/draft-briscoe-docsis-q-protection/" xml:bas
e="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.briscoe-docsis-q-pro
tection.xml">
<front>
<title>The DOCSIS(r) Queue Protection Algorithm to Preserve Low Late
ncy</title>
<author fullname="Bob Briscoe"/>
<author fullname="Greg White"/>
<date day="13" month="May" year="2022"/>
<abstract>
<t>This informational document explains the specification of the q
ueue
protection algorithm used in DOCSIS technology since version 3.1. A
shared low latency queue relies on the non-queue-building behaviour
of every traffic flow using it. However, some flows might not take
such care, either accidentally or maliciously. If a queue is about
to exceed a threshold level of delay, the queue protection algorithm
can rapidly detect the flows most likely to be responsible. It can
then prevent harm to other traffic in the low latency queue by
ejecting selected packets (or all packets) of these flows. The
document is designed for four types of audience: a) congestion
control designers who need to understand how to keep on the 'good'
side of the algorithm; b) implementers of the algorithm who want to
understand it in more depth; c) designers of algorithms with similar
goals, perhaps for non-DOCSIS scenarios; and d) researchers
interested in evaluating the algorithm.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-briscoe-docsis-q-protec
tion-06"/>
</reference>
<reference anchor="I-D.briscoe-iccrg-prague-congestion-control" target="
https://datatracker.ietf.org/api/v1/doc/document/draft-briscoe-iccrg-prague-cong
estion-control/" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.
I-D.briscoe-iccrg-prague-congestion-control.xml">
<front>
<title>Prague Congestion Control</title>
<author fullname="Koen De Schepper"/>
<author fullname="Olivier Tilmans"/>
<author fullname="Bob Briscoe"/>
<date day="11" month="July" year="2022"/>
<abstract>
<t>This specification defines the Prague congestion control scheme
,
which is derived from DCTCP and adapted for Internet traffic by
implementing the Prague L4S requirements. Over paths with L4S
support at the bottleneck, it adapts the DCTCP mechanisms to achieve
consistently low latency and full throughput. It is defined
independently of any particular transport protocol or operating
system, but notes are added that highlight issues specific to certain
transports and OSs. It is mainly based on the current default
options of the reference Linux implementation of TCP Prague, but it
includes experience from other implementations where available. It
separately describes non-default and optional parts, as well as
future plans.</t>
<t>The implementation does not satisfy all the Prague requirements
(yet)
and the IETF might decide that certain requirements need to be
relaxed as an outcome of the process of trying to satisfy them all.
In two cases, research code is replaced by placeholders until full
evaluation is complete.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-briscoe-iccrg-prague-co
ngestion-control-01"/>
</reference>
<reference anchor="I-D.cardwell-iccrg-bbr-congestion-control" target="ht
tps://datatracker.ietf.org/api/v1/doc/document/draft-cardwell-iccrg-bbr-congesti
on-control/" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.
cardwell-iccrg-bbr-congestion-control.xml">
<front>
<title>BBR Congestion Control</title>
<author fullname="Neal Cardwell"/>
<author fullname="Yuchung Cheng"/>
<author fullname="Soheil Hassas Yeganeh"/>
<author fullname="Ian Swett"/>
<author fullname="Van Jacobson"/>
<date day="7" month="March" year="2022"/>
<abstract>
<t>This document specifies the BBR congestion control algorithm.
BBR
("Bottleneck Bandwidth and Round-trip propagation time") uses recent
measurements of a transport connection's delivery rate, round-trip
time, and packet loss rate to build an explicit model of the network
path. BBR then uses this model to control both how fast it sends
data and the maximum volume of data it allows in flight in the
network at any time. Relative to loss-based congestion control
algorithms such as Reno [RFC5681] or CUBIC [RFC8312], BBR offers
substantially higher throughput for bottlenecks with shallow buffers
or random losses, and substantially lower queueing delays for
bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be
implemented in any transport protocol that supports packet-delivery
acknowledgment. Thus far, open source implementations are available
for TCP [RFC793] and QUIC [RFC9000]. This document specifies version
2 of the BBR algorithm, also sometimes referred to as BBRv2 or bbr2.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-cong
estion-control-02"/>
</reference>
<reference anchor="I-D.mathis-iccrg-relentless-tcp" target="https://www.
ietf.org/archive/id/draft-mathis-iccrg-relentless-tcp-00.txt" xml:base="https://
bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.mathis-iccrg-relentless-tcp.xml
">
<front>
<title>Relentless Congestion Control</title>
<author fullname="Matt Mathis"/>
<date day="4" month="March" year="2009"/>
<abstract>
<t>Relentless congestion control is a simple modification that can
be applied to almost any AIMD style congestion control: instead of applying a m
ultiplicative reduction to cwnd after a loss, cwnd is reduced by the number of l
ost segments. It can be modeled as a strict implementation of van Jacobson's Pac
ket Conservation Principle. During recovery, new segments are injected into the
network in exact accordance with the segments that are reported to have been del
ivered to the receiver by the returning ACKs. This algorithm offers a valuable n
ew congestion control property: the TCP portion of the control loop has exactly
unity gain, which should make it easier to implement simple controllers in netwo
rk devices to accurately control queue sizes across a huge range of scales. Rele
ntless Congestion Control conforms to neither the details nor the philosophy of
current congestion control standards. These standards are based on the idea that
the Internet can attain sufficient fairness by having relatively simple network
devices send uniform congestion signals to all flows, and mandating that all pr
otocols have equivalent responses to these congestion signals. To function appro
priately in a shared environment, Relentless Congestion Control requires that th
e network allocates capacity through some technique such as Fair Queuing, Approx
imate Fair Dropping, etc. The salient features of these algorithms are that they
segregate the traffic into distinct flows, and send different congestion signal
s to each flow. This alternative congestion control paradigm is described in a s
eparate document, also under consideration by the ICCRG. The goal of the documen
t is to illustrate some new protocol features and properties might be possible i
f we relax the "TCP-friendly" mandate. A secondary goal of Relentless TCP is to
make a distinction between the bottlenecks that belong to protocol itself, vs st
andard congestion control and the "TCP-friendly" paradigm.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-mathis-iccrg-relentless
-tcp-00"/>
</reference> </reference>
<reference anchor="BBRv2" target="https://github.com/google/bbr/blob/v2a
lpha/README.md"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8257.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8312.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8511.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8985.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8888.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9001.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9147.
xml"/>
<!-- [I-D.sridharan-tcpm-ctcp] IESG state Expired as of 1/1/7/23. xi:include Wro
ng date.-->
<reference anchor="I-D.sridharan-tcpm-ctcp">
<front>
<title>Compound TCP: A New TCP Congestion Control for High-Speed and Long Di
stance Networks
</title>
<author initials="M." surname="Sridharan" fullname="Murari Sridharan">
<organization>Microsoft</organization>
</author>
<author initials="K." surname="Tan" fullname="Kun Tan">
<organization>Microsoft Research</organization>
</author>
<author initials="D." surname="Bansal" fullname="Deepak Bansal">
<organization>Microsoft</organization>
</author>
<author initials="D." surname="Thaler" fullname="Dave Thaler">
<organization>Microsoft</organization>
</author>
<date month="November" day="3" year="2008"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-sridharan-tcpm-ctcp-02"/>
</reference>
<!-- [I-D.briscoe-docsis-q-protection] in MISSREF state as of 1/17/23. xi:includ
e is missing editor role -->
<reference anchor="I-D.briscoe-docsis-q-protection">
<front>
<title>The DOCSIS® Queue Protection Algorithm to Preserve Low Latency</title
>
<author fullname="Bob Briscoe" role="editor">
<organization>Independent</organization>
</author>
<author fullname="Greg White">
<organization>CableLabs</organization>
</author>
<date day="13" month="May" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-briscoe-docsis-q-protection-06"
/>
</reference>
<!-- [I-D.briscoe-iccrg-prague-congestion-control] Expired as of 1/17/23. Missin
g editor role. -->
<reference anchor="I-D.briscoe-iccrg-prague-congestion-control">
<front>
<title>Prague Congestion Control</title>
<author fullname="Koen De Schepper" surname="De Schepper" initials="K.">
<organization>Nokia Bell Labs</organization>
</author>
<author fullname="Olivier Tilmans">
<organization>Nokia Bell Labs</organization>
</author>
<author fullname="Bob Briscoe" role="editor">
<organization>Independent</organization>
</author>
<date month="July" day="11" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-briscoe-iccrg-prague-congestion
-control-01"/>
</reference>
<!-- [I-D.cardwell-iccrg-bbr-congestion-control] IESG state
Expired as of 1/17/23. xi:include incorrectly shows Hassas Yeganeh's name as
"S. H. Yeganeh" when it should be "S. Hassas Yeganeh" -->
<reference anchor="I-D.cardwell-iccrg-bbr-congestion-control">
<front>
<title>BBR Congestion Control</title>
<author initials="N." surname="Cardwell" fullname="Neal Cardwell">
<organization>Google</organization>
</author>
<author initials="Y." surname="Cheng" fullname="Yuchung Cheng">
<organization>Google</organization>
</author>
<author initials="S." surname="Hassas Yeganeh" fullname="Soheil Hassas Yegan
eh">
<organization>Google</organization>
</author>
<author initials="I." surname="Swett" fullname="Ian Swett">
<organization>Google</organization>
</author>
<author initials="V." surname="Jacobson" fullname="Van Jacobson">
<organization>Google</organization>
</author>
<date month="March" day="7" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-congestion-c
ontrol-02"/>
</reference>
<!-- [I-D.mathis-iccrg-relentless-tcp] IESG state Expired as of 1/17/23 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.mathis-
iccrg-relentless-tcp.xml"/>
<reference anchor="BBRv2" target="https://github.com/google/bbr">
<front> <front>
<title>BRTCP BBR v2 Alpha/Preview Release</title> <title>TCP BBR v2 Alpha/Preview Release</title>
<author fullname="Neal Cardwell" initials="N" surname="Cardwell"> <author/>
<organization/> <date month="June" year="2022"/>
</author>
<date/>
</front> </front>
<seriesInfo name="GitHub repository;" value="Linux congestion control module"/> <refcontent>commit 17700ca</refcontent>
</reference> </reference>
<!--{ToDo: DCttH ref will need to be updated, once stable}-->
<reference anchor="DCttH19" target="https://bobbriscoe.net/pubs.html#DCttH _TR"> <reference anchor="DCttH19" target="https://bobbriscoe.net/projects/latenc y/dctth_journal_draft20190726.pdf">
<front> <front>
<title>`Data Centre to the Home': Ultra-Low Latency for All</title> <title>'Data Centre to the Home': Ultra-Low Latency for All</title>
<author fullname="Koen De Schepper" initials="K." surname="De Schepp er"> <author fullname="Koen De Schepper" initials="K." surname="De Schepp er">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
</author> </author>
<author fullname="Olga Bondarenko" initials="O." surname="Bondarenko "> <author fullname="Olga Bondarenko" initials="O." surname="Bondarenko ">
<organization>Simula Research Lab</organization> <organization>Simula Research Lab</organization>
</author> </author>
<author fullname="Olivier" initials="O." surname="Tilmans"> <author fullname="Olivier" initials="O." surname="Tilmans">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
</author> </author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent (bobbriscoe.net)</organization> <organization>Independent (bobbriscoe.net)</organization>
</author> </author>
<date month="July" year="2019"/> <date month="July" year="2019"/>
</front> </front>
<seriesInfo name="Updated RITE project Technical Report" value=""/> <refcontent>Updated RITE project Technical Report</refcontent>
<format target="https://bobbriscoe.net/projects/latency/dctth_journal_
draft20190726.pdf" type="PDF"/>
</reference> </reference>
<reference anchor="L4Seval22" target="https://arxiv.org/abs/2209.01078">
<front>
<title>Dual Queue Coupled AQM: Deployable Very Low Queuing Delay for
All</title>
<author fullname="Koen De Schepper" initials="K." surname="De Schepper
">
<organization>Nokia Bell Labs</organization>
</author>
<author fullname="Olga Albisser" initials="O." surname="Albisser">
<organization>Simula Research Lab</organization>
</author>
<author fullname="Olivier Tilmans" initials="O." surname="Tilmans">
<organization>Nokia Bell Labs</organization>
</author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent (bobbriscoe.net)</organization>
</author>
<date month="September" year="2022"/>
</front>
<seriesInfo name="DOI" value="10.48550/arXiv.2209.01078"/>
<refcontent>Preprint submitted to IEEE/ACM Transactions on Networking</r
efcontent>
</reference>
<reference anchor="PI2" target="https://dl.acm.org/citation.cfm?doid=299 9572.2999578"> <reference anchor="PI2" target="https://dl.acm.org/citation.cfm?doid=299 9572.2999578">
<front> <front>
<title>PI^2 : A Linearized AQM for both Classic and Scalable <title>PI^2: A Linearized AQM for both Classic and Scalable
TCP</title> TCP</title>
<author fullname="Koen De Schepper" initials="K." surname="De Schepp er"> <author fullname="Koen De Schepper" initials="K." surname="De Schepp er">
<organization>Bell Labs</organization> <organization>Bell Labs</organization>
</author> </author>
<author fullname="Olga Bondarenko" initials="O." surname="Bondarenko "> <author fullname="Olga Bondarenko" initials="O." surname="Bondarenko ">
<organization>Simula Research Lab</organization> <organization>Simula Research Lab</organization>
</author> </author>
<author fullname="Ing-jyh Tsang" initials="I." surname="Tsang"> <author fullname="Ing-jyh Tsang" initials="I." surname="Tsang">
<organization>Bell Labs</organization> <organization>Bell Labs</organization>
</author> </author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization> <organization>BT</organization>
</author> </author>
<date month="December" year="2016"/> <date month="December" year="2016"/>
</front> </front>
<seriesInfo name="Proc. ACM CoNEXT 2016" value="pp.105-119"/> <seriesInfo name="DOI" value="10.1145/2999572.2999578"/>
<refcontent>Proceedings of ACM CoNEXT 2016, pp. 105-119</refcontent>
</reference> </reference>
<reference anchor="VCP" target="https://doi.acm.org/10.1145/1080091.1080 098"> <reference anchor="VCP" target="https://doi.acm.org/10.1145/1080091.1080 098">
<front> <front>
<title>One more bit is enough</title> <title>One more bit is enough</title>
<author fullname="Yong Xia" initials="Y." surname="Xia"> <author fullname="Yong Xia" initials="Y." surname="Xia">
<organization/> <organization/>
</author> </author>
<author fullname="Lakshminarayanan Subramanian" initials="L." surnam e="Subramanian"> <author fullname="Lakshminarayanan Subramanian" initials="L." surnam e="Subramanian">
<organization/> <organization/>
</author> </author>
<author fullname="Ion Stoica" initials="I." surname="Stoica"> <author fullname="Ion Stoica" initials="I." surname="Stoica">
<organization/> <organization/>
</author> </author>
<author fullname="Shivkumar Kalyanaraman" initials="S." surname="Kal yanaraman"> <author fullname="Shivkumar Kalyanaraman" initials="S." surname="Kal yanaraman">
<organization/> <organization/>
</author> </author>
<date month="" year="2005"/> <date month="August" year="2005"/>
</front> </front>
<seriesInfo name="Proc. SIGCOMM'05, ACM CCR" value="35(4)37--48"/> <seriesInfo name="DOI" value="10.1145/1080091.1080098"/>
<format target="https://conferences.sigcomm.org/sigcomm/2005/paper-Xia <refcontent>SIGCOMM '05: Proceedings of the 2005 conference on Applicat
Sub.pdf" type="PDF"/> ions, technologies, architectures, and protocols for computer communications, pp
. 37–48</refcontent>
</reference> </reference>
<reference anchor="QV" target="https://riteproject.files.wordpress.com/2 015/12/rite-deliverable-2-3.pdf"> <reference anchor="QV" target="https://riteproject.files.wordpress.com/2 015/12/rite-deliverable-2-3.pdf">
<front> <front>
<title>Up to Speed with Queue View</title> <title>Report on Prototype Development and Evaluation of Network and Interaction Techniques</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization> <organization>BT</organization>
</author> </author>
<author fullname="Per Hurtig" initials="P." surname="Hurtig"> <author fullname="Per Hurtig" initials="P." surname="Hurtig">
<organization>Uni Karlstad</organization> <organization>Karlstad University</organization>
</author> </author>
<date month="August" year="2015"/> <date month="September" year="2015"/>
</front> </front>
<seriesInfo name="RITE Technical Report" value="D2.3; Appendix C.2"/> <refcontent>RITE Technical Report, Deliverable 2.3, Appendix C.2: "Up to Speed with Queue View"</refcontent>
</reference> </reference>
<reference anchor="Alizadeh-stability" target="https://people.csail.mit.
edu/alizadeh/papers/dctcp_analysis-sigmetrics11.pdf"> <reference anchor="Alizadeh-stability" target="https://dl.acm.org/doi/10
.1145/1993744.1993753">
<front> <front>
<title>Analysis of DCTCP: Stability, Convergence, and <title>Analysis of DCTCP: Stability, Convergence, and
Fairness</title> Fairness</title>
<author fullname="Mohamed Alizadeh" initials="M." surname="Alizadeh" /> <author fullname="Mohamed Alizadeh" initials="M." surname="Alizadeh" />
<author fullname="Adel Javanmard" initials="A." surname="Javanmard"/ > <author fullname="Adel Javanmard" initials="A." surname="Javanmard"/ >
<author fullname="Balaji Prabhakar" initials="B." surname="Prabhakar "/> <author fullname="Balaji Prabhakar" initials="B." surname="Prabhakar "/>
<date month="June" year="2011"/> <date month="June" year="2011"/>
</front> </front>
<seriesInfo name="ACM SIGMETRICS 2011" value=""/> <seriesInfo name="DOI" value="10.1145/1993744.1993753"/>
<refcontent>SIGMETRICS '11: Proceedings of the ACM SIGMETRICS Joint In
ternational Conference on Measurement and Modeling of Computer Systems, pp. 73-8
4</refcontent>
<format target="https://people.csail.mit.edu/alizadeh/papers/dctcp_ana
lysis-sigmetrics11.pdf" type="PDF"/>
</reference> </reference>
<reference anchor="TCPPrague" target="https://www.ietf.org/mail-archive/ web/tcpprague/current/msg00001.html"> <reference anchor="TCPPrague" target="https://www.ietf.org/mail-archive/ web/tcpprague/current/msg00001.html">
<front> <front>
<title>Notes: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, <title>Notes: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40,
Prague</title> Prague</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Simula</organization> <organization>Simula</organization>
</author> </author>
<date month="July" year="2015"/> <date month="July" year="2015"/>
</front> </front>
<seriesInfo name="tcpprague mailing list archive" value=""/> <refcontent>message to the tcpPrague mailing list</refcontent>
</reference> </reference>
<reference anchor="sub-mss-prob" target="https://arxiv.org/abs/1904.0759 8"> <reference anchor="sub-mss-prob" target="https://arxiv.org/abs/1904.0759 8">
<front> <front>
<title>Scaling TCP's Congestion Window for Small Round Trip <title>Scaling TCP's Congestion Window for Small Round Trip
Times</title> Times</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization> <organization>BT</organization>
</author> </author>
<author fullname="Koen De Schepper" initials="K." surname="De Schepp er"> <author fullname="Koen De Schepper" initials="K." surname="De Schepp er">
<organization>Bell Labs</organization> <organization>Bell Labs</organization>
</author> </author>
<date month="May" year="2015"/> <date month="May" year="2015"/>
</front> </front>
<seriesInfo name="BT Technical Report" value="TR-TUB8-2015-002"/> <seriesInfo name="DOI" value="10.48550/arXiv.1904.07598"/>
<format target="https://arxiv.org/pdf/1904.07598" type="PDF"/> <refcontent>BT Technical Report: TR-TUB8-2015-002</refcontent>
</reference> </reference>
<reference anchor="ecn-fallback" target="https://arxiv.org/abs/1911.0071 0"> <reference anchor="ecn-fallback" target="https://arxiv.org/abs/1911.0071 0">
<front> <front>
<title>TCP Prague Fall-back on Detection of a Classic ECN <title>TCP Prague Fall-back on Detection of a Classic ECN
AQM</title> AQM</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization> <organization>Independent</organization>
</author> </author>
<author fullname="Asad Sajjad Ahmed" initials="A.S." surname="Ahmed" > <author fullname="Asad Sajjad Ahmed" initials="A." surname="Ahmed">
<organization>Simula and Uni Oslo</organization> <organization>Simula and Uni Oslo</organization>
</author> </author>
<date month="April" year="2020"/> <date month="February" year="2021"/>
</front> </front>
<seriesInfo name="bobbriscoe.net Technical Report" value="TR-BB-2019-0 <seriesInfo name="DOI" value="10.48550/arXiv.1911.00710"/>
02"/> <refcontent>Technical Report: TR-BB-2019-002</refcontent>
</reference> </reference>
<reference anchor="Ahmed19" target="https://www.duo.uio.no/handle/10852/ 70966"> <reference anchor="Ahmed19" target="https://www.duo.uio.no/handle/10852/ 70966">
<front> <front>
<title>Extending TCP for Low Round Trip Delay</title> <title>Extending TCP for Low Round Trip Delay</title>
<author fullname="Asad Sajjad Ahmed" initials="A.S." surname="Ahmed" > <author fullname="Asad Sajjad Ahmed" initials="A.S." surname="Ahmed" >
<organization>Simula and Uni Oslo</organization> <organization>Simula and Uni Oslo</organization>
</author> </author>
<date month="August" year="2019"/> <date month="August" year="2019"/>
</front> </front>
<seriesInfo name="Master's Thesis, Uni Oslo" value=""/> <refcontent>Master's Thesis, University of Oslo</refcontent>
<format target="https://www.duo.uio.no/bitstream/handle/10852/70966/ma
in.pdf?sequence=5&amp;isAllowed=y" type="PDF"/>
</reference>
<reference anchor="Paced-Chirping" target="https://riteproject.files.wor
dpress.com/2018/07/misundjoakimmastersthesissubmitted180515.pdf">
<front>
<title>Rapid Acceleration in TCP Prague</title>
<author fullname="Joakim Misund" initials="J." surname="Misund">
<organization>University of Oslo and Simula</organization>
</author>
<date month="May" year="2018"/>
</front>
<seriesInfo name="Master's Thesis" value=""/>
</reference> </reference>
<reference anchor="A2DTCP" target="https://ieeexplore.ieee.org/xpl/artic leDetails.jsp?arnumber=6871352"> <reference anchor="A2DTCP" target="https://ieeexplore.ieee.org/xpl/artic leDetails.jsp?arnumber=6871352">
<front> <front>
<title>Adaptive-Acceleration Data Center TCP</title> <title>Adaptive-Acceleration Data Center TCP</title>
<author fullname="Tao Zhang" initials="T." surname="Zhang"> <author fullname="Tao Zhang" initials="T." surname="Zhang">
<organization/> <organization/>
</author> </author>
<author fullname="Jianxin Wang" initials="J." surname="Wang"> <author fullname="Jianxin Wang" initials="J." surname="Wang">
<organization/> <organization/>
</author> </author>
<author fullname="Jiawei Huang" initials="J." surname="Huang"> <author fullname="Jiawei Huang" initials="J." surname="Huang">
skipping to change at line 3175 skipping to change at line 2047
<organization/> <organization/>
</author> </author>
<author fullname="Jianer Chen" initials="J." surname="Chen"> <author fullname="Jianer Chen" initials="J." surname="Chen">
<organization/> <organization/>
</author> </author>
<author fullname="Yi Pan" initials="Y." surname="Pan"> <author fullname="Yi Pan" initials="Y." surname="Pan">
<organization/> <organization/>
</author> </author>
<date month="June" year="2015"/> <date month="June" year="2015"/>
</front> </front>
<seriesInfo name="IEEE Transactions on Computers" value="64(6):1522-15 <seriesInfo name="DOI" value="10.1109/TC.2014.2345393"/>
33"/> <refcontent>IEEE Transactions on Computers, Volume 64, Issue 6, pp. 15
22-1533</refcontent>
</reference> </reference>
<reference anchor="PragueLinux" target="https://www.netdevconf.org/0x13/ session.html?talk-tcp-prague-l4s"> <reference anchor="PragueLinux" target="https://www.netdevconf.org/0x13/ session.html?talk-tcp-prague-l4s">
<front> <front>
<title>Implementing the `TCP Prague' Requirements for Low Latency <title>Implementing the 'TCP Prague' Requirements for L4S</title>
Low Loss Scalable Throughput (L4S)</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization> <organization>Independent</organization>
</author> </author>
<author fullname="Koen De Schepper" initials="K." surname="De Schepp er"> <author fullname="Koen De Schepper" initials="K." surname="De Schepp er">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
</author> </author>
<author fullname="Olga Albisser" initials="O." surname="Albisser"> <author fullname="Olga Albisser" initials="O." surname="Albisser">
<organization>Simula</organization> <organization>Simula</organization>
</author> </author>
<author fullname="Joakim Misund" initials="J." surname="Misund"> <author fullname="Joakim Misund" initials="J." surname="Misund">
<organization>University of Oslo</organization> <organization>University of Oslo</organization>
</author> </author>
<author fullname="Olivier Tilmans" initials="O." surname="Tilmans"> <author fullname="Olivier Tilmans" initials="O." surname="Tilmans">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
</author> </author>
<author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind" > <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind" >
<organization>ETHZ</organization> <organization>ETHZ</organization>
</author> </author>
<author fullname="Asad Sajjad Ahmed" initials="A.S." surname="Ahmed" > <author fullname="Asad Sajjad Ahmed" initials="A." surname="Ahmed">
<organization>Simula</organization> <organization>Simula</organization>
</author> </author>
<date month="March" year="2019"/> <date month="March" year="2019"/>
</front> </front>
<seriesInfo name="Proc. Linux Netdev 0x13" value=""/> <refcontent>Proceedings of Linux Netdev 0x13</refcontent>
<format target="https://www.files.netdevconf.info/f/4d6939d5f1fb404faf d1/?dl=1" type="PDF"/> <format target="https://www.files.netdevconf.info/f/4d6939d5f1fb404faf d1/?dl=1" type="PDF"/>
</reference> </reference>
<reference anchor="LinuxPacedChirping" target="https://www.netdevconf.or
g/0x13/session.html?talk-chirp"> <reference anchor="LinuxPacedChirping" target="https://legacy.netdevconf
.info/0x13/session.html?talk-chirp">
<front> <front>
<title>Paced Chirping - Rethinking TCP start-up</title> <title>Paced Chirping - Rethinking TCP start-up</title>
<author fullname="Joakim Misund" initials="J." surname="Misund"> <author fullname="Joakim Misund" initials="J." surname="Misund">
<organization>University of Oslo</organization> <organization>University of Oslo</organization>
</author> </author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization> <organization>Independent</organization>
</author> </author>
<date month="March" year="2019"/> <date month="March" year="2019"/>
</front> </front>
<seriesInfo name="Proc. Linux Netdev 0x13" value=""/> <refcontent>Proceedings of Linux Netdev 0x13</refcontent>
<format target="https://www.files.netdevconf.info/f/da8cc04a608a448f89
0e/?dl=1" type="PDF"/>
</reference> </reference>
<reference anchor="TCP-CA" target="https://ee.lbl.gov/papers/congavoid.p df"> <reference anchor="TCP-CA" target="https://ee.lbl.gov/papers/congavoid.p df">
<front> <front>
<title>Congestion Avoidance and Control</title> <title>Congestion Avoidance and Control</title>
<author fullname="Van Jacobson" initials="V." surname="Jacobson"> <author fullname="Van Jacobson" initials="V." surname="Jacobson">
<organization/> <organization/>
</author> </author>
<author fullname="Michael J. Karels" initials="M.J." surname="Karels <author fullname="Michael J. Karels" initials="M. J." surname="Karel
"> s">
<organization/> <organization/>
<address> </author>
<postal> <date month="November" year="1988"/>
<street/> </front>
<city/> <refcontent>Laurence Berkeley Labs Technical Report</refcontent>
<region/> </reference>
<code/>
<country/> <reference anchor="Savage-TCP" target="https://dl.acm.org/doi/abs/10.114
</postal> 5/505696.505704">
<phone/>
<email/>
<uri/>
</address>
</author>
<date month="November" year="1988"/>
</front>
<seriesInfo name="Laurence Berkeley Labs Technical Report" value=""/>
</reference>
<reference anchor="Savage-TCP">
<front> <front>
<title>TCP Congestion Control with a Misbehaving Receiver</title> <title>TCP Congestion Control with a Misbehaving Receiver</title>
<author fullname="Stefan Savage" initials="S." surname="Savage"> <author fullname="Stefan Savage" initials="S." surname="Savage">
<organization>Uni Washington</organization> <organization>University of Washington</organization>
</author> </author>
<author fullname="Neal Cardwell" initials="N." surname="Cardwell"> <author fullname="Neal Cardwell" initials="N." surname="Cardwell">
<organization>Uni Washington</organization> <organization>University of Washington</organization>
</author> </author>
<author fullname="David Wetherall" initials="D." surname="Wetherall" > <author fullname="David Wetherall" initials="D." surname="Wetherall" >
<organization>Uni Washington</organization> <organization>University of Washington</organization>
</author> </author>
<author fullname="Tom Anderson" initials="T." surname="Anderson"> <author fullname="Tom Anderson" initials="T." surname="Anderson">
<organization>Uni Washington</organization> <organization>University of Washington</organization>
</author> </author>
<date month="October" year="1999"/> <date month="October" year="1999"/>
</front> </front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value="29 <seriesInfo name="DOI" value="10.1145/505696.505704"/>
(5):71--78"/> <refcontent>ACM SIGCOMM Computer Communication Review, Volume 29, Issue
5, pp. 71–78</refcontent>
</reference> </reference>
<reference anchor="Heist21" target="https://github.com/heistp/l4s-tests/
"> <reference anchor="Heist21" target="https://github.com/heistp/l4s-tests">
<front> <front>
<title>L4S Tests</title> <title>L4S Tests</title>
<author fullname="Pete Heist" initials="P." surname="Heist"> <author>
<organization/>
</author>
<author fullname="Jonathan Morton" initials="J." surname="Morton">
<organization/> <organization/>
</author> </author>
<date month="May" year="2021"/> <date month="August" year="2021"/>
</front> </front>
<seriesInfo name="GitHub" value="README"/> <refcontent>commit e21cd91</refcontent>
</reference> </reference>
<reference anchor="SCReAM-L4S" target="https://github.com/EricssonResear
ch/scream/blob/master/README.md"> <reference anchor="SCReAM-L4S" target="https://github.com/EricssonResear
ch/scream">
<front> <front>
<title>SCReAM</title> <title>SCReAM</title>
<author fullname="Ingemar Johansson" initials="I" surname="Johansson <author/>
"> <date month="November" year="2022"/>
<organization/>
</author>
<date/>
</front> </front>
<seriesInfo name="GitHub repository;" value=""/> <refcontent>commit 140e292</refcontent>
<format target="https://github.com/google/bbr/blob/v2alpha/README.md"
type="Source code"/>
</reference> </reference>
<reference anchor="DualPI2Linux" target="https://www.netdevconf.org/0x13
/session.html?talk-DUALPI2-AQM"> <reference anchor="DualPI2Linux" target="https://www.netdevconf.org/0x13/s
<front> ession.html?talk-DUALPI2-AQM">
<title>DUALPI2 - Low Latency, Low Loss and Scalable (L4S) <front>
<title>DUALPI2 - Low Latency, Low Loss and Scalable (L4S)
AQM</title> AQM</title>
<author fullname="Olga Albisser" initials="O." surname="Albisser"> <author fullname="Olga Albisser" initials="O." surname="Albisser">
<organization>Simula Research Lab</organization> <organization>Simula Research Lab</organization>
</author> </author>
<author fullname="Koen De Schepper" initials="K." surname="De Schepp <author fullname="Koen De Schepper" initials="K." surname="De Schepper
er"> ">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
</author> </author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe"> <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>Independent</organization> <organization>Independent</organization>
</author> </author>
<author fullname="Olivier Tilmans" initials="O." surname="Tilmans"> <author fullname="Olivier Tilmans" initials="O." surname="Tilmans">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
</author> </author>
<author fullname="Henrik Steen" initials="H." surname="Steen"> <author fullname="Henrik Steen" initials="H." surname="Steen">
<organization>Simula Research Lab</organization> <organization>Simula Research Lab</organization>
</author> </author>
<date month="March" year="2019"/> <date month="March" year="2019"/>
</front> </front>
<seriesInfo name="Proc. Linux Netdev 0x13" value=""/> <refcontent>Proceedings of Linux Netdev 0x13</refcontent>
<format target="https://www.files.netdevconf.org/f/febbe8c6a05b4ceab64 <format target="https://www.files.netdevconf.org/f/febbe8c6a05b4ceab641/
1/?dl=1" type="PDF"/> ?dl=1" type="PDF"/>
</reference> </reference>
<reference anchor="COBALT" target="https://doi.org/10.1109/LANMAN.2019.8
847054"> <reference anchor="COBALT" target="https://ieeexplore.ieee.org/abstract/doc
<front> ument/8847054">
<title>Design and Evaluation of COBALT Queue Discipline</title> <front>
<author initials="J." surname="Palmei"/> <title>Design and Evaluation of COBALT Queue Discipline</title>
<author initials="S." surname="Gupta"/> <author fullname="Jendaipou Palmei" initials="J." surname="Palmei">
<author initials="P." surname="Imputato"/> <organization/>
<author initials="J." surname="Morton"/> </author>
<author initials="M." surname="Tahiliani"/> <author fullname="Shefali Gupta" initials="S." surname="Gupta">
<author initials="S." surname="Avallone"/> <organization/>
<author initials="D." surname="Taht"/> </author>
<date year="2019"/> <author fullname="Pasquale Imputato" initials="P." surname="Imputato">
</front> <organization/>
<seriesInfo name="In Proc. IEEE Int'l Symp. on Local and Metropolitan </author>
Area Networks" value="2019, pp1--6"/> <author fullname="Jonathan Morton" initials="J." surname="Morton">
</reference> <organization/>
<reference anchor="Dukkipati06" target="https://dl.acm.org/doi/10.1145/1 </author>
111322.1111336"> <author fullname="Mohit P. Tahiliani" initials="M. P." surname="Tahili
<front> ani">
<title>Why Flow-Completion Time is the Right Metric for Congestion <organization/>
</author>
<author fullname="Stefan Avallone" initials="S." surname="Avallone">
<organization/>
</author>
<author fullname="Dave Täht" initials="D." surname="Täht">
<organization/>
</author>
<date month="July" year="2019"/>
</front>
<seriesInfo name="DOI" value="10.1109/LANMAN.2019.8847054"/>
<refcontent>IEEE International Symposium on Local and Metropolitan Area N
etworks (LANMAN)</refcontent>
</reference>
<reference anchor="Dukkipati06" target="https://dl.acm.org/doi/10.1145/111
1322.1111336">
<front>
<title>Why Flow-Completion Time is the Right Metric for Congestion
Control</title> Control</title>
<author fullname="Nandita Dukkipati" initials="N." surname="Dukkipat <author fullname="Nandita Dukkipati" initials="N." surname="Dukkipati"
i"> >
<organization>Stanford Uni</organization> <organization>Stanford University</organization>
</author> </author>
<author fullname="Nick McKeown" initials="N." surname="McKeown"> <author fullname="Nick McKeown" initials="N." surname="McKeown">
<organization>Stanford Uni</organization> <organization>Stanford University</organization>
</author> </author>
<date month="January" year="2006"/> <date month="January" year="2006"/>
</front> </front>
<seriesInfo name="ACM CCR" value="36(1):59--62"/> <seriesInfo name="DOI" value="10.1145/1111322.1111336"/>
<format target="http://yuba.stanford.edu/rcp/flowCompTime-dukkipati.pd <refcontent>ACM SIGCOMM Computer Communication Review, Volume 36, Issue
f" type="PDF"/> 1, pp. 59-62</refcontent>
</reference> </reference>
<reference anchor="Bufferbloat" target="https://bufferbloat.net/"> <reference anchor="Bufferbloat" target="https://bufferbloat.net/">
<front> <front>
<title>Bufferbloat</title> <title>Bufferbloat</title>
<author fullname=""> <author>
<organization/> <organization>The Bufferbloat community</organization>
</author> </author>
<date/> <date/>
</front> </front>
<annotation>(last accessed 27 Aug 2022)</annotation>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="l4sps_tcp-prague-reqs" numbered="true" toc="default"> <section anchor="l4sps_tcp-prague-reqs" numbered="true" toc="default">
<name>Rationale for the 'Prague L4S Requirements'</name> <name>Rationale for the 'Prague L4S Requirements'</name>
<t>This appendix is informative, not normative. It gives a list of <t>This appendix is informative, not normative. It gives a list of
modifications to current scalable congestion controls so that they can modifications to current Scalable congestion controls so that they can
be deployed over the public Internet and coexist safely with existing be deployed over the public Internet and coexist safely with existing
traffic. The list complements the normative requirements in <xref target=" l4sid_transport_req" format="default"/> that a sender has to comply with before traffic. The list complements the normative requirements in <xref target=" l4sid_transport_req" format="default"/> that a sender has to comply with before
it can set the L4S identifier in packets it sends into the Internet. As it can set the L4S identifier in packets it sends into the Internet. As
well as rationale for safety improvements (the requirements in <xref targe t="l4sid_transport_req" format="default"/>) this appendix also includes preferab le well as rationale for safety improvements (the requirements in <xref targe t="l4sid_transport_req" format="default"/>), this appendix also includes prefera ble
performance improvements (optimizations).</t> performance improvements (optimizations).</t>
<t>The requirements and recommendations in <xref target="l4sid_transport_r <t>The requirements and recommendations in <xref target="l4sid_transport_r
eq" format="default"/>) have become known as the Prague L4S eq" format="default"/> have become known as the 'Prague L4S
Requirements, because they were originally identified at an ad hoc Requirements', because they were originally identified at an ad hoc
meeting during IETF-94 in Prague <xref target="TCPPrague" format="default" meeting during IETF 94 in Prague <xref target="TCPPrague" format="default"
/>. They />. They
were originally called the 'TCP Prague Requirements', but they are not were originally called the 'TCP Prague Requirements', but they are not
solely applicable to TCP, so the name and wording has been generalized solely applicable to TCP, so the name and wording has been generalized
for all transport protocols, and the name 'TCP Prague' is now used for a for all transport protocols, and the name 'TCP Prague' is now used for a
specific implementation of the requirements.</t> specific implementation of the requirements.</t>
<t>At the time of writing, DCTCP <xref target="RFC8257" format="default"/> <t>At the time of writing, DCTCP <xref target="RFC8257" format="default"/>
is the is the
most widely used scalable transport protocol. In its current form, DCTCP most widely used Scalable transport protocol. In its current form, DCTCP
is specified to be deployable only in controlled environments. Deploying is specified to be deployable only in controlled environments. Deploying
it in the public Internet would lead to a number of issues, both from it in the public Internet would lead to a number of issues, from both
the safety and the performance perspective. The modifications and the safety and the performance perspective. The modifications and
additional mechanisms listed in this section will be necessary for its additional mechanisms listed in this section will be necessary for its
deployment over the global Internet. Where an example is needed, DCTCP deployment over the global Internet. Where an example is needed, DCTCP
is used as a base, but the requirements in <xref target="l4sid_transport_r eq" format="default"/> apply equally to other scalable is used as a base, but the requirements in <xref target="l4sid_transport_r eq" format="default"/> apply equally to other Scalable
congestion controls, covering adaptive real-time media, etc., not just congestion controls, covering adaptive real-time media, etc., not just
capacity-seeking behaviours.</t> capacity-seeking behaviours.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Rationale for the Requirements for Scalable Transport Protocols</n ame> <name>Rationale for the Requirements for Scalable Transport Protocols</n ame>
<t/>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use of L4S Packet Identifier</name> <name>Use of L4S Packet Identifier</name>
<t>Description: A scalable congestion control needs to distinguish <t>Description: A Scalable congestion control needs to distinguish
the packets it sends from those sent by Classic congestion controls the packets it sends from those sent by Classic congestion controls
(see the precise normative requirement wording in <xref target="l4sid_ codepoint" format="default"/>).</t> (see the precise normative requirement wording in <xref target="l4sid_ codepoint" format="default"/>).</t>
<t>Motivation: It needs to be possible for a network node to <t>Motivation: It needs to be possible for a network node to
classify L4S packets without flow state into a queue that applies an classify L4S packets without flow state into a queue that applies an
L4S ECN marking behaviour and isolates L4S packets from the queuing L4S ECN-marking behaviour and isolates L4S packets from the queuing
delay of Classic packets.</t> delay of Classic packets.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Accurate ECN Feedback</name> <name>Accurate ECN Feedback</name>
<t>Description: The transport protocol for a scalable congestion <t>Description: The transport protocol for a Scalable congestion
control needs to provide timely, accurate feedback about the extent control needs to provide timely, accurate feedback about the extent
of ECN marking experienced by all packets (see the precise normative of ECN marking experienced by all packets (see the precise normative
requirement wording in <xref target="l4sid_feedback" format="default"/ >).</t> requirement wording in <xref target="l4sid_feedback" format="default"/ >).</t>
<t>Motivation: Classic congestion controls only need feedback about <t>Motivation: Classic congestion controls only need feedback about
the existence of a congestion episode within a round trip, not the existence of a congestion episode within a round trip, not
precisely how many packets were marked with ECN or dropped. precisely how many packets were ECN-marked or dropped.
Therefore, in 2001, when ECN feedback was added to TCP <xref target="R Therefore, in 2001, when ECN feedback was added to TCP <xref target="R
FC3168" format="default"/>, it could not inform the sender of more than one FC3168" format="default"/>, it could not inform the sender of more than one
ECN mark per RTT. Since then, requirements for more accurate ECN ECN mark per RTT.
feedback in TCP have been defined in <xref target="RFC7560" format="de Since then, requirements for more accurate ECN
fault"/> and feedback in TCP have been defined in <xref target="RFC7560" format="de
fault"/>, and
<xref target="I-D.ietf-tcpm-accurate-ecn" format="default"/> specifies a change to <xref target="I-D.ietf-tcpm-accurate-ecn" format="default"/> specifies a change to
the TCP protocol to satisfy these requirements. Most other transport the TCP protocol to satisfy these requirements. Most other transport
protocols already satisfy this requirement (see <xref target="l4sid_fe edback" format="default"/>).</t> protocols already satisfy this requirement (see <xref target="l4sid_fe edback" format="default"/>).</t>
</section> </section>
<section anchor="l4sid_sec_replaceable" numbered="true" toc="default"> <section anchor="l4sid_sec_replaceable" numbered="true" toc="default">
<name>Capable of Replacement by Classic Congestion Control</name> <name>Capable of Replacement by Classic Congestion Control</name>
<t>Description: It needs to be possible to replace the <t>Description: It needs to be possible to replace the
implementation of a scalable congestion control with a Classic implementation of a Scalable congestion control with a Classic
control (see the precise normative requirement wording in <xref target control (see the precise normative requirement wording in <xref target
="l4sid_congestion_response" format="default"/>).</t> ="l4sid_Prague_req-replaceable" format="default"/>).</t>
<t>Motivation: L4S is an experimental protocol, therefore it seems <t>Motivation: L4S is an experimental protocol; therefore, it seems
prudent to be able to disable it at source in case of insurmountable prudent to be able to disable it at source in case of insurmountable
problems, perhaps due to some unexpected interaction on a particular problems, perhaps due to some unexpected interaction on a particular
sender; over a particular path or network; with a particular sender; over a particular path or network; or with a particular
receiver or even ultimately an insurmountable problem with the receiver, or even ultimately an insurmountable problem with the
experiment as a whole.</t> experiment as a whole.</t>
</section> </section>
<section anchor="l4sid_sec_fallback_on_loss" numbered="true" toc="defaul t"> <section anchor="l4sid_sec_fallback_on_loss" numbered="true" toc="defaul t">
<name>Fall back to Classic Congestion Control on Packet Loss</name> <name>Fall Back to Classic Congestion Control on Packet Loss</name>
<t>Description: As well as responding to ECN markings in a scalable <t>Description: As well as responding to ECN markings in a scalable
way, a scalable congestion control needs to react to packet loss in way, a Scalable congestion control needs to react to packet loss in
a way that will coexist safely with a Reno congestion a way that will coexist safely with a Reno congestion
control <xref target="RFC5681" format="default"/> (see the precise nor control <xref target="RFC5681" format="default"/> (see the precise nor
mative mative
requirement wording in <xref target="l4sid_congestion_response" format requirement wording in <xref target="l4sid_Prague_req-loss-response" f
="default"/>).</t> ormat="default"/>).</t>
<t>Motivation: Part of the safety conditions for deploying a <t>Motivation: Part of the safety conditions for deploying a
scalable congestion control on the public Internet is to make sure Scalable congestion control on the public Internet is to make sure
that it behaves properly when it builds a queue at a network that it behaves properly when it builds a queue at a network
bottleneck that has not been upgraded to support L4S. Packet loss bottleneck that has not been upgraded to support L4S. Packet loss
can have many causes, but it usually has to be conservatively can have many causes, but it usually has to be conservatively
assumed that it is a sign of congestion. Therefore, on detecting assumed that it is a sign of congestion. Therefore, on detecting
packet loss, a scalable congestion control will need to fall back to packet loss, a Scalable congestion control will need to fall back to
Classic congestion control behaviour. If it does not comply, it Classic congestion control behaviour. If it does not comply, it
could starve Classic traffic.</t> could starve Classic traffic.</t>
<t>A scalable congestion control can be used for different types of <t>A Scalable congestion control can be used for different types of
transport, e.g. for real-time media or for reliable transport transport, e.g., for real-time media or for reliable transport
like TCP. Therefore, the particular Classic congestion control like TCP. Therefore, the particular Classic congestion control
behaviour to fall back on will need to be dependent on the specific behaviour to fall back on will need to be dependent on the specific
congestion control implementation. In the particular case of DCTCP, congestion control implementation.
the DCTCP specification <xref target="RFC8257" format="default"/> stat In the particular case of DCTCP,
es that the DCTCP specification <xref target="RFC8257" format="default"/> stat
"It is RECOMMENDED that an implementation deal with loss episodes in es that
the same way as conventional TCP." For safe deployment, <xref target=" "A DCTCP sender <bcp14>MUST</bcp14> react to loss episodes in
l4sid_congestion_response" format="default"/> requires any specification of a the same way as conventional TCP,...". To ensure any Scalable congest
scalable congestion control for the public Internet to define the ion control is safe to deploy over the public Internet, Item
above requirement as a "MUST".</t> <xref target="l4sid_Prague_req-loss-response" format="counter"/> of <x
<t>Even though a bottleneck is L4S capable, it might still become ref target="l4sid_congestion_response" format="default"/> in the present spec
does not require precisely the same response as Reno TCP, but it does
require a response that will coexist safely with Classic congestion co
ntrols
like Reno.</t>
<t>Even though a bottleneck is L4S capable, it might still become
overloaded and have to drop packets. In this case, the sender may overloaded and have to drop packets. In this case, the sender may
receive a high proportion of packets marked with the CE bit set and receive a high proportion of packets marked with the CE codepoint and
also experience loss. Current DCTCP implementations each react also experience loss. Current DCTCP implementations each react
differently to this situation. At least one implementation reacts differently to this situation. One approach is to react only to the dr
only to the drop signal (e.g. by halving the CWND) and at least op
another DCTCP implementation reacts to both signals (e.g. by signal (e.g., by halving the cwnd); another approach is to react to bo
halving the CWND due to the drop and also further reducing the CWND th
based on the proportion of marked packet). A third approach for the signals, which reduces cwnd by more than half. A compromise
public Internet has been proposed that adjusts the loss response to between these two has been proposed where the loss response is adjuste
result in a halving when combined with the ECN response. We believe d to
result in a halving when combined with any ECN response earlier in the
same
round. We believe
that further experimentation is needed to understand what is the that further experimentation is needed to understand what is the
best behaviour for the public Internet, which may or not be one of best behaviour for the public Internet, which may or may not be one of
these existing approaches.</t> these existing approaches.</t>
</section> </section>
<section anchor="l4sid_sec_fallback_on_classic_CE" numbered="true" toc=" default"> <section anchor="l4sid_sec_fallback_on_classic_CE" numbered="true" toc=" default">
<name>Coexistence with Classic Congestion Control at Classic ECN bottl enecks</name> <name>Coexistence with Classic Congestion Control at Classic ECN Bottl enecks</name>
<t>Description: Monitoring has to be in place so that a non-L4S but <t>Description: Monitoring has to be in place so that a non-L4S but
ECN-capable AQM can be detected at path bottlenecks. This is in case ECN-capable AQM can be detected at path bottlenecks. This is in case
such an AQM has been implemented in a shared queue, in which case such an AQM has been implemented in a shared queue, in which case
any long-running scalable flow would predominate over any any long-running Scalable flow would predominate over any
simultaneous long-running Classic flow sharing the queue. The simultaneous long-running Classic flow sharing the queue. The
precise requirement wording in <xref target="l4sid_congestion_response precise requirement wording in <xref target="l4sid_Prague_req-classic-
" format="default"/> is written so that such a ecn-response" format="default"/> is written so that such a
problem could either be resolved in real-time, or via administrative problem could be resolved either in real time or via administrative
intervention.</t> intervention.</t>
<t>Motivation: Similarly to the discussion in <xref target="l4sid_sec_ fallback_on_loss" format="default"/>, this requirement in <xref target="l4sid_co ngestion_response" format="default"/> is a safety condition to ensure <t>Motivation: Similarly to the discussion in <xref target="l4sid_sec_ fallback_on_loss" format="default"/>, this requirement in <xref target="l4sid_co ngestion_response" format="default"/> is a safety condition to ensure
an L4S congestion control coexists well with Classic flows when it an L4S congestion control coexists well with Classic flows when it
builds a queue at a shared network bottleneck that has not been builds a queue at a shared network bottleneck that has not been
upgraded to support L4S. Nonetheless, if necessary, it is considered upgraded to support L4S. Nonetheless, if necessary, it is considered
reasonable to resolve such problems over management timescales reasonable to resolve such problems over management timescales
(possibly involving human intervention) because:</t> (possibly involving human intervention) because:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>although a Classic flow can considerably reduce its <li>although a Classic flow can considerably reduce its
throughput in the face of a competing scalable flow, it still throughput in the face of a competing Scalable flow, it still
makes progress and does not starve;</li> makes progress and does not starve;</li>
<li>implementations of a Classic ECN AQM in a queue that is <li>implementations of a Classic ECN AQM in a queue that is
intended to be shared are believed to be rare;</li> intended to be shared are believed to be rare; and</li>
<li>detection of such AQMs is not always clear-cut; so focused <li>detection of such AQMs is not always clear-cut; so focused
out-of-band testing (or even contacting the relevant network out-of-band testing (or even contacting the relevant network
operator) would improve certainty.</li> operator) would improve certainty.</li>
</ul> </ul>
<t>Therefore, the relevant normative requirement (<xref target="l4sid_ <t>The relevant normative requirement (<xref target="l4sid_congestion_
congestion_response" format="default"/>) is divided into three stages: response" format="default"/>) is therefore divided into three stages:
monitoring, detection and action:</t> monitoring, detection, and action:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Monitoring:</dt> <dt>Monitoring:</dt>
<dd>Monitoring involves collection of the <dd>Monitoring involves collection of the
measurement data to be analysed. Monitoring is expressed as a measurement data to be analysed. Monitoring is expressed as a
'MUST' for uncontrolled environments, although the placement of "<bcp14>MUST</bcp14>" for uncontrolled environments, although the placement of
the monitoring function is left open. Whether monitoring has to the monitoring function is left open. Whether monitoring has to
be applied in real-time is expressed as a 'SHOULD'. This allows be applied in real time is expressed as a "<bcp14>SHOULD</bcp14>".
This allows
for the possibility that the operator of an L4S sender for the possibility that the operator of an L4S sender
(e.g. a CDN) might prefer to test out-of-band for signs of (e.g., a Content Distribution Network (CDN)) might prefer to test out-of-band for signs of
Classic ECN AQMs, perhaps to avoid continually consuming Classic ECN AQMs, perhaps to avoid continually consuming
resources to monitor live traffic.</dd> resources to monitor live traffic.</dd>
<dt>Detection:</dt> <dt>Detection:</dt>
<dd>Detection involves analysis of the <dd>Detection involves analysis of the
monitored data to detect the likelihood of a Classic ECN AQM. monitored data to detect the likelihood of a Classic ECN AQM.
Detection can either directly detect actual coexistence problems Detection can either directly detect actual coexistence problems
between flows, or it can aim to identify AQM technologies that between flows or aim to identify AQM technologies that
are likely to present coexistence problems, based on knowledge are likely to present coexistence problems, based on knowledge
of AQMs deployed at the time. The requirements recommend that of AQMs deployed at the time. The requirements recommend that
detection occurs live in real-time. However, detection is detection occurs live in real time. However, detection is
allowed to be deferred (e.g. it might involve further allowed to be deferred (e.g., it might involve further
testing targeted at candidate AQMs);</dd> testing targeted at candidate AQMs).</dd>
<dt>Action:</dt> <dt>Action:</dt>
<dd> <dd>
<t>This involves the act of switching the <t>This involves the act of switching the
sender to a Classic congestion control. This might occur in sender to a Classic congestion control. This might occur in
real-time within the congestion control for the subsequent real time within the congestion control for the subsequent
duration of a flow, or it might involve administrative action to duration of a flow, or it might involve administrative action to
switch to Classic congestion control for a specific interface or switch to Classic congestion control for a specific interface or
for a certain set of destination addresses.</t> for a certain set of destination addresses.</t>
<t>Instead of the sender taking action itself, the <t>Instead of the sender taking action itself, the
operator of the sender (e.g. a CDN) might prefer to ask the operator of the sender (e.g., a CDN) might prefer to ask the
network operator to modify the Classic AQM's treatment of L4S network operator to modify the Classic AQM's treatment of L4S
packets; or to ensure L4S packets bypass the AQM; or to upgrade packets; ensure L4S packets bypass the AQM; or upgrade
the AQM to support L4S (see the L4S operational the AQM to support L4S (see the L4S operational
guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/>). guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/>).
Once L4S If L4S
flows no longer shared the Classic ECN AQM they would obviously flows then no longer shared the Classic ECN AQM, they would obviou
sly
no longer detect it, and the requirement to act on it would no no longer detect it, and the requirement to act on it would no
longer apply.</t> longer apply.</t>
</dd> </dd>
</dl> </dl>
<t>The whole set of normative requirements concerning Classic ECN <t>The whole set of normative requirements concerning Classic ECN
AQMs in <xref target="l4sid_congestion_response" format="default"/> is worded so that AQMs in <xref target="l4sid_congestion_response" format="default"/> is worded so that
it does not apply in controlled environments, such as private it does not apply in controlled environments, such as private
networks or data centre networks. CDN servers placed within an networks or data-centre networks. CDN servers placed within an
access ISP's network can be considered as a single controlled access ISP's network can be considered as a single controlled
environment, but any onward networks served by the access network, environment, but any onward networks served by the access network,
including all the attached customer networks, would be unlikely to including all the attached customer networks, would be unlikely to
fall under the same degree of coordinated control. Monitoring is fall under the same degree of coordinated control. Monitoring is
expressed as a 'MUST' for these uncontrolled segments of paths expressed as a "<bcp14>MUST</bcp14>" for these uncontrolled segments o
(e.g. beyond the access ISP in a home network), because there f paths
(e.g., beyond the access ISP in a home network), because there
is a possibility that there might be a shared queue Classic ECN AQM is a possibility that there might be a shared queue Classic ECN AQM
in that segment. Nonetheless, the intent of the wording is to only in that segment. Nonetheless, the intent of the wording is to only
require occasional monitoring of these uncontrolled regions, and not require occasional monitoring of these uncontrolled regions and not
to burden CDN operators if monitoring never uncovers any potential to burden CDN operators if monitoring never uncovers any potential
problems.</t> problems.</t>
<t>More detailed discussion of all the above options and <t>More detailed discussion of all the above options and
alternatives can be found in the L4S operational guidance <xref target alternatives can be found in the L4S operational guidance <xref target
="I-D.ietf-tsvwg-l4sops" format="default"/>.</t> ="I-D.ietf-tsvwg-l4sops" format="default"/>.</t>
<t>Having said all the above, the approach recommended in <xref target <t>Having said all the above, the approach recommended in <xref target
="l4sid_congestion_response" format="default"/> is to monitor, detect and act ="l4sid_congestion_response" format="default"/> is to monitor, detect, and act
in real-time on live traffic. A passive monitoring algorithm to in real time on live traffic. A passive monitoring algorithm to
detect a Classic ECN AQM at the bottleneck and fall back to Classic detect a Classic ECN AQM at the bottleneck and fall back to Classic
congestion control is described in an extensive technical congestion control is described in an extensive technical
report <xref target="ecn-fallback" format="default"/>, which also prov report <xref target="ecn-fallback" format="default"/>, which also prov
ides a ides a
link to Linux source code, and a large online visualization of its link to Linux source code and a large online visualization of its
evaluation results. Very briefly, the algorithm primarily monitors evaluation results. Very briefly, the algorithm primarily monitors
RTT variation using the same algorithm that maintains the mean RTT variation using the same algorithm that maintains the mean
deviation of TCP's smoothed RTT, but it smooths over a duration of deviation of TCP's smoothed RTT, but it smooths over a duration of
the order of a Classic sawtooth. The outcome is also conditioned on the order of a Classic sawtooth.
The outcome is also conditioned on
other metrics such as the presence of CE marking and congestion other metrics such as the presence of CE marking and congestion
avoidance phase having stabilized. The report also identifies avoidance phase having stabilized. The report also identifies
further work to improve the approach, for instance improvements with further work to improve the approach, for instance, improvements with
low capacity links and combining the measurements with a cache of low-capacity links and combining the measurements with a cache of
what had been learned about a path in previous connections. The what had been learned about a path in previous connections. The
report also suggests alternative approaches.</t> report also suggests alternative approaches.</t>
<t>Although using passive measurements within live traffic (as <t>Although using passive measurements within live traffic (as
above) can detect a Classic ECN AQM, it is much harder (perhaps above) can detect a Classic ECN AQM, it is much harder (perhaps
impossible) to determine whether or not the AQM is in a shared impossible) to determine whether or not the AQM is in a shared
queue. Nonetheless, this is much easier using active test traffic queue. Nonetheless, this is much easier using active test traffic
out-of-band, because two flows can be used. Section 4 of the same out-of-band because two flows can be used. Section 4 of the same
report <xref target="ecn-fallback" format="default"/> describes a simp report <xref target="ecn-fallback" format="default"/> describes a simp
le le
technique to detect a Classic ECN AQM and determine whether it is in technique to detect a Classic ECN AQM and determine whether it is in
a shared queue, summarized here.</t> a shared queue, which is summarized here.</t>
<t>An L4S-enabled test server could be set up so that, when a test <t>An L4S-enabled test server could be set up so that, when a test
client accesses it, it serves a script that gets the client to open client accesses it, it serves a script that gets the client to open
two parallel long-running flows. It could serve one with a Classic two parallel long-running flows. It could serve one with a Classic
congestion control (C, that sets ECT(0)) and one with a scalable CC congestion control (C, that sets ECT(0)) and one with a Scalable CC
(L, that sets ECT(1)). If neither flow induces any ECN marks, it can (L, that sets ECT(1)). If neither flow induces any ECN marks, it can
be presumed the path does not contain a Classic ECN AQM. If either be presumed that the path does not contain a Classic ECN AQM. If eithe r
flow induces some ECN marks, the server could measure the relative flow induces some ECN marks, the server could measure the relative
flow rates and round trip times of the two flows. <xref target="l4sid_ flow rates and round-trip times of the two flows.
tab_active_AQN_test" format="default"/> shows the AQM that can be <xref target="l4sid_tab_active_AQN_test" format="default"/> shows the
inferred for various cases (presuming the AQM behaviours known at AQM that can be
inferred for various cases (presuming no more types of AQM behaviour t
han those known at
the time of writing).</t> the time of writing).</t>
<table anchor="l4sid_tab_active_AQN_test" align="center"> <table anchor="l4sid_tab_active_AQN_test" align="center">
<name>Out-of-band testing with two parallel flows. L:=L4S, C:=Classi c.</name> <name>Out-of-Band Testing with Two Parallel Flows</name>
<thead> <thead>
<tr> <tr>
<th align="left">Rate</th> <th align="left">Rate</th>
<th align="left">RTT</th> <th align="left">RTT</th>
<th align="left">Inferred AQM</th> <th align="left">Inferred AQM</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">L &gt; C</td> <td align="left">L &gt; C</td>
skipping to change at line 3609 skipping to change at line 2496
<td align="left">Classic ECN AQM (FQ)</td> <td align="left">Classic ECN AQM (FQ)</td>
</tr> </tr>
<tr> <tr>
<td align="left">L = C</td> <td align="left">L = C</td>
<td align="left">L &lt; C</td> <td align="left">L &lt; C</td>
<td align="left">FQ-L4S AQM</td> <td align="left">FQ-L4S AQM</td>
</tr> </tr>
<tr> <tr>
<td align="left">L ~= C</td> <td align="left">L ~= C</td>
<td align="left">L &lt; C</td> <td align="left">L &lt; C</td>
<td align="left">Coupled DualQ AQM</td> <td align="left">DualQ Coupled AQM</td>
</tr> </tr>
</tbody> </tbody>
<tfoot>
<tr>
<th colspan="3" align="center">L = L4S; C = Classic</th>
</tr>
</tfoot>
</table> </table>
<t>Finally, we motivate the recommendation in <xref target="l4sid_cong
estion_response" format="default"/> that a scalable congestion <t>Finally, we motivate the recommendation in <xref target="l4sid_cong
estion_response" format="default"/> that a Scalable congestion
control is not expected to change to setting ECT(0) while it adapts control is not expected to change to setting ECT(0) while it adapts
its behaviour to coexist with Classic flows. This is because the its behaviour to coexist with Classic flows. This is because the
sender needs to continue to check whether it made the right decision sender needs to continue to check whether it made the right decision
- and switch back if it was wrong, or if a different link becomes and switch back if it was wrong, or if a different link becomes
the bottleneck:</t> the bottleneck:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If, as recommended, the sender changes only its behaviour but <li>If, as recommended, the sender changes only its behaviour but
not its codepoint to Classic, its codepoint will still be not its codepoint to Classic, its codepoint will still be
compatible with either an L4S or a Classic AQM. If the compatible with either an L4S or a Classic AQM. If the
bottleneck does actually support both, it will still classify bottleneck does actually support both, it will still classify
ECT(1) into the same L4S queue, where the sender can measure ECT(1) into the same L4S queue, where the sender can measure
that switching to Classic behaviour was wrong, so that it can that switching to Classic behaviour was wrong so that it can
switch back.</li> switch back.</li>
<li>In contrast, if the sender changes both its behaviour and its <li>In contrast, if the sender changes both its behaviour and its
codepoint to Classic, even if the bottleneck supports both, it codepoint to Classic, even if the bottleneck supports both, it
will classify ECT(0) into the Classic queue, reinforcing the will classify ECT(0) into the Classic queue, reinforcing the
sender's incorrect decision so that it never switches back.</li> sender's incorrect decision so that it never switches back.</li>
<li>Also, not changing codepoint avoids the risk of being flipped
<li>Also, not changing its codepoint avoids the risk of being flippe
d
to a different path by a load balancer or multipath routing that to a different path by a load balancer or multipath routing that
hashes on the whole of the ex-ToS byte (unfortunately still a hashes on the whole of the former Type-of-Service (ToS) byte (whic h is unfortunately still a
common pathology).</li> common pathology).</li>
</ul> </ul>
<t>Note that if a flow is configured to <em>only</em> <aside><t>Note that if a flow is configured to <em>only</em>
use a Classic congestion control, it is then entirely appropriate use a Classic congestion control, it is then entirely appropriate
not to use ECT(1).</t> not to use ECT(1).</t></aside>
</section> </section>
<section anchor="l4sid_sec_RTT_dependence" numbered="true" toc="default" > <section anchor="l4sid_sec_RTT_dependence" numbered="true" toc="default" >
<name>Reduce RTT dependence</name> <name>Reduce RTT Dependence</name>
<t>Description: A scalable congestion control needs to reduce RTT <t>Description: A Scalable congestion control needs to reduce RTT
bias as much as possible at least over the low to typical range of bias as much as possible at least over the low-to-typical range of
RTTs that will interact in the intended deployment scenario (see the RTTs that will interact in the intended deployment scenario (see the
precise normative requirement wording in <xref target="l4sid_congestio n_response" format="default"/>).</t> precise normative requirement wording in <xref target="l4sid_Prague_re q-rtt-independence" format="default"/>).</t>
<t>Motivation: The throughput of Classic congestion controls is <t>Motivation: The throughput of Classic congestion controls is
known to be inversely proportional to RTT, so one would expect flows known to be inversely proportional to RTT, so one would expect flows
over very low RTT paths to nearly starve flows over larger RTTs. over very low RTT paths to nearly starve flows over larger RTTs.
However, Classic congestion controls have never allowed a very low However, Classic congestion controls have never allowed a very low
RTT path to exist because they induce a large queue. For instance, RTT path to exist because they induce a large queue. For instance,
consider two paths with base RTT 1 ms and 100 ms. If a consider two paths with base RTT 1 ms and 100 ms. If a
Classic congestion control induces a 100 ms queue, it turns Classic congestion control induces a 100 ms queue, it turns
these RTTs into 101 ms and 200 ms leading to a throughput these RTTs into 101 ms and 200 ms, leading to a throughput
ratio of about 2:1. Whereas if a scalable congestion control induces ratio of about 2:1. Whereas if a Scalable congestion control induces
only a 1 ms queue, the ratio is 2:101, leading to a throughput only a 1 ms queue, the ratio is 2:101, leading to a throughput
ratio of about 50:1.</t> ratio of about 50:1.</t>
<t>Therefore, with very small queues, long RTT flows will <t>Therefore, with very small queues, long RTT flows will
essentially starve, unless scalable congestion controls comply with essentially starve, unless Scalable congestion controls comply with
this requirement in <xref target="l4sid_congestion_response" format="d the requirement in <xref target="l4sid_congestion_response" format="de
efault"/>.</t> fault"/>.</t>
<t>Over higher than typical RTTs, L4S flows can use the same RTT <t>Over higher than typical RTTs, L4S flows can use the same RTT
bias as in current Classic congestion controls and still work bias as in current Classic congestion controls and still work
satisfactorily. So, there is no additional requirement in <xref target satisfactorily. So there is no additional requirement in <xref target=
="l4sid_congestion_response" format="default"/> for high RTT L4S flows to "l4sid_congestion_response" format="default"/> for high RTT L4S flows to
remove RTT bias - they can but they don't have to.</t> remove RTT bias -- they can, but they don't have to.</t>
<t>One way for a Scalable congestion control to satisfy these <t>One way for a Scalable congestion control to satisfy these
requirements is to make its additive increase behave as if it were a requirements is to make its additive increase behave as if it were a
standard Reno flow but over a larger RTT by using a virtual RTT standard Reno flow but over a larger RTT by using a virtual RTT
(rtt_virt) that is a function of the actual RTT (rtt). Example (rtt_virt) that is a function of the actual RTT (rtt). Example
functions might be:</t> functions might be:</t>
<ul empty="true" spacing="normal">
<ul spacing="normal" empty="true">
<li> <li>
<tt>rtt_virt = max(rtt, 25ms)</tt></li> <tt>rtt_virt = max(rtt, 25 ms)</tt></li>
<li> <li>
<tt>rtt_virt = rtt + 10ms</tt></li> <tt>rtt_virt = rtt + 10 ms</tt></li>
</ul> </ul>
<t>These example functions are chosen so that, as the actual <t>These example functions are chosen so that, as the actual
RTT reduces from high to low, the virtual RTT reduces less (see RTT reduces from high to low, the virtual RTT reduces less (see
<xref target="I-D.briscoe-iccrg-prague-congestion-control" format="def ault"/> for <xref target="I-D.briscoe-iccrg-prague-congestion-control" format="def ault"/> for
details).</t> details).</t>
<t>However, short RTT flows can more rapidly respond to changes in <t>However, short RTT flows can more rapidly respond to changes in
available capacity, whether due to other flows arriving and available capacity, whether due to other flows arriving and
departing or radio capacity varying. So it would wrong to require departing or radio capacity varying. So it would be wrong to require
short RTT flows to be as sluggish as long-RTT flows, which would short RTT flows to be as sluggish as long RTT flows, which would
unnecessarily under-utilize capacity and result in unnecessary unnecessarily underutilize capacity and result in unnecessary
overshoots and undershoots (instability). Therefore, rather than overshoots and undershoots (instability). Therefore, rather than
requiring strict RTT-independence, the wording says "as independent requiring strict RTT independence, the wording in Item <xref target="l 4sid_Prague_req-rtt-independence" format="counter"/> of <xref target="l4sid_cong estion_response" format="default"/> is "as independent
of RTT as possible without compromising stability or utilization". of RTT as possible without compromising stability or utilization".
This allows shorter RTT flows to exploit their agility This allows shorter RTT flows to exploit their agility
advantage.</t> advantage.</t>
</section> </section>
<section anchor="l4sid_sec_min_cwnd" numbered="true" toc="default"> <section anchor="l4sid_sec_min_cwnd" numbered="true" toc="default">
<name>Scaling down to fractional congestion windows</name> <name>Scaling Down to Fractional Congestion Windows</name>
<t>Description: A scalable congestion control needs to remain <t>Description: A Scalable congestion control needs to remain
responsive to congestion when typical RTTs over the public Internet responsive to congestion when typical RTTs over the public Internet
are significantly smaller because they are no longer inflated by are significantly smaller because they are no longer inflated by
queuing delay (see the precise normative requirement wording in queuing delay (see the precise normative requirement wording in
<xref target="l4sid_congestion_response" format="default"/>).</t> <xref target="l4sid_Prague_req-fractional-window" format="default"/>). </t>
<t>Motivation: As currently specified, the minimum congestion window <t>Motivation: As currently specified, the minimum congestion window
of ECN-capable TCP (and its derivatives) is expected to be 2 sender of ECN-capable TCP (and its derivatives) is expected to be 2 sender
maximum segment sizes (SMSS), or 1 SMSS after a retransmission maximum segment sizes (SMSS), or 1 SMSS after a retransmission
timeout. Once the congestion window reaches this minimum, if there timeout. Once the congestion window reaches this minimum, if there
is further ECN-marking, TCP is meant to wait for a retransmission is further ECN marking, TCP is meant to wait for a retransmission
timeout before sending another segment (see section 6.1.2 of the ECN timeout before sending another segment (see <xref target="RFC3168"
spec <xref target="RFC3168" format="default"/>). In practice, most kno sectionFormat="of" section="6.1.2">the ECN spec</xref>). In
wn practice, most known window-based congestion control algorithms
window-based congestion control algorithms become unresponsive to become unresponsive to ECN congestion signals at this point. No
ECN congestion signals at this point. No matter how much ECN matter how much ECN marking, the congestion window no longer
marking, the congestion window no longer reduces. Instead, the reduces. Instead, the sender's lack of any further congestion
sender's lack of any further congestion response forces the queue to response forces the queue to grow, overriding any AQM and increasing
grow, overriding any AQM and increasing queuing delay (making the queuing delay (making the window large enough to become responsive
window large enough to become responsive again). This can result in again). This can result in a stable but deeper queue, or it might
a stable but deeper queue, or it might drive the queue to loss, then drive the queue to loss, in which case the retransmission timeout mech
the retransmission timeout mechanism acts as a backstop.</t> anism
acts as a backstop.</t>
<t>Most window-based congestion controls for other transport <t>Most window-based congestion controls for other transport
protocols have a similar minimum window, albeit when measured in protocols have a similar minimum window, albeit when measured in
bytes for those that use smaller packets.</t> bytes for those that use smaller packets.</t>
<t>L4S mechanisms significantly reduce queueing delay so, over the <t>L4S mechanisms significantly reduce queuing delay so, over the
same path, the RTT becomes lower. Then this problem becomes same path, the RTT becomes lower. Then, this problem becomes
surprisingly common <xref target="sub-mss-prob" format="default"/>. Th surprisingly common <xref target="sub-mss-prob" format="default"/>. Th
is is is is
because, for the same link capacity, smaller RTT implies a smaller because, for the same link capacity, smaller RTT implies a smaller
window. For instance, consider a residential setting with an window. For instance, consider a residential setting with an
upstream broadband Internet access of 8 Mb/s, assuming a max upstream broadband Internet access of 8 Mb/s, assuming a max
segment size of 1500 B. Two upstream flows will each have the segment size of 1500 B. Two upstream flows will each have the
minimum window of 2 SMSS if the RTT is 6 ms or less, which minimum window of 2 SMSS if the RTT is 6 ms or less, which
is quite common when accessing a nearby data centre. So, any more is quite common when accessing a nearby data centre. So any more
than two such parallel TCP flows will become unresponsive to ECN and than two such parallel TCP flows will become unresponsive to ECN and
increase queuing delay.</t> increase queuing delay.</t>
<t>Unless scalable congestion controls address the requirement in <t>Unless Scalable congestion controls address the requirement in
<xref target="l4sid_congestion_response" format="default"/> from the s tart, they will <xref target="l4sid_congestion_response" format="default"/> from the s tart, they will
frequently become unresponsive to ECN, negating the low latency frequently become unresponsive to ECN, negating the low-latency
benefit of L4S, for themselves and for others.</t> benefit of L4S, for themselves and for others.</t>
<t>That would seem to imply that scalable congestion controllers <t>That would seem to imply that Scalable congestion controllers
ought to be required to be able work with a congestion window less ought to be required to be able work with a congestion window less
than 1 SMSS. For instance, if an ECN-capable TCP gets an than 1 SMSS. For instance, if an ECN-capable TCP gets an
ECN-mark when it is already sitting at a window of 1 SMSS, ECN mark when it is already sitting at a window of 1 SMSS,
RFC 3168 requires it to defer sending for a retransmission <xref target="RFC3168" format="default"/> requires it to defer sending
for a retransmission
timeout. A less drastic but more complex mechanism can maintain a timeout. A less drastic but more complex mechanism can maintain a
congestion window less than 1 SMSS (significantly less if congestion window less than 1 SMSS (significantly less if
necessary), as described in <xref target="Ahmed19" format="default"/>. Other necessary), as described in <xref target="Ahmed19" format="default"/>. Other
approaches are likely to be feasible.</t> approaches are likely to be feasible.</t>
<t>However, the requirement in <xref target="l4sid_congestion_response " format="default"/> is worded as a "SHOULD" because <t>However, the requirement in <xref target="l4sid_congestion_response " format="default"/> is worded as a "<bcp14>SHOULD</bcp14>" because
it is believed that the existence of a minimum window is not all it is believed that the existence of a minimum window is not all
bad. When competing with an unresponsive flow, a minimum window bad. When competing with an unresponsive flow, a minimum window
naturally protects the flow from starvation by at least keeping some naturally protects the flow from starvation by at least keeping some
data flowing.</t> data flowing.</t>
<t>By stating the requirement to go lower than 1 SMSS as a <t>By stating the requirement to go lower than 1 SMSS as a
"SHOULD", while the requirement in RFC 3168 still stands as "<bcp14>SHOULD</bcp14>", while the requirement in <xref target="RFC316
8" format="default"/> still stands as
well, we shall be able to watch the choices of minimum window evolve well, we shall be able to watch the choices of minimum window evolve
in different scalable congestion controllers.</t> in different Scalable congestion controllers.</t>
<!-- Requirement #3.5: Smoothing ECN feedback
Description: The ratio of marked packets CE marks received by the
scalable transport sender are averaged
</section> </section>
<section anchor="l4sid_sec_reordering_tolerance" numbered="true" toc="de fault"> <section anchor="l4sid_sec_reordering_tolerance" numbered="true" toc="de fault">
<name>Measuring Reordering Tolerance in Time Units</name> <name>Measuring Reordering Tolerance in Time Units</name>
<t>Description: When detecting loss, a scalable congestion control <t>Description: When detecting loss, a Scalable congestion control
needs to be tolerant to reordering over an adaptive time interval, needs to be tolerant to reordering over an adaptive time interval,
which scales with throughput, rather than counting only in fixed which scales with throughput, rather than counting only in fixed
units of packets, which does not scale (see the precise normative units of packets, which does not scale (see the precise normative
requirement wording in <xref target="l4sid_congestion_response" format ="default"/>).</t> requirement wording in <xref target="l4sid_Prague_req-reordering" form at="default"/>).</t>
<t>Motivation: A primary purpose of L4S is scalable throughput (it's <t>Motivation: A primary purpose of L4S is scalable throughput (it's
in the name). Scalability in all dimensions is, of course, also a in the name). Scalability in all dimensions is, of course, also a
goal of all IETF technology. The inverse linear congestion response goal of all IETF technology. The inverse linear congestion response
in <xref target="l4sid_congestion_response" format="default"/> is nece ssary, but not in <xref target="l4sid_congestion_response" format="default"/> is nece ssary, but not
sufficient, to solve the congestion control scalability problem sufficient, to solve the congestion control scalability problem
identified in <xref target="RFC3649" format="default"/>. As well as ma intaining identified in <xref target="RFC3649" format="default"/>. As well as ma intaining
frequent ECN signals as rate scales, it is also important to ensure frequent ECN signals as rate scales, it is also important to ensure
that a potentially false perception of loss does not limit that a potentially false perception of loss does not limit
throughput scaling.</t> throughput scaling.</t>
<t>End-systems cannot know whether a missing packet is due to loss <t>End systems cannot know whether a missing packet is due to loss
or reordering, except in hindsight - if it appears later. So they or reordering, except in hindsight -- if it appears later. So they
can only deem that there has been a loss if a gap in the sequence can only deem that there has been a loss if a gap in the sequence
space has not been filled, either after a certain number of space has not been filled, either after a certain number of
subsequent packets has arrived (e.g. the 3 DupACK rule of subsequent packets has arrived (e.g., the 3 DupACK rule of
standard TCP congestion control <xref target="RFC5681" format="default standard TCP congestion control <xref target="RFC5681" format="default
"/>) or "/>) or
after a certain amount of time (e.g. the RACK after a certain amount of time (e.g., the RACK
approach <xref target="RFC8985" format="default"/>).</t> approach <xref target="RFC8985" format="default"/>).</t>
<t>As we attempt to scale packet rate over the years:</t> <t>As we attempt to scale packet rate over the years:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Even if only <em>some</em> sending hosts <li>Even if only <em>some</em> sending hosts
still deem that loss has occurred by counting reordered packets, still deem that loss has occurred by counting reordered packets,
<em>all</em> networks will have to keep <em>all</em> networks will have to keep
reducing the time over which they keep packets in order. If some reducing the time over which they keep packets in order. If some
link technologies keep the time within which reordering occurs link technologies keep the time within which reordering occurs
roughly unchanged, then loss over these links, as perceived by roughly unchanged, then loss over these links, as perceived by
these hosts, will appear to continually rise over the years.</li> these hosts, will appear to continually rise over the years.</li>
<li>In contrast, if all senders detect loss in units of time, the <li>In contrast, if all senders detect loss in units of time, the
time over which the network has to keep packets in order stays time over which the network has to keep packets in order stays
roughly invariant.</li> roughly invariant.</li>
</ul> </ul>
<t>Therefore, hosts have an incentive to detect loss in time <t>Therefore, hosts have an incentive to detect loss in time
units (so as not to fool themselves too often into detecting losses units (so as not to fool themselves too often into detecting losses
when there are none). And for hosts that are changing their when there are none). And for hosts that are changing their
congestion control implementation to L4S, there is no downside to congestion control implementation to L4S, there is no downside to
including time-based loss detection code in the change (loss including time-based loss detection code in the change (loss
recovery implemented in hardware is an exception, covered later). recovery implemented in hardware is an exception, which is covered lat er).
Therefore, requiring L4S hosts to detect loss in time-based units Therefore, requiring L4S hosts to detect loss in time-based units
would not be a burden.</t> would not be a burden.</t>
<t>If the requirement in <xref target="l4sid_congestion_response" form at="default"/> <t>If the requirement in <xref target="l4sid_congestion_response" form at="default"/>
were not placed on L4S hosts, even though it would be no burden on were not placed on L4S hosts, even though it would be no burden on
hosts to comply, all networks would face unnecessary uncertainty hosts to comply, all networks would face unnecessary uncertainty
over whether some L4S hosts might be detecting loss by counting over whether some L4S hosts might be detecting loss by counting
packets. Then <em>all</em> link technologies will packets. Then, <em>all</em> link technologies would
have to unnecessarily keep reducing the time within which reordering have to unnecessarily keep reducing the time within which reordering
occurs. That is not a problem for some link technologies, but it occurs. That is not a problem for some link technologies, but it
becomes increasingly challenging for other link technologies to becomes increasingly challenging for other link technologies to
continue to scale, particularly those relying on channel bonding for continue to scale, particularly those relying on channel bonding for
scaling, such as LTE, 5G and DOCSIS.</t> scaling, such as LTE, 5G, and Data Over Cable Service Interface Specif ication (DOCSIS).</t>
<t>Given Internet paths traverse many link technologies, any scaling <t>Given Internet paths traverse many link technologies, any scaling
limit for these more challenging access link technologies would limit for these more challenging access link technologies would
become a scaling limit for the Internet as a whole.</t> become a scaling limit for the Internet as a whole.</t>
<t>It might be asked how it helps to place this loss detection <t>It might be asked how it helps to place this loss detection
requirement only on L4S hosts, because networks will still face requirement only on L4S hosts, because networks will still face
uncertainty over whether non-L4S flows are detecting loss by uncertainty over whether non-L4S flows are detecting loss by
counting DupACKs. The answer is that those link technologies for counting DupACKs. The answer is that those link technologies for
which it is challenging to keep squeezing the reordering time will which it is challenging to keep squeezing the reordering time will
only need to do so for non-L4S traffic (which they can do because only need to do so for non-L4S traffic (which they can do because
the L4S identifier is visible at the IP layer). Therefore, they can the L4S identifier is visible at the IP layer). Therefore, they can
focus their processing and memory resources into scaling non-L4S focus their processing and memory resources into scaling non-L4S
(Classic) traffic. Then, the higher the proportion of L4S traffic, (Classic) traffic. Then, the higher the proportion of L4S traffic,
the less of a scaling challenge they will have.</t> the less of a scaling challenge they will have.</t>
<t>To summarize, there is no reason for L4S hosts not to be part of <t>To summarize, there is no reason for L4S hosts not to be part of
the solution instead of part of the problem.</t> the solution instead of part of the problem.</t>
<t>Requirement ("MUST") or recommendation ("SHOULD")? As explained <t>Requirement ("<bcp14>MUST</bcp14>") or recommendation ("<bcp14>SHOU LD</bcp14>")? As explained
above, this is a subtle interoperability issue between hosts and above, this is a subtle interoperability issue between hosts and
networks, which seems to need a "MUST". Unless networks can be networks, which seems to need a "<bcp14>MUST</bcp14>". Unless networks can be
certain that all L4S hosts follow the time-based approach, they certain that all L4S hosts follow the time-based approach, they
still have to cater for the worst case - continually squeeze still have to cater for the worst case -- continually squeeze
reordering into a smaller and smaller duration - just for hosts that reordering into a smaller and smaller duration -- just for hosts that
might be using the counting approach. However, it was decided to might be using the counting approach. However, it was decided to
express this as a recommendation, using "SHOULD". The main express this as a recommendation, using "<bcp14>SHOULD</bcp14>". The m ain
justification was that networks can still be fairly certain that L4S justification was that networks can still be fairly certain that L4S
hosts will follow this recommendation, because following it offers hosts will follow this recommendation, because following it offers
only gain and no pain.</t> only gain and no pain.</t>
<t>Details:</t> <t>Details:</t>
<t>The speed of loss recovery is much more significant for short
flows than long, therefore a good compromise is to adapt the <t>The time spent recovering a loss is much more significant for short
reordering window; from a small fraction of the RTT at the start of flows than long; therefore, a good compromise is to adapt the
a flow, to a larger fraction of the RTT for flows that continue for reordering window from a small fraction of the RTT at the start of
a flow to a larger fraction of the RTT for flows that continue for
many round trips.</t> many round trips.</t>
<t>This is broadly the approach adopted by TCP RACK (Recent <t>This is broadly the approach adopted by RACK <xref target="RFC8985"
ACKnowledgements) <xref target="RFC8985" format="default"/>. However, format="default"/>. However, RACK
RACK
starts with the 3 DupACK approach, because the RTT estimate is not starts with the 3 DupACK approach, because the RTT estimate is not
necessarily stable. As long as the initial window is paced, such necessarily stable. As long as the initial window is paced, such
initial use of 3 DupACK counting would amount to time-based loss initial use of 3 DupACK counting would amount to time-based loss
detection and therefore would satisfy the time-based loss detection detection and therefore would satisfy the time-based loss detection
recommendation of <xref target="l4sid_congestion_response" format="def ault"/>. This recommendation of <xref target="l4sid_congestion_response" format="def ault"/>. This
is because pacing of the initial window would ensure that 3 DupACKs is because pacing of the initial window would ensure that 3 DupACKs
early in the connection would be spread over a small fraction of the early in the connection would be spread over a small fraction of the
round trip.</t> round trip.</t>
<t>As mentioned above, hardware implementations of loss recovery <t>As mentioned above, hardware implementations of loss recovery
using DupACK counting exist (e.g. some implementations of using DupACK counting exist (e.g., some implementations of
RoCEv2 for RDMA). For low latency, these implementations can change Remote Direct Memory Access over Converged Ethernet version 2 (RoCEv2)
).
For low latency, these implementations can change
their congestion control to implement L4S, because the congestion their congestion control to implement L4S, because the congestion
control (as distinct from loss recovery) is implemented in software. control (as distinct from loss recovery) is implemented in software.
But they cannot easily satisfy this loss recovery requirement. But they cannot easily satisfy this loss recovery requirement.
However, it is believed they do not need to, because such However, it is believed they do not need to, because such
implementations are believed to solely exist in controlled implementations are believed to solely exist in controlled
environments, where the network technology keeps reordering environments, where the network technology keeps reordering
extremely low anyway. This is why controlled environments with extremely low anyway. This is why controlled environments with
hardly any reordering are excluded from the scope of the normative hardly any reordering are excluded from the scope of the normative
recommendation in <xref target="l4sid_congestion_response" format="def ault"/>.</t> recommendation in <xref target="l4sid_congestion_response" format="def ault"/>.</t>
<t>Detecting loss in time units also prevents the ACK-splitting <t>Detecting loss in time units also prevents the ACK-splitting
attacks described in <xref target="Savage-TCP" format="default"/>.</t> attacks described in <xref target="Savage-TCP" format="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Scalable Transport Protocol Optimizations</name> <name>Scalable Transport Protocol Optimizations</name>
<t/>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Setting ECT in Control Packets and Retransmissions</name> <name>Setting ECT in Control Packets and Retransmissions</name>
<t>Description: This item concerns TCP and its derivatives <t>Description: This item concerns TCP and its derivatives
(e.g. SCTP) as well as RTP/RTCP <xref target="RFC6679" format="default "/>. (e.g., SCTP) as well as RTP/RTCP <xref target="RFC6679" format="defaul t"/>.
The original specification of ECN for TCP precluded the use of ECN The original specification of ECN for TCP precluded the use of ECN
on control packets and retransmissions. Similarly, RFC 6679 on control packets and retransmissions. Similarly, <xref target="RFC66 79" format="default"/>
precludes the use of ECT on RTCP datagrams, in case the path changes precludes the use of ECT on RTCP datagrams, in case the path changes
after it has been checked for ECN traversal. To improve performance, after it has been checked for ECN traversal. To improve performance,
scalable transport protocols ought to enable ECN at the IP layer in Scalable transport protocols ought to enable ECN at the IP layer in
TCP control packets (SYN, SYN-ACK, pure ACKs, etc.) and in TCP control packets (SYN, SYN-ACK, pure ACKs, etc.) and in
retransmitted packets. The same is true for other transports, retransmitted packets. The same is true for other transports,
e.g. SCTP, RTCP.</t> e.g., SCTP and RTCP.</t>
<t>Motivation (TCP): RFC 3168 prohibits the use of ECN on these <t>Motivation (TCP): <xref target="RFC3168" format="default"/> prohibi
types of TCP packet, based on a number of arguments. This means ts the use of ECN on these
types of TCP packets, based on a number of arguments. This means
these packets are not protected from congestion loss by ECN, which these packets are not protected from congestion loss by ECN, which
considerably harms performance, particularly for short flows. considerably harms performance, particularly for short flows.
ECN++ <xref target="I-D.ietf-tcpm-generalized-ecn" format="default"/> ECN++ <xref target="I-D.ietf-tcpm-generalized-ecn" format="default"/>
proposes proposes
experimental use of ECN on all types of TCP packet as long as AccECN experimental use of ECN on all types of TCP packets as long as AccECN
feedback <xref target="I-D.ietf-tcpm-accurate-ecn" format="default"/> feedback <xref target="I-D.ietf-tcpm-accurate-ecn" format="default"/>
is is
available (which itself satisfies the accurate feedback requirement available (which itself satisfies the accurate feedback requirement
in <xref target="l4sid_feedback" format="default"/> for using a scalab le congestion in <xref target="l4sid_feedback" format="default"/> for using a Scalab le congestion
control).</t> control).</t>
<t>Motivation (RTCP): L4S experiments in general will need to <t>Motivation (RTCP): L4S experiments in general will need to
observe the rule in the RTP ECN spec <xref target="RFC6679" format="de fault"/> observe the rule in the RTP ECN spec <xref target="RFC6679" format="de fault"/>
that precludes ECT on RTCP datagrams. Nonetheless, as ECN usage that precludes ECT on RTCP datagrams. Nonetheless, as ECN usage
becomes more widespread, it would be useful to conduct specific becomes more widespread, it would be useful to conduct specific
experiments with ECN-capable RTCP to gather data on whether such experiments with ECN-capable RTCP to gather data on whether such
caution is necessary.</t> caution is necessary.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Faster than Additive Increase</name> <name>Faster than Additive Increase</name>
<t>Description: It would improve performance if scalable congestion <t>Description: It would improve performance if Scalable congestion
controls did not limit their congestion window increase to the controls did not limit their congestion window increase to the
standard additive increase of 1 SMSS per round trip <xref target="RFC5 681" format="default"/> during congestion avoidance. The same is true for standard additive increase of 1 SMSS per round trip <xref target="RFC5 681" format="default"/> during congestion avoidance. The same is true for
derivatives of TCP congestion control, including similar approaches derivatives of TCP congestion control, including similar approaches
used for real-time media.</t> used for real-time media.</t>
<t>Motivation: As currently defined <xref target="RFC8257" format="def <t>Motivation: As currently defined <xref target="RFC8257" format="def
ault"/>, ault"/>,
DCTCP uses the conventional Reno additive increase in congestion DCTCP uses the conventional Reno additive increase in the congestion
avoidance phase. When the available capacity suddenly increases avoidance phase. When the available capacity suddenly increases
(e.g. when another flow finishes, or if radio capacity (e.g., when another flow finishes or if radio capacity
increases) it can take very many round trips to take advantage of increases) it can take very many round trips to take advantage of
the new capacity. TCP Cubic <xref target="RFC8312" format="default"/> was the new capacity. TCP CUBIC <xref target="RFC8312" format="default"/> was
designed to solve this problem, but as flow rates have continued to designed to solve this problem, but as flow rates have continued to
increase, the delay accelerating into available capacity has become increase, the delay accelerating into available capacity has become
prohibitive. See, for instance, the examples in Section 5.1 of the prohibitive. See, for instance, the examples in Section <xref target="
L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" format="defaul RFC9330" section="5.1"
t"/>. Even sectionFormat="bare"/> of the
when out of its Reno-compatibility mode, every 8x scaling of Cubic's L4S architecture <xref target="RFC9330" format="default"/>. Even
flow rate leads to 2x more acceleration delay.</t> when out of its Reno-friendly mode, every 8 times scaling of CUBIC's f
low
rate leads to 2 times more acceleration delay.</t>
<t>In the steady state, DCTCP induces about 2 ECN marks per round <t>In the steady state, DCTCP induces about 2 ECN marks per round
trip, so it is possible to quickly detect when these signals have trip, so it is possible to quickly detect when these signals have
disappeared and seek available capacity more rapidly, while disappeared and seek available capacity more rapidly, while
minimizing the impact on other flows (Classic and minimizing the impact on other flows (Classic and
scalable) <xref target="LinuxPacedChirping" format="default"/>. Altern Scalable) <xref target="LinuxPacedChirping" format="default"/>. Altern
atively, atively,
approaches such as Adaptive Acceleration (A2DTCP <xref target="A2DTCP" approaches such as Adaptive-Acceleration Data Center TCP (A2DTCP) <xre
format="default"/>) have been proposed to address this problem in f target="A2DTCP" format="default"/>) have been proposed to address this problem
in
data centres, which might be deployable over the public data centres, which might be deployable over the public
Internet.</t> Internet.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Faster Convergence at Flow Start</name> <name>Faster Convergence at Flow Start</name>
<t>Description: It would improve performance if scalable congestion <t>Description: It would improve performance if Scalable congestion
controls converged (reached their steady-state share of the controls converged (reached their steady-state share of the
capacity) faster than Classic congestion controls or at least no capacity) faster than Classic congestion controls or at least no
slower. This affects the flow start behaviour of any L4S congestion slower. This affects the flow start behaviour of any L4S congestion
control derived from a Classic transport that uses TCP slow start, control derived from a Classic transport that uses TCP slow start,
including those for real-time media.</t> including those for real-time media.</t>
<t>Motivation: As an example, a new DCTCP flow takes longer than a <t>Motivation: As an example, a new DCTCP flow takes longer than a
Classic congestion control to obtain its share of the capacity of Classic congestion control to obtain its share of the capacity of
the bottleneck when there are already ongoing flows using the the bottleneck when there are already ongoing flows using the
bottleneck capacity. In a data centre environment DCTCP takes about bottleneck capacity.
a factor of 1.5 to 2 longer to converge due to the much higher In a data-centre environment, DCTCP takes about
1.5 to 2 times longer to converge due to the much higher
typical level of ECN marking that DCTCP background traffic induces, typical level of ECN marking that DCTCP background traffic induces,
which causes new flows to exit slow start early <xref target="Alizadeh which causes new flows to exit slow start early <xref target="Alizadeh
-stability" format="default"/>. In testing for use over the public -stability" format="default"/>. In testing for use over the public
Internet the convergence time of DCTCP relative to a regular Internet, the convergence time of DCTCP relative to a regular
loss-based TCP slow start is even less favourable <xref target="Paced- loss-based TCP slow start is even less favourable <xref target="LinuxP
Chirping" format="default"/> due to the shallow ECN marking threshold acedChirping" format="default"/> due to the shallow ECN-marking threshold
needed for L4S. It is exacerbated by the typically greater mismatch needed for L4S. It is exacerbated by the typically greater mismatch
between the link rate of the sending host and typical Internet between the link rate of the sending host and typical Internet
access bottlenecks. This problem is detrimental in general, but access bottlenecks. This problem is detrimental in general but
would particularly harm the performance of short flows relative to would particularly harm the performance of short flows relative to
Classic congestion controls.</t> Classic congestion controls.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="l4sid_ECT1_CE" numbered="true" toc="default"> <section anchor="l4sid_ECT1_CE" numbered="true" toc="default">
<name>Compromises in the Choice of L4S Identifier</name> <name>Compromises in the Choice of L4S Identifier</name>
<t>This appendix is informative, not normative. As explained in <xref targ et="l4sid_reqs" format="default"/>, there is insufficient space in the IP header (v4 <t>This appendix is informative, not normative. As explained in <xref targ et="l4sid_reqs" format="default"/>, there is insufficient space in the IP header (v4
or v6) to fully accommodate every requirement. So the choice of L4S or v6) to fully accommodate every requirement. So the choice of L4S
identifier involves tradeoffs. This appendix records the pros and cons identifier involves trade-offs. This appendix records the pros and cons
of the choice that was made.</t> of the choice that was made.</t>
<t>Non-normative recap of the chosen codepoint scheme:</t> <t>Non-normative recap of the chosen codepoint scheme:</t>
<ul empty="true" spacing="normal"> <ul spacing="normal" empty="true">
<li> <li>
<t>Packets with ECT(1) and conditionally packets with CE signify L4S <t>Packets with ECT(1) and conditionally packets with CE signify L4S
semantics as an alternative to the semantics of Classic semantics as an alternative to the semantics of Classic
ECN <xref target="RFC3168" format="default"/>, specifically:</t> ECN <xref target="RFC3168" format="default"/>, specifically:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The ECT(1) codepoint signifies that the packet was sent by an <li>The ECT(1) codepoint signifies that the packet was sent by an
L4S-capable sender.</li> L4S-capable sender.</li>
<li>Given shortage of codepoints, both L4S and Classic ECN sides <li>Given the shortage of codepoints, both the L4S and Classic ECN s ides
of an AQM have to use the same CE codepoint to indicate that a of an AQM have to use the same CE codepoint to indicate that a
packet has experienced congestion. If a packet that had already packet has experienced congestion. If a packet that had already
been marked CE in an upstream buffer arrived at a subsequent been marked CE in an upstream buffer arrived at a subsequent
AQM, this AQM would then have to guess whether to classify CE AQM, this AQM would then have to guess whether to classify CE
packets as L4S or Classic ECN. Choosing the L4S treatment is a packets as L4S or Classic ECN.
Choosing the L4S treatment is a
safer choice, because then a few Classic packets might arrive safer choice, because then a few Classic packets might arrive
early, rather than a few L4S packets arriving late.</li> early rather than a few L4S packets arriving late.</li>
<li>Additional information might be available if the classifier <li>Additional information might be available if the classifier
were transport-aware. Then it could classify a CE packet for were transport-aware. Then, it could classify a CE packet for
Classic ECN treatment if the most recent ECT packet in the same Classic ECN treatment if the most recent ECT packet in the same
flow had been marked ECT(0). However, the L4S service ought not flow had been set to ECT(0). However, the L4S service ought not
to need transport-layer awareness.</li> need transport-layer awareness.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>Cons:</t> <t>Cons:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Consumes the last ECN codepoint:</dt> <dt>Consumes the last ECN codepoint:</dt>
<dd>The L4S service could <dd>The L4S service could
potentially supersede the service provided by Classic ECN, therefore potentially supersede the service provided by Classic ECN; therefore,
using ECT(1) to identify L4S packets could ultimately mean that the using ECT(1) to identify L4S packets could ultimately mean that the
ECT(0) codepoint was 'wasted' purely to distinguish one form of ECN ECT(0) codepoint was 'wasted' purely to distinguish one form of ECN
from its successor.</dd> from its successor.</dd>
<dt>ECN hard in some lower layers:</dt> <dt>ECN hard in some lower layers:</dt>
<dd>It is not always <dd>It is not always
possible to support the equivalent of an IP-ECN field in an AQM possible to support the equivalent of an IP-ECN field in an AQM
acting in a buffer below the IP layer <xref target="I-D.ietf-tsvwg-ecn acting in a buffer below the IP layer <xref target="I-D.ietf-tsvwg-ecn
-encap-guidelines" format="default"/>. Then, depending on -encap-guidelines" format="default"/>. Then, depending on
the lower layer scheme, the L4S service might have to drop rather the lower-layer scheme, the L4S service might have to drop rather
than mark frames even though they might encapsulate an ECN-capable than mark frames even though they might encapsulate an ECN-capable
packet.</dd> packet.</dd>
<dt>Risk of reordering Classic CE packets within a flow:</dt> <dt>Risk of reordering Classic CE packets within a flow:</dt>
<dd anchor="l4sid_CE_reordering"> <dd anchor="l4sid_CE_reordering">
<t>Classifying <t>Classifying
all CE packets into the L4S queue risks any CE packets that were all CE packets into the L4S queue risks any CE packets that were
originally ECT(0) being incorrectly classified as L4S. If there were originally ECT(0) being incorrectly classified as L4S. If there were
delay in the Classic queue, these incorrectly classified CE packets delay in the Classic queue, these incorrectly classified CE packets
would arrive early, which is a form of reordering. Reordering within would arrive early, which is a form of reordering. Reordering within
a microflow can cause TCP senders (and senders of similar a microflow can cause TCP senders (and senders of similar
skipping to change at line 4010 skipping to change at line 2909
originally ECT(0) being incorrectly classified as L4S. If there were originally ECT(0) being incorrectly classified as L4S. If there were
delay in the Classic queue, these incorrectly classified CE packets delay in the Classic queue, these incorrectly classified CE packets
would arrive early, which is a form of reordering. Reordering within would arrive early, which is a form of reordering. Reordering within
a microflow can cause TCP senders (and senders of similar a microflow can cause TCP senders (and senders of similar
transports) to retransmit spuriously. However, the risk of spurious transports) to retransmit spuriously. However, the risk of spurious
retransmissions would be extremely low for the following retransmissions would be extremely low for the following
reasons:</t> reasons:</t>
<ol spacing="normal" type="1"><li>It is quite unusual to experience qu euing at more than one <ol spacing="normal" type="1"><li>It is quite unusual to experience qu euing at more than one
bottleneck on the same path (the available capacities have to be bottleneck on the same path (the available capacities have to be
identical).</li> identical).</li>
<li>In only a subset of these unusual cases would the first <li>In only a subset of these unusual cases would the first
bottleneck support Classic ECN marking while the second bottleneck support Classic ECN marking and the second
supported L4S ECN marking, which would be the only scenario L4S ECN marking. This would be the only scenario
where some ECT(0) packets could be CE marked by an AQM where some ECT(0) packets could be CE marked by an AQM
supporting Classic ECN then the remainder experienced further supporting Classic ECN while subsequently the remaining ECT(0) pac kets would experience further
delay through the Classic side of a subsequent L4S DualQ delay through the Classic side of a subsequent L4S DualQ
AQM.</li> AQM.</li>
<li> <li>
<t>Even then, when a few packets are delivered early, it takes <t>Even then, when a few packets are delivered early, it takes
very unusual conditions to cause a spurious retransmission, in very unusual conditions to cause a spurious retransmission, in
contrast to when some packets are delivered late. The first contrast to when some packets are delivered late. The first
bottleneck has to apply CE-marks to at least N contiguous bottleneck has to apply CE marks to at least N contiguous
packets and the second bottleneck has to inject an uninterrupted packets, and the second bottleneck has to inject an uninterrupted
sequence of at least N of these packets between two packets sequence of at least N of these packets between two packets
earlier in the stream (where N is the reordering window that the earlier in the stream (where N is the reordering window that the
transport protocol allows before it considers a packet is transport protocol allows before it considers a packet is
lost).</t> lost).</t>
<ul empty="true" spacing="normal"> <ul spacing="normal" empty="true">
<li>For example consider N=3, and consider the sequence of
packets 100, 101, 102, 103,... and imagine that packets <li>For example, consider N=3, and consider the sequence of
150,151,152 from later in the flow are injected as follows: packets 100, 101, 102, 103,... Imagine that packets
100, 150, 151, 101, 152, 102, 103... If this were late 150, 151, 152 from later in the flow are injected as follows:
100, 150, 151, 101, 152, 102, 103,... If this were late
reordering, even one packet arriving out of sequence would reordering, even one packet arriving out of sequence would
trigger a spurious retransmission, but there is no spurious trigger a spurious retransmission, but there is no spurious
retransmission here with early reordering, because packet retransmission here with early reordering, because packet
101 moves the cumulative ACK counter forward before 3 101 moves the cumulative ACK counter forward before 3
packets have arrived out of order. Later, when packets 148, packets have arrived out of order.
149, 153... arrive, even though there is a 3-packet hole, Later, when packets 148,
149, 153,... arrive, even though there is a 3-packet hole,
there will be no problem, because the packets to fill the there will be no problem, because the packets to fill the
hole are already in the receive buffer.</li> hole are already in the receive buffer.</li>
</ul> </ul>
</li> </li>
<li>Even with the current TCP recommendation of N=3 <xref target="RF <li>Even with the current TCP recommendation of N=3 <xref target="RF
C5681" format="default"/> spurious retransmissions will be unlikely for C5681" format="default"/>, spurious retransmissions will be unlikely for
all the above reasons. As RACK <xref target="RFC8985" format="defa all the above reasons. As RACK <xref target="RFC8985" format="defa
ult"/> is ult"/> is
becoming widely deployed, it tends to adapt its reordering becoming widely deployed, it tends to adapt its reordering
window to a larger value of N, which will make the chance of a window to a larger value of N, which will make the chance of a
contiguous sequence of N early arrivals vanishingly small.</li> contiguous sequence of N early arrivals vanishingly small.</li>
<li>Even a run of 2 CE marks within a Classic ECN flow is <li>Even a run of 2 CE marks within a Classic ECN flow is
unlikely, given FQ-CoDel is the only known widely deployed AQM unlikely, given FQ-CoDel is the only known widely deployed AQM
that supports Classic ECN marking and it takes great care to that supports Classic ECN marking, and it takes great care to
separate out flows and to space any markings evenly along each separate out flows and to space any markings evenly along each
flow.</li> flow.</li>
</ol> </ol>
<t>It is extremely unlikely that the above set of 5 <t>It is extremely unlikely that the above set of 5
eventualities that are each unusual in themselves would all happen eventualities that are each unusual in themselves would all happen
simultaneously. But, even if they did, the consequences would hardly simultaneously. But, even if they did, the consequences would hardly
be dire: the odd spurious fast retransmission. Whenever the traffic be dire: the odd spurious fast retransmission. Whenever the traffic
source (a Classic congestion control) mistakes the reordering of a source (a Classic congestion control) mistakes the reordering of a
string of CE marks for a loss, one might think that it will reduce string of CE marks for a loss, one might think that it will reduce
its congestion window as well as emitting a spurious retransmission. its congestion window as well as emitting a spurious retransmission.
However, it would have already reduced its congestion window when However, it would have already reduced its congestion window when
the CE markings arrived early. If it is using ABE <xref target="RFC851 1" format="default"/>, it might reduce cwnd a little more for a loss the CE markings arrived early. If it is using ABE <xref target="RFC851 1" format="default"/>, it might reduce cwnd a little more for a loss
than for a CE mark. But it will revert that reduction once it than for a CE mark. But it will revert that reduction once it
detects that the retransmission was spurious.</t> detects that the retransmission was spurious.</t>
<t>In conclusion, the impact of early reordering on <t>In conclusion, the impact of early reordering on
spurious retransmissions due to CE being ambiguous will generally be spurious retransmissions due to CE being ambiguous will generally be
vanishingly small.</t> vanishingly small.</t>
</dd> </dd>
<dt>Insufficient anti-replay window in some pre-existing VPNs:</dt> <dt>Insufficient anti-replay window in some pre-existing VPNs:</dt>
<dd>If <dd>If
delay is reduced for a subset of the flows within a VPN, the delay is reduced for a subset of the flows within a VPN, the
anti-replay feature of some VPNs is known to potentially mistake the anti-replay feature of some VPNs is known to potentially mistake the
difference in delay for a replay attack. <xref target="l4sid_VPN_anti- replay" format="default"/> recommends that the anti-replay difference in delay for a replay attack. <xref target="l4sid_VPN_anti- replay" format="default"/> recommends that the anti-replay
window at the VPN egress is sufficiently sized, as required by the window at the VPN egress is sufficiently sized, as required by the
relevant specifications. However, in some VPN implementations the relevant specifications.
However, in some VPN implementations, the
maximum anti-replay window is insufficient to cater for a large maximum anti-replay window is insufficient to cater for a large
delay difference at prevailing packet rates. <xref target="l4sid_VPN_a nti-replay" format="default"/> suggests alternative work-rounds delay difference at prevailing packet rates. <xref target="l4sid_VPN_a nti-replay" format="default"/> suggests alternative work-rounds
for such cases, but end-users using L4S over a VPN will need to be for such cases, but end users using L4S over a VPN will need to be
able to recognize the symptoms of this problem, in order to seek out able to recognize the symptoms of this problem, in order to seek out
these work-rounds.</dd> these work-rounds.</dd>
<dt>Hard to distinguish Classic ECN AQM:</dt> <dt>Hard to distinguish Classic ECN AQM:</dt>
<dd> <dd>
<t>With this scheme, <t>With this scheme,
when a source receives ECN feedback, it is not explicitly clear when a source receives ECN feedback, it is not explicitly clear
which type of AQM generated the CE markings. This is not a problem which type of AQM generated the CE markings. This is not a problem
for Classic ECN sources that send ECT(0) packets, because an L4S AQM for Classic ECN sources that send ECT(0) packets, because an L4S AQM
will recognize the ECT(0) packets as Classic and apply the will recognize the ECT(0) packets as Classic and apply the
appropriate Classic ECN marking behaviour.</t> appropriate Classic ECN-marking behaviour.</t>
<t>However, in the absence of explicit disambiguation <t>However, in the absence of explicit disambiguation
of the CE markings, an L4S source needs to use heuristic techniques of the CE markings, an L4S source needs to use heuristic techniques
to work out which type of congestion response to apply (see <xref targ to work out which type of congestion response to apply (see <xref targ
et="l4sid_sec_fallback_on_classic_CE" format="default"/>). Otherwise, if et="l4sid_sec_fallback_on_classic_CE" format="default"/>).
long-running Classic flow(s) are sharing a Classic ECN AQM Otherwise, if
bottleneck with long-running L4S flow(s), which then apply an L4S long-running Classic flows are sharing a Classic ECN AQM
response to Classic CE signals, the L4S flows would outcompete the bottleneck with long-running L4S flows, and the L4S flows apply an L4S
Classic flow(s). Experiments have shown that L4S flows can take response to the Classic CE signals, they would then outcompete the
Classic flows. Experiments have shown that L4S flows can take
about 20 times more capacity share than equivalent Classic flows. about 20 times more capacity share than equivalent Classic flows.
Nonetheless, as link capacity reduces (e.g. to 4 Mb/s), the Nonetheless, as link capacity reduces (e.g., to 4 Mb/s), the
inequality reduces. So Classic flows always make progress and are inequality reduces. So Classic flows always make progress and are
not starved.</t> not starved.</t>
<t>When L4S was first proposed (in <t>When L4S was first proposed (in
2015, 14 years after the Classic ECN spec <xref target="RFC3168" forma 2015, 14 years after the Classic ECN spec <xref target="RFC3168" forma
t="default"/> was published), it was believed that Classic ECN t="default"/> was published), it was believed that Classic ECN
AQMs had failed to be deployed, because research measurements had AQMs had failed to be deployed because research measurements had
found little or no evidence of CE marking. In subsequent years found little or no evidence of CE marking.
Classic ECN was included in per-flow-queuing (FQ) deployments, In subsequent years,
however an FQ scheduler stops an L4S flow outcompeting Classic, Classic ECN was included in FQ deployments;
however, an FQ scheduler stops an L4S flow outcompeting Classic,
because it enforces equality between flow rates. It is not known because it enforces equality between flow rates. It is not known
whether there have been any non-FQ deployments of Classic ECN AQMs whether there have been any non-FQ deployments of Classic ECN AQMs
in the subsequent years, or whether there will be in future.</t> in the subsequent years or whether there will be any in future.</t>
<t>An algorithm for detecting a Classic ECN AQM as soon <t>An algorithm for detecting a Classic ECN AQM as soon
as a flow stabilizes after start-up has been proposed <xref target="ec n-fallback" format="default"/> (see <xref target="l4sid_sec_fallback_on_classic_ CE" format="default"/> for a brief summary). as a flow stabilizes after start-up has been proposed <xref target="ec n-fallback" format="default"/> (see <xref target="l4sid_sec_fallback_on_classic_ CE" format="default"/> for a brief summary).
Testbed evaluations of v2 of the algorithm have shown detection is Testbed evaluations of v2 of the algorithm have shown detection is
reasonably good for Classic ECN AQMs, in a wide range of reasonably good for Classic ECN AQMs, in a wide range of
circumstances. However, although it can correctly detect an L4S ECN circumstances.
AQM in many circumstances, its is often incorrect at low link However, although it can correctly detect an L4S ECN
AQM in many circumstances, it is often incorrect at low link
capacities and/or high RTTs. Although this is the safe way round, capacities and/or high RTTs. Although this is the safe way round,
there is a danger that it will discourage use of the algorithm.</t> there is a danger that it will discourage use of the algorithm.</t>
</dd> </dd>
<dt>Non-L4S service for control packets:</dt> <dt>Non-L4S service for control packets:</dt>
<dd>Solely for the <dd>Solely for the
case of TCP, the Classic ECN RFCs <xref target="RFC3168" format="defau case of TCP, the Classic ECN RFCs <xref target="RFC3168" format="defau
lt"/> and lt"/> and
<xref target="RFC5562" format="default"/> require a sender to clear th <xref target="RFC5562" format="default"/> require a sender to clear th
e ECN field to e IP-ECN field to
Not-ECT on retransmissions and on certain control packets Not-ECT on retransmissions and on certain control packets,
specifically pure ACKs, window probes and SYNs. When L4S packets are specifically pure ACKs, window probes, and SYNs. When L4S packets are
classified by the ECN field, these TCP control packets would not be classified by the IP-ECN field, these TCP control packets would not be
classified into an L4S queue, and could therefore be delayed classified into an L4S queue and could therefore be delayed
relative to the other packets in the flow. This would not cause relative to the other packets in the flow. This would not cause
reordering (because retransmissions are already out of order, and reordering (because retransmissions are already out of order, and
these control packets typically carry no data). However, it would these control packets typically carry no data). However, it would
make critical TCP control packets more vulnerable to loss and delay. make critical TCP control packets more vulnerable to loss and delay.
To address this problem, ECN++ <xref target="I-D.ietf-tcpm-generalized -ecn" format="default"/> proposes an experiment in To address this problem, ECN++ <xref target="I-D.ietf-tcpm-generalized -ecn" format="default"/> proposes an experiment in
which all TCP control packets and retransmissions are ECN-capable as which all TCP control packets and retransmissions are ECN-capable as
long as appropriate ECN feedback is available in each case.</dd> long as appropriate ECN feedback is available in each case.</dd>
</dl> </dl>
<t>Pros:</t> <t>Pros:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Should work e2e:</dt> <dt>Should work end to end:</dt>
<dd>The ECN field generally propagates <dd>The IP-ECN field generally propagates
end-to-end across the Internet without being wiped or mangled, at end to end across the Internet without being wiped or mangled, at
least over fixed networks. Unlike the DSCP, the setting of the ECN least over fixed networks. Unlike the DSCP, the setting of the ECN
field is at least meant to be forwarded unchanged by networks that field is at least meant to be forwarded unchanged by networks that
do not support ECN.</dd> do not support ECN.</dd>
<dt>Should work in tunnels:</dt> <dt>Should work in tunnels:</dt>
<dd>The L4S identifiers work <dd>The L4S identifiers work
across and within any tunnel that propagates the ECN field in any of across and within any tunnel that propagates the IP-ECN field in any o f
the variant ways it has been defined since ECN-tunneling was first the variant ways it has been defined since ECN-tunneling was first
specified in the year 2001 <xref target="RFC3168" format="default"/>. However, specified in the year 2001 <xref target="RFC3168" format="default"/>. However,
it is likely that some tunnels still do not implement ECN it is likely that some tunnels still do not implement ECN
propagation at all.</dd> propagation at all.</dd>
<dt>Should work for many link technologies:</dt> <dt>Should work for many link technologies:</dt>
<dd>At most, but <dd>At most, but
not all, path bottlenecks there is IP-awareness, so that L4S AQMs not all, path bottlenecks there is IP awareness, so that L4S AQMs
can be located where the IP-ECN field can be manipulated. can be located where the IP-ECN field can be manipulated.
Bottlenecks at lower layer nodes without IP-awareness either have to Bottlenecks at lower-layer nodes without IP awareness have to either u
use drop to signal congestion or a specific congestion notification se
facility has to be defined for that link technology, including drop to signal congestion or have a specific congestion notification
facility defined for that link technology, including
propagation to and from IP-ECN. The programme to define these is propagation to and from IP-ECN. The programme to define these is
progressing and in each case so far the scheme already defined for progressing, and in each case so far, the scheme already defined for
ECN inherently supports L4S as well (see <xref target="l4sid_encaps_no _change" format="default"/>).</dd> ECN inherently supports L4S as well (see <xref target="l4sid_encaps_no _change" format="default"/>).</dd>
<dt>Could migrate to one codepoint:</dt> <dt>Could migrate to one codepoint:</dt>
<dd>If all Classic ECN <dd>If all Classic ECN
senders eventually evolve to use the L4S service, the ECT(0) senders eventually evolve to use the L4S service, the ECT(0)
codepoint could be reused for some future purpose, but only once use 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 of ECT(0) packets has reduced to zero, or near zero, which might
never happen.</dd> never happen.</dd>
<dt>L4 not required:</dt> <dt>L4 not required:</dt>
<dd>Being based on the ECN field, this <dd>Being based on the IP-ECN field, this
scheme does not need the network to access transport layer flow scheme does not need the network to access transport-layer flow
identifiers. Nonetheless, it does not preclude solutions that IDs. Nonetheless, it does not preclude solutions that
do.</dd> do.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Potential Competing Uses for the ECT(1) Codepoint</name> <name>Potential Competing Uses for the ECT(1) Codepoint</name>
<t>The ECT(1) codepoint of the ECN field has already been assigned once <t>The ECT(1) codepoint of the IP-ECN field has already been assigned once
for the ECN nonce <xref target="RFC3540" format="default"/>, which has now for the ECN nonce spec <xref target="RFC3540" format="default"/>, which ha
been s now been
categorized as historic <xref target="RFC8311" format="default"/>. ECN is categorized as Historic <xref target="RFC8311" format="default"/>. ECN is
probably probably
the only remaining field in the Internet Protocol that is common to IPv4 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 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 with lower layers. Therefore, ECT(1) should not be reassigned to a
different experimental use (L4S) without carefully assessing competing different experimental use (L4S) without carefully assessing competing
potential uses. These fall into the following categories:</t> potential uses.
These fall into the categories described below.</t>
<section anchor="l4sid_competing_integrity" numbered="true" toc="default"> <section anchor="l4sid_competing_integrity" numbered="true" toc="default">
<name>Integrity of Congestion Feedback</name> <name>Integrity of Congestion Feedback</name>
<t>Receiving hosts can fool a sender into downloading faster by <t>Receiving hosts can fool a sender into downloading faster by
suppressing feedback of ECN marks (or of losses if retransmissions are suppressing feedback of ECN marks (or of losses if retransmissions are
not necessary or available otherwise).</t> not necessary or available otherwise).</t>
<t>The historic ECN nonce protocol <xref target="RFC3540" format="defaul <t>The Historic ECN nonce spec <xref target="RFC3540" format="default"/>
t"/> proposed that a TCP sender could set either ECT(0) or ECT(1) in
proposed 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. If any each packet of a flow and remember the sequence it had set. If any
packet was lost or congestion marked, the receiver would miss that bit packet was lost or congestion marked, the receiver would miss that bit
of the sequence. An ECN Nonce receiver had to feed back the least of the sequence. An ECN nonce receiver had to feed back the least-signif
significant bit of the sum, so it could not suppress feedback of a icant
bit of the sum, so it could not suppress feedback of a
loss or mark without a 50-50 chance of guessing the sum loss or mark without a 50-50 chance of guessing the sum
incorrectly.</t> incorrectly.</t>
<t>It is highly unlikely that ECT(1) will be needed as a nonce for <t>It is highly unlikely that ECT(1) will be needed as a nonce for
integrity protection of congestion notifications in future. The ECN integrity protection of congestion notifications in future. The ECN
Nonce RFC <xref target="RFC3540" format="default"/> has been reclassifie nonce spec <xref target="RFC3540" format="default"/> has been reclassifi
d as ed as
historic, partly because other ways (that do not consume a codepoint Historic, partly because other ways (that do not consume a codepoint
in the IP header) have been developed to protect feedback integrity of in the IP header) have been developed to protect feedback integrity of
TCP and other transports <xref target="RFC8311" format="default"/>. For TCP and other transports <xref target="RFC8311" format="default"/>. For
instance:</t> instance:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the sender can test the integrity of a small random sample of <li>The sender can test the integrity of a small random sample of
the receiver's feedback by occasionally setting the IP-ECN field the receiver's feedback by occasionally setting the IP-ECN field
to a value normally only set by the network. Then it can test to a value normally only set by the network.
Then, it can test
whether the receiver's feedback faithfully reports what it expects whether the receiver's feedback faithfully reports what it expects
(see para 2 of Section 20.2 of the ECN spec <xref target="RFC3168" f (see Paragraph 2 of <xref target="RFC3168" sectionFormat="of" sectio
ormat="default"/>. This works for loss and it will work for the n="20.2">the ECN spec</xref>. This works for loss, and it will work for the
accurate ECN feedback <xref target="RFC7560" format="default"/> inte accurate ECN feedback <xref target="RFC7560" format="default"/> inte
nded for nded for
L4S. Like the (historic) ECN nonce, this technique does not L4S. Like the (Historic) ECN nonce spec, this technique does not
protect against a misbehaving sender. But it allows a well-behaved protect against a misbehaving sender. But it allows a well-behaved
sender to check that each receiver is correctly feeding back sender to check that each receiver is correctly feeding back
congestion notifications.</li> congestion notifications.</li>
<li>A network can check that its ECN markings (or packet losses) <li>A network can check that its ECN markings (or packet losses)
have been passed correctly round the full feedback loop by have been passed correctly around the full feedback loop by
auditing congestion exposure (ConEx) <xref target="RFC7713" format=" auditing Congestion Exposure (ConEx) <xref target="RFC7713" format="
default"/>. This assures that the integrity of congestion default"/>. This assures that the integrity of congestion
notifications and feedback messages must have both been preserved. notifications and feedback messages must have both been preserved.
ConEx information is also available anywhere along the network ConEx information is also available anywhere along the network
path, so it can be used to enforce a congestion response. Whether path, so it can be used to enforce a congestion response. Whether
the receiver or a downstream network is suppressing congestion the receiver or a downstream network is suppressing congestion
feedback or the sender is unresponsive to the feedback, or both, feedback or the sender is unresponsive to the feedback, or both,
ConEx is intended to neutralise any advantage that any of these ConEx is intended to neutralize any advantage that any of these
three parties would otherwise gain.</li> three parties would otherwise gain.</li>
<li>Congestion feedback fields in transport layer headers are <li>Congestion feedback fields in transport-layer headers are
immutable end-to-end, and therefore amenable to end-to-end immutable end to end and therefore amenable to end-to-end
integrity protection. This preserves the integrity of a receiver's integrity protection. This preserves the integrity of a receiver's
feedback messages to the sender, but it does not protect against feedback messages to the sender, but it does not protect against
misbehaving receivers or misbehaving senders. The TCP misbehaving receivers or misbehaving senders. The TCP
authentication option (TCP-AO <xref target="RFC5925" format="default Authentication Option (TCP-AO) <xref target="RFC5925" format="defaul
"/>), t"/>,
QUIC's end-to-end protection <xref target="RFC9001" format="default" QUIC's end-to-end protection <xref target="RFC9001" format="default"
/> or />, or
end-to-end IPsec integrity protection <xref target="RFC4303" format= "default"/> can end-to-end IPsec integrity protection <xref target="RFC4303" format= "default"/> can
be used to detect any tampering with congestion feedback (whether be used to detect any tampering with congestion feedback (whether
malicious or accidental). respectively in TCP, QUIC or any malicious or accidental), respectively, in TCP, QUIC, or any
transport. TCP-AO covers the main TCP header and TCP options by transport. TCP-AO covers the main TCP header and TCP options by
default, but it is often too brittle to use on many end-to-end default, but it is often too brittle to use on many end-to-end
paths, where middleboxes can make verification fail in their paths, where middleboxes can make verification fail in their
attempts to improve performance or security, e.g. by attempts to improve performance or security, e.g., by
resegmentation or shifting the sequence space.</li> resegmentation or shifting the sequence space.</li>
</ul> </ul>
<t>At the time of writing, It is not common to protect the <t>At the time of writing, it is becoming common to protect the
integrity of congestion feedback, whether loss or Classic ECN. If this integrity of transport feedback using QUIC. However, it is still not
position changes during the L4S experiment, one or more of the above common to protect the integrity of the wider congestion feedback loop,
techniques might need to be developed and deployed.</t> whether based on loss or Classic ECN. If this position changes during
the L4S experiment, one or more of the above techniques might need to
be developed and deployed.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Notification of Less Severe Congestion than CE</name> <name>Notification of Less Severe Congestion than CE</name>
<t>Various researchers have proposed to use ECT(1) as a less severe <t>Various researchers have proposed to use ECT(1) as a less severe
congestion notification than CE, particularly to enable flows to fill congestion notification than CE, particularly to enable flows to fill
available capacity more quickly after an idle period, when another available capacity more quickly after an idle period, when another
flow departs or when a flow starts, e.g. VCP <xref target="VCP" format=" default"/>, Queue View (QV) <xref target="QV" format="default"/>.</t> flow departs or when a flow starts, e.g., the Variable-structure congest ion Control Protocol (VCP) <xref target="VCP" format="default"/> and Queue View (QV) <xref target="QV" format="default"/>.</t>
<t>Before assigning ECT(1) as an identifier for L4S, we must carefully <t>Before assigning ECT(1) as an identifier for L4S, we must carefully
consider whether it might be better to hold ECT(1) in reserve for consider whether it might be better to hold ECT(1) in reserve for
future standardisation of rapid flow acceleration, which is an future standardization of rapid flow acceleration, which is an
important and enduring problem <xref target="RFC6077" format="default"/> important and enduring problem <xref target="RFC6077" format="default"/>
.</t> .</t>
<t>Pre-Congestion Notification (PCN) is another scheme that assigns <t>Pre-Congestion Notification (PCN) is another scheme that assigns
alternative semantics to the ECN field. It uses ECT(1) to signify a alternative semantics to the IP-ECN field. It uses ECT(1) to signify a
less severe level of pre-congestion notification than CE <xref target="R less severe level of pre-congestion notification than CE <xref target="R
FC6660" format="default"/>. However, the ECN field only takes on the PCN FC6660" format="default"/>. However, the IP-ECN field only takes on the PCN
semantics if packets carry a Diffserv codepoint defined to indicate semantics if packets carry a Diffserv codepoint defined to indicate
PCN marking within a controlled environment. PCN is required to be PCN marking within a controlled environment. PCN is required to be
applied solely to the outer header of a tunnel across the controlled 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 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 field. Therefore, a PCN region on the path would not interfere with
the L4S service identifier defined in <xref target="l4sid_identification " format="default"/>.</t> the L4S service identifier defined in <xref target="l4sid_identification " format="default"/>.</t>
</section> </section>
</section> </section>
<!-- <section title="Change Log (to be Deleted before Publication)">
<t>A detailed version history can be accessed at
&lt;http://datatracker.ietf.org/doc/draft-briscoe-aqm-ecn-roadmap/history/
&gt;</t>
<t><list style="hanging"> <section numbered="false" toc="default"> <name>Acknowledgements</name>
<t hangText="From briscoe-...-00 to briscoe-...-01:">Technical <t>Thanks to <contact fullname="Richard Scheffenegger"/>, <contact
changes:<list style="symbols"> fullname="John Leslie"/>, <contact fullname="David Täht"/>, <contact
<t/> fullname="Jonathan Morton"/>, <contact fullname="Gorry Fairhurst"/>,
</list>Editorial changes:<list style="symbols"> <contact fullname="Michael Welzl"/>, <contact fullname="Mikael
<t/> Abrahamsson"/>, and <contact fullname="Andrew McGregor"/> for the
</list></t> discussions that led to this specification. <contact fullname="Ing-jyh
</list></t> (Inton) Tsang"/> was a contributor to the early draft versions of this
</section> document. Thanks to <contact fullname="Mikael Abrahamsson"/>, <contact
fullname="Lloyd Wood"/>, <contact fullname="Nicolas Kuhn"/>, <contact
fullname="Greg White"/>, <contact fullname="Tom Henderson"/>, <contact
fullname="David Black"/>, <contact fullname="Gorry Fairhurst"/>, <contact
fullname="Brian Carpenter"/>, <contact fullname="Jake Holland"/>, <contact
fullname="Rod Grimes"/>, <contact fullname="Richard Scheffenegger"/>,
<contact fullname="Sebastian Moeller"/>, <contact fullname="Neal
Cardwell"/>, <contact fullname="Praveen Balasubramanian"/>, <contact
fullname="Reza Marandian Hagh"/>, <contact fullname="Pete Heist"/>,
<contact fullname="Stuart Cheshire"/>, <contact fullname="Vidhi Goel"/>,
<contact fullname="Mirja Kühlewind"/>, <contact fullname="Ermin Sakic"/>,
and <contact fullname="Martin Duke"/> for providing help and reviewing
this document. And thanks to <contact fullname="Ingemar Johansson"/> for
reviewing and providing substantial text. Thanks also to the area
reviewers: <contact fullname="Valery Smyslov"/>, <contact fullname="Maria
Ines Robles"/>, <contact fullname="Bernard Aboba"/>, <contact
fullname="Lars Eggert"/>, <contact fullname="Roman Danyliw"/>, and <contact
fullname="Éric Vyncke"/>. Thanks to <contact fullname="Sebastian
Moeller"/> for identifying the interaction with VPN anti-replay and to
<contact fullname="Jonathan Morton"/> for identifying the attack based on
this. Particular thanks to tsvwg chairs <contact fullname="Gorry
Fairhurst"/>, <contact fullname="David Black"/>, and <contact fullname="Wes
Eddy"/> for patiently helping this and the other L4S documents through the
IETF process. <xref target="l4sps_tcp-prague-reqs" format="default"/>, which
lists the Prague L4S Requirements, is based on text authored by <contact
fullname="Marcelo Bagnulo Braun"/> that was originally an appendix to
<xref target="RFC9330" format="default"/>. That text was in turn based on
the collective output of the attendees listed in the minutes of a 'bar
BoF' on DCTCP Evolution during IETF 94 <xref target="TCPPrague"
format="default"/>.</t>
<t>The authors' contributions were partly funded by
the European Community under its Seventh Framework Programme through the
Reducing Internet Transport Latency (RITE) project (ICT-317700). The
contribution of <contact fullname="Koen De Schepper"/> was also
partly funded by the 5Growth and DAEMON EU H2020 projects. <contact
fullname="Bob Briscoe"/> was partly funded by the Research Council of
Norway through the TimeIn project, CableLabs, and the
Comcast Innovation Fund. The views expressed here are solely those of the
authors.</t>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to Richard Scheffenegger, John Leslie, David Taeht,
Jonathan Morton, Gorry Fairhurst, Michael Welzl, Mikael Abrahamsson and
Andrew McGregor for the discussions that led to this specification.
Ing-jyh (Inton) Tsang was a contributor to the early drafts of this
document. And thanks to Mikael Abrahamsson, Lloyd Wood, Nicolas Kuhn,
Greg White, Tom Henderson, David Black, Gorry Fairhurst, Brian
Carpenter, Jake Holland, Rod Grimes, Richard Scheffenegger, Sebastian
Moeller, Neal Cardwell, Praveen Balasubramanian, Reza Marandian Hagh,
Pete Heist, Stuart Cheshire, Vidhi Goel, Mirja Kuehlewind, Ermin
Sakic and Martin Duke for providing help and reviewing this draft, and
thanks to Ingemar Johansson for reviewing and providing substantial
text. Thanks also to the area reviewers: Valery Smyslov, Maria Ines
Robles, Bernard Aboba, Lars Eggert, Roman Danyliw and Eric Vyncke.
Thanks to Sebastian Moeller for identifying the interaction with VPN
anti-replay and to Jonathan Morton for identifying the attack based on
this. Particular thanks to tsvwg chairs Gorry Fairhurst, David Black and
Wes Eddy for patiently helping this and the other L4S drafts through the
IETF process. <xref target="l4sps_tcp-prague-reqs" format="default"/> list
ing the Prague
L4S Requirements is based on text authored by Marcelo Bagnulo Braun that
was originally an appendix to <xref target="I-D.ietf-tsvwg-l4s-arch" forma
t="default"/>.
That text was in turn based on the collective output of the attendees
listed in the minutes of a 'bar BoF' on DCTCP Evolution during
IETF-94 <xref target="TCPPrague" format="default"/>.</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 contribution of Koen
De Schepper was also part-funded by the 5Growth and DAEMON EU H2020
projects. Bob Briscoe was also funded partly by the Research Council of
Norway through the TimeIn project, partly by CableLabs and partly by the
Comcast Innovation Fund. The views expressed here are solely those of
the authors.</t>
</section> </section>
</back>
</back>
</rfc> </rfc>
 End of changes. 537 change blocks. 
3305 lines changed or deleted 1766 lines changed or added

This html diff was produced by rfcdiff 1.48.