<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!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" submissionType="IETF" category="exp" consensus="true" docName="draft-ietf-tsvwg-ecn-l4s-id-29" number="9331" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" 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 ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
       full title is longer than 39 characters -->
    <title abbrev="L4S ECN abbrev="ECN Protocol for V Low Queuing Delay">Explicit L4S">
   The Explicit Congestion Notification (ECN) Protocol for Very
   Low Queuing Delay Latency, Low Loss, and Scalable Throughput (L4S)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-ecn-l4s-id-29"/> name="RFC" value="9331"/>
    <author fullname="Koen De Schepper" initials="K." surname="De Schepper">
      <organization>Nokia Bell Labs</organization>
      <address>
        <postal>
          <street/>
          <city>Antwerp</city>
          <country>Belgium</country>
        </postal>
        <email>koen.de_schepper@nokia.com</email>
        <uri>https://www.bell-labs.com/about/researcher-profiles/koende_schepper/</uri>
      </address>
    </author>
    <author fullname="Bob Briscoe" initials="B." role="editor" surname="Briscoe"> surname="Briscoe" role="editor">
      <organization>Independent</organization>
      <address>
        <postal>
          <street/>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>ietf@bobbriscoe.net</email>
        <uri>https://bobbriscoe.net/</uri>
      </address>
    </author>
    <!--
    <author fullname="Olga Bondarenko" initials="O." surname="Bondarenko">
      <organization>Simula Research Lab</organization>

      <address>
        <postal>
          <street/>

          <city>Lysaker</city>

          <country>Norway</country>
        </postal>

        <email>olgabnd@gmail.com</email>

        <uri>https://www.simula.no/people/olgabo</uri>
      </address>
    </author>
-->

    <!--
    <author fullname="Ing-jyh Tsang" initials="I." surname="Tsang">
      <organization>Nokia Bell Labs</organization>

      <address>
        <postal>
          <street/>

          <city>Antwerp</city>

          <country>Belgium</country>
        </postal>

        <email>ing-jyh.tsang@nokia.com</email>
      </address>
    </author>
-->
    <date year=""/>
    <area>Transport</area>
    <workgroup>Transport Services (tsv)</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>I-D</keyword> year="2023" month="January" />
    <area>tsv</area>
    <workgroup>tsvwg</workgroup>
  <keyword>Performance</keyword>
  <keyword>Queuing Delay</keyword>
  <keyword>One Way Delay</keyword>
  <keyword>Round-Trip Time</keyword>
  <keyword>RTT</keyword>
  <keyword>Jitter</keyword>
  <keyword>Congestion Control</keyword>
  <keyword>Congestion Avoidance</keyword>
  <keyword>Quality of Service</keyword>
  <keyword>QoS</keyword>
  <keyword>Quality of Experience</keyword>
  <keyword>QoE</keyword>
  <keyword>Active Queue Management</keyword>
  <keyword>AQM</keyword>
  <keyword>Explicit Congestion Notification</keyword>
  <keyword>ECN</keyword>
  <keyword>Burstiness</keyword>

    <abstract>
      <t>This specification defines the protocol to be used for a new network
      service called low latency, low loss Low Latency, Low Loss, and scalable Scalable throughput (L4S). L4S
      uses an Explicit Congestion Notification (ECN) scheme at the IP layer
      that is similar to the original (or 'Classic') ECN approach, except as
      specified within. L4S uses 'scalable' 'Scalable' congestion control, which induces
      much more frequent control signals from the network network, and it responds to
      them with much more fine-grained adjustments, adjustments so that very low
      (typically sub-millisecond on average) and consistently low queuing
      delay becomes possible for L4S traffic without compromising link
      utilization. Thus Thus, even capacity-seeking (TCP-like) traffic can have high
      bandwidth and very low delay at the same time, even during periods of
      high traffic load.</t>
      <t>The L4S identifier defined in this document distinguishes L4S from
      'Classic' (e.g. TCP-Reno-friendly) (e.g., TCP-Reno-friendly) traffic. Then, network
      bottlenecks can be incrementally modified to distinguish and isolate
      existing traffic that still follows the Classic behaviour, to prevent it
      from degrading the low queuing delay and low loss of L4S traffic. This
      experimental track
      Experimental specification defines the rules that L4S transports
      and network elements need to follow, with the intention that L4S flows
      neither harm each other's performance nor that of Classic traffic. It
      also suggests open questions to be investigated during experimentation.
      Examples of new active queue management Active Queue Management (AQM) marking algorithms and
      examples of
      new transports (whether TCP-like or real-time) real time) are specified
      separately.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="l4sid_intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This experimental track Experimental specification defines the protocol to be used
      for a new network service called low latency, low loss Low Latency, Low Loss, and scalable Scalable
      throughput (L4S). L4S uses an Explicit Congestion Notification (ECN)
      scheme at the IP layer with the same set of codepoint transitions as the
      original (or 'Classic') Explicit Congestion Notification (ECN <xref ECN <xref target="RFC3168" format="default"/>). RFC 3168 required format="default"/>. <xref target="RFC3168"/> requires an ECN mark to be equivalent
      to a drop, both when applied in the network and when responded to by a
      transport. Unlike Classic ECN marking: marking, i) the network applies L4S
      marking more immediately and more frequently than drop; drop and ii) the
      transport response to each mark is reduced and smoothed relative to that
      for drop. The two changes counterbalance each other so that the
      throughput of an L4S flow will be roughly the same as a comparable
      non-L4S flow under the same conditions. Nonetheless, the much more
      frequent ECN control signals and the finer responses to these signals
      result in very low queuing delay without compromising link utilization,
      and this low delay can be maintained during high load. For instance,
      queuing delay under heavy and highly varying load with the example
      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
      percentile without losing link utilization <xref target="DualPI2Linux" format="default"/>, utilization <xref target="DCttH19" target="L4Seval22" format="default"/> <xref target="DualPI2Linux" format="default"/>.
      Note that the queuing
      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
      addressed, but separately (see section 6.3 Section <xref target="RFC9330" section="6.3"
sectionFormat="bare"/> of the L4S
      architecture <xref target="I-D.ietf-tsvwg-l4s-arch"
      architecture <xref target="RFC9330" format="default"/>).</t>
      <t>L4S relies on 'scalable' 'Scalable' congestion controls for these delay
      properties and for preserving low delay as flow rate scales, hence the
      name. The congestion control used in Data Center TCP (DCTCP) is an
      example of a scalable Scalable congestion control, but DCTCP is applicable solely
      to controlled environments like data centres <xref centres <xref target="RFC8257" format="default"/>, because it is too aggressive to co-exist coexist with
      existing TCP-Reno-friendly traffic. The DualQ Dual-Queue Coupled AQM, which is
      defined in a complementary experimental specification <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" Experimental specification <xref target="RFC9332" format="default"/>, is an AQM framework that
      enables scalable Scalable congestion controls derived from DCTCP to co-exist coexist with
      existing traffic, each getting roughly the same flow rate when they
      compete under similar conditions. Note that a scalable Scalable congestion
      control is still not safe to deploy on the Internet unless it satisfies
      the requirements listed in <xref target="l4sid_transport_req" format="default"/>.</t>

      <t>L4S is not only for elastic (TCP-like) traffic - -- there are scalable Scalable
      congestion controls for real-time media, such as the L4S variant <xref target="SCReAM-L4S" format="default"/> of the SCReAM <xref SCReAM <xref target="RFC8298" format="default"/>
      real-time media congestion avoidance technique RTP Media Congestion Avoidance Techniques (RMCAT). The factor that
      distinguishes L4S from Classic traffic is its behaviour in response to
      congestion.
      The transport wire protocol, e.g. TCP, e.g., TCP, QUIC, SCTP,
      DCCP, the Stream Control Transmission Protocol (SCTP),
      the Datagram Congestion Control Protocol (DCCP), or RTP/RTCP, is orthogonal (and therefore not suitable for
      distinguishing L4S from Classic packets).</t>
      <t>The L4S identifier defined in this document is the key piece that
      distinguishes L4S from 'Classic' (e.g. Reno-friendly) (e.g., Reno-friendly) traffic.
      Then, network bottlenecks can be incrementally modified to distinguish
      and isolate existing Classic traffic from L4S traffic, to prevent the
      former from degrading the very low queuing delay and loss of the new
      scalable
      Scalable transports, without harming Classic performance at these
      bottlenecks. Although both sender and network deployment are required
      before any benefit, initial implementations of the separate parts of the
      system have been motivated by the potential performance benefits.</t>
      <section anchor="l4sid_problem" numbered="true" toc="default">
        <name>Latency, Loss Loss, and Scaling Problems</name>

        <t>Latency is becoming the critical performance factor for many
        (most?)
        (perhaps most) Internet applications, e.g. interactive e.g., interactive web, web
        services, voice, conversational video, interactive video, interactive
        remote presence, instant messaging, online gaming, remote desktop,
        cloud-based applications &amp; services, and remote control of
        machinery and industrial processes. In many parts of the world,
        further increases in access network bit rate bitrate offer diminishing returns
        <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
        placing caches or servers closer to users. However, queuing remains a
        major, albeit intermittent, component of latency.</t>
        <t>The Diffserv architecture provides Expedited Forwarding <xref Forwarding (EF) <xref target="RFC3246" format="default"/>, format="default"/> so that low latency low-latency traffic can jump the queue of
        other traffic. If growth in latency-sensitive applications continues,
        periods with solely latency-sensitive traffic will become increasingly
        common on links where traffic aggregation is low. During these
        periods, if all the traffic were marked for the same treatment,
        Diffserv would make no difference. The links with low aggregation also
        tend to become the path bottleneck under load, for instance, the
        access links dedicated to individual sites (homes, small enterprises enterprises,
        or mobile devices). So, instead of differentiation, it becomes
        imperative to remove the underlying causes of any unnecessary
        delay.</t>
        <t>The Bufferbloat project has shown that excessively-large excessively large buffering
        ('bufferbloat') has been introducing significantly more delay than the
        underlying propagation time <xref target="Bufferbloat" format="default"/>. These delays
        appear only intermittently -- only when a capacity-seeking
        (e.g. TCP)
        (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
        its way through the queue.</t>
        <t>Active queue management (AQM)

        <t>AQM was originally developed to solve
        this problem (and others). Unlike Diffserv, which gives low latency to
        some traffic at the expense of others, AQM controls latency for <em>all</em> traffic in a class. In general, AQM methods
        introduce an increasing level of discard from the buffer, the longer
        the queue persists above a shallow threshold.
        This gives sufficient
        signals to capacity-seeking (aka. greedy) (a.k.a. greedy) flows to keep the
        buffer empty for its intended purpose: absorbing bursts.
	However,
        RED <xref target="RFC2309" format="default"/> Random Early Detection (RED) and other algorithms from the 1990s
        were sensitive to their configuration and hard to set correctly. So, correctly <xref target="RFC7567" format="default"/>. So
        this form of AQM was not widely deployed.</t>

        <t>More recent state-of-the-art AQM methods, such
        as FQ-CoDel <xref
        as Flow Queue CoDel <xref target="RFC8290" format="default"/>, PIE <xref Proportional Integral controller Enhanced (PIE) <xref target="RFC8033" format="default"/> format="default"/>, or Adaptive RED <xref RED <xref target="ARED01" format="default"/>, are
        easier to configure, because they define the queuing threshold in time
        not bytes, so configuration is invariant whatever the link rate.
        However, the sawtoothing window of a Classic congestion control
        creates a dilemma for the operator: i) either i) configure a shallow AQM
        operating point, point so the tips of the sawteeth cause minimal queue
        delay, but then the troughs underutilize the link; link, or ii) configure the
        operating point deeper into the buffer, buffer so the troughs utilize the
        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
        sawteeth will be of the same order as the underlying base round trip round-trip
        time (RTT), thereby roughly doubling the total round-trip time.</t> RTT.</t>
        <t>If a sender's own behaviour is introducing queuing delay variation,
        no AQM in the network can 'un-vary' the delay without significantly
        compromising link utilization. Even flow-queuing (e.g. <xref flow queuing (e.g., <xref target="RFC8290" format="default"/>), which isolates one flow from another, cannot
        isolate a flow from the delay variations it inflicts on itself.
        Therefore, those applications that need to seek out high bandwidth but
        also need low latency will have to migrate to scalable Scalable congestion
        control, which uses much smaller sawtooth variations.</t>
        <t>Altering host behaviour is not enough on its own though. Even if
        hosts adopt low latency scalable low-latency Scalable congestion controls, they need to be
        isolated from the large queue variations induced by existing Classic
        congestion controls. L4S AQMs provide that latency isolation in the
        network
        network, and the L4S identifier enables the AQMs to distinguish the two
        types of packet packets that need to be isolated: L4S and Classic. L4S
        isolation can be achieved with a queue per flow (e.g. <xref (e.g., <xref target="RFC8290" format="default"/>) format="default"/>), but a DualQ <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" DualQ <xref target="RFC9332" format="default"/> is sufficient, sufficient and
        actually gives better tail latency <xref latency <xref target="DCttH19" format="default"/>. Both
        approaches are addressed in this document.</t>

        <t>The DualQ solution was developed to make very low latency available
        without requiring per-flow queues at every bottleneck. This was useful
        because per-flow-queuing per-flow queuing (FQ) has well-known downsides - -- not least the
        need to inspect transport layer transport-layer headers in the network, which makes it
        incompatible with privacy approaches such as IPSec VPN tunnels, IPsec Virtual Private Network (VPN) tunnels and
        incompatible with link layer link-layer queue management, where transport layer transport-layer
        headers can be hidden, e.g. 5G.</t> e.g., 5G.</t>
        <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
        to high bandwidth-delay products (footnote (see footnote 6 of Jacobson and
        Karels <xref
        Karels <xref target="TCP-CA" format="default"/>).
        Given that Reno congestion control is already beyond its scaling range at
        regular broadband
        bit-rates bitrates over WAN distances are already <xref <xref target="RFC3649" format="default"/>
        beyond the scaling range of Reno congestion control, format="default"/>, 'less unscalable'
        Cubic <xref
        CUBIC <xref target="RFC8312" format="default"/> and Compound <xref Compound <xref target="I-D.sridharan-tcpm-ctcp" format="default"/> variants of TCP have been
        successfully deployed. However, these are now approaching their
        scaling limits. Unfortunately, fully scalable Scalable congestion controls such
        as DCTCP <xref DCTCP <xref target="RFC8257" format="default"/> outcompete Classic ECN
        congestion controls sharing the same queue, which is why they have
        been confined to private data centres or research testbeds.</t>
        <t>It turns out that these scalable Scalable congestion control algorithms that
        solve the latency problem can also solve the scalability problem of
        Classic congestion controls. The finer sawteeth in the congestion
        window (cwnd) have low amplitude, so they cause very little queuing delay
        variation
        variation, and the average time to recover from one congestion signal
        to the next (the average duration of each sawtooth) remains invariant,
        which maintains constant tight control as flow-rate flow rate scales. A
        background paper <xref target="DCttH19" paper <xref target="L4Seval22" format="default"/> gives the full
        explanation of why the design solves both the latency and the scaling
        problems, both in plain English and in more precise mathematical form.
        The explanation is summarized without the mathematics in Section 4 <xref target="RFC9330" section="4"
sectionFormat="bare"/> of
        the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" architecture <xref target="RFC9330" format="default"/>.</t>
      </section>
      <section anchor="l4sid_Terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
        <t>[Note to the RFC Editor (to be removed before publication as an
        RFC): The L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" format="default"/> repeats the following definitions,
        which should be identical, except in the architecture Classic CC and
        Scalable CC are condensed because they refer to a section later in the
        architecture.]</t> here.
        </t>
        <dl newline="false" spacing="normal">
          <dt>Classic Congestion Control:</dt>
          <dd>A congestion control
            behaviour that can co-exist coexist with standard Reno <xref Reno <xref target="RFC5681" format="default"/> without causing significantly negative impact
            on its flow rate <xref rate <xref target="RFC5033" format="default"/>. With Classic
            congestion controls, such as Reno or Cubic, CUBIC, because flow rate has
            scaled since TCP congestion control was first designed in 1988, it
            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
            examples in section 5.1 Section <xref target="RFC9330" section="5.1"
sectionFormat="bare"/> of the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" architecture <xref target="RFC9330" format="default"/> and in <xref target="RFC3649" format="default"/>. Therefore, control of queuing and utilization
            becomes very slack, and the slightest disturbances (e.g. from (e.g., from
            new flows starting) prevent a high rate from being attained.</dd>
          <dt>Scalable Congestion Control:</dt>
          <dd>A congestion control
            where the average time from one congestion signal to the next (the
            recovery time) remains invariant as the flow rate scales, all
            other factors being equal. This maintains the same degree of
            control over queueing queuing and utilization whatever the flow rate, as
            well as ensuring that high throughput is robust to disturbances.
            For instance, DCTCP averages 2 congestion signals per round-trip round trip,
            whatever the flow rate, as do other recently developed scalable Scalable
            congestion controls, e.g. Relentless TCP <xref e.g., Relentless TCP <xref target="I-D.mathis-iccrg-relentless-tcp" format="default"/>, TCP Prague for TCP and QUIC <xref target="I-D.briscoe-iccrg-prague-congestion-control" format="default"/>, format="default"/> <xref target="PragueLinux" format="default"/>, BBRv2 the L4S ECN
   part of Bottleneck Bandwidth and Round-trip propagation time
   (BBRv2) <xref target="BBRv2" format="default"/>, format="default"/> <xref target="I-D.cardwell-iccrg-bbr-congestion-control" format="default"/> format="default"/>, and the L4S
            variant of SCREAM SCReAM for real-time media <xref media <xref target="SCReAM-L4S" format="default"/>, <xref format="default"/> <xref target="RFC8298" format="default"/>. See <xref target="l4sid_congestion_response" format="default"/> for more explanation.</dd>
          <dt>Classic service:</dt> Service:</dt>
          <dd>The Classic service is intended for
            all the congestion control behaviours
	    that co-exist coexist with
            Reno <xref Reno <xref target="RFC5681" format="default"/> (e.g. Reno (e.g., Reno itself,
            Cubic <xref
            CUBIC <xref target="RFC8312" format="default"/>, Compound <xref Compound <xref target="I-D.sridharan-tcpm-ctcp" format="default"/>, TFRC <xref and TFRC <xref target="RFC5348" format="default"/>). The term 'Classic queue' means a queue
            providing the Classic service.</dd>
          <dt>Low-Latency, Low-Loss
          <dt>Low Latency, Low Loss, and Scalable throughput (L4S) service:</dt>
          <dd>
            <t>The
            'L4S' service is intended for traffic from scalable Scalable congestion
            control algorithms, such as the Prague congestion control <xref target="I-D.briscoe-iccrg-prague-congestion-control" format="default"/>, which was
            derived from DCTCP <xref DCTCP <xref target="RFC8257" format="default"/>.
            The L4S service
            is for more general traffic than just Prague -- it allows the
            set of congestion controls with similar scaling properties to
            Prague to evolve, such as the examples listed above (Relentless,
            SCReAM, etc.). The term 'L4S queue' means a queue providing the
            L4S service.</t>
            <t>The terms Classic or L4S can
            also qualify other nouns, such as 'queue', 'codepoint',
            'identifier', 'classification', 'packet', and 'flow'. For example: example, an
            L4S packet means a packet with an L4S identifier sent from an L4S
            congestion control.</t>
            <t>Both Classic and L4S
            services can cope with a proportion of unresponsive or
            less-responsive traffic as well, but well but, in the L4S case case, its rate has
            to be smooth enough or low enough not to not build a queue
            (e.g. DNS, VoIP,
            (e.g., DNS, Voice over IP (VoIP), game sync datagrams, etc.).</t>
          </dd>
          <dt>Reno-friendly:</dt>
          <dd>The subset of Classic traffic that is
            friendly to the standard Reno congestion control defined for TCP
            in <xref target="RFC5681" format="default"/>. The TFRC spec <xref spec <xref target="RFC5348" format="default"/> indirectly implies that 'friendly' is defined
            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
            place of 'TCP-friendly', given the latter has become imprecise,
            because the TCP protocol is now used with so many different
            congestion control behaviours, and Reno can be is used in non-TCP
            transports
            transports, such as QUIC <xref QUIC <xref target="RFC9000" format="default"/>.</dd>
          <dt>Classic ECN:</dt>
          <dd>The
          <dd><t>The original Explicit Congestion Notification (ECN) protocol <xref protocol <xref target="RFC3168" format="default"/>, which format="default"/> that
            requires ECN signals to be treated the same as equivalent to drops, both when
            generated in the network and when responded to by the sender. For sender.</t>

	    <t>For L4S, the names used for the
	    four codepoints of the 2-bit IP-ECN field are unchanged from those
	    defined in the ECN spec <xref target="RFC3168" format="default"/>: Not ECT, format="default"/>, i.e., Not-ECT,
	    ECT(0), ECT(1) ECT(1), and CE, where ECT stands for ECN-Capable
	    Transport and CE stands for Congestion Experienced. A packet
	    marked with the CE codepoint is termed 'ECN-marked' or sometimes
	    just 'marked' where the context makes ECN obvious.</dd> obvious.</t></dd>
          <dt>Site:</dt>
          <dd>A home, mobile device, small enterprise enterprise, or
            campus,
            campus where the network bottleneck is typically the access link
            to the site. Not all network arrangements fit this model model, but it is
            a useful, widely applicable generalization.</dd>
        </dl>
      </section>
      <section numbered="true" toc="default">
        <name>Scope</name>

        <t>The new L4S identifier defined in this specification is applicable
        for IPv4 and IPv6 packets (as for is Classic ECN <xref ECN <xref target="RFC3168" format="default"/>). It is applicable for the unicast, multicast multicast, and
        anycast forwarding modes.</t>
        <t>The L4S identifier is an orthogonal packet classification to the
        Differentiated Services Code Point (DSCP) <xref (DSCP) <xref target="RFC2474" format="default"/>. <xref target="l4sid_other_IDs" format="default"/> explains what
        this means in practice.</t>
        <t>This document is intended for experimental status, Experimental, so it does not
        update any standards track Standards Track RFCs. Therefore, it depends on <xref target="RFC8311" format="default"/>, which is a standards track Standards Track specification
        that:</t>
        <ul spacing="normal">
          <li>updates the ECN proposed standard <xref Proposed Standard <xref target="RFC3168" format="default"/>
            to allow experimental track Experimental RFCs to relax the requirement that an
            ECN mark must be equivalent to a drop (when the network applies
            markings and/or when the sender responds to them).
            For instance,
            in the ABE experiment <xref Alternative Backoff with ECN (ABE) experiment <xref target="RFC8511" format="default"/> format="default"/>, this relaxation permits a
            sender to respond less to ECN marks than to drops;</li>
          <li>changes the status of the experimental Experimental ECN nonce <xref nonce spec <xref target="RFC3540" format="default"/> to historic;</li> Historic; and</li>
          <li>
            <t>makes consequent updates to the following additional proposed
            standard Proposed
            Standard RFCs to reflect the above two bullets:</t>
            <ul spacing="normal">
              <li>ECN for RTP <xref RTP <xref target="RFC6679" format="default"/>;</li> format="default"/> and </li>
              <li>the congestion control specifications of various DCCP
                congestion control identifier
                Congestion Control Identifier (CCID) profiles <xref profiles <xref target="RFC4341" format="default"/>, format="default"/> <xref target="RFC4342" format="default"/>, format="default"/> <xref target="RFC5622" format="default"/>.</li>
            </ul>
          </li>
        </ul>
        <t>This document is about identifiers that are used for interoperation
        between hosts and networks. So the audience is broad, covering
        developers of host transports and network AQMs, as well as covering
        how operators might wish to combine various identifiers, which would
        require flexibility from equipment developers.</t>
      </section>
    </section>
    <section anchor="l4sid_identification" numbered="true" toc="default">
      <name>L4S Packet Identification: Document Roadmap</name>
      <t>The L4S ECN marking treatment is an experimental track alternative packet marking
      treatment
      to the Classic ECN treatment in <xref target="RFC3168" format="default"/>,
      which has been updated by <xref target="RFC8311" format="default"/> to allow experiments
      such as the one defined in the present specification. <xref target="RFC4774" format="default"/> discusses some of the issues and evaluation criteria
      when defining alternative ECN semantics, which are further discussed in
      <xref target="l4sid_congestion_response_rfcs" format="default"/>.</t>
      <t>The L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" target="RFC9330" format="default"/>
      describes the three main components of L4S: the sending host behaviour,
      the marking behaviour in the network network, and the L4S ECN protocol that
      identifies L4S packets as they flow between the two.</t>
      <t>The next section

      <t><xref target="l4sid_reqs" format="default"/> of the present this document (<xref target="l4sid_reqs" format="default"/>) records the requirements that informed the choice
      of L4S identifier. Then Then, subsequent sections specify the L4S ECN
      protocol, which i) identifies packets that have been sent from hosts
      that are expected to comply with a broad type of sending behaviour; behaviour and
      ii) identifies the marking treatment that network nodes are expected to
      apply to L4S packets.</t>
      <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 target="l4sid_transport_req" format="default"/> for full transport layer transport-layer behaviour
      requirements, including feedback and congestion response.</t>
      <t>A network node that implements the L4S service always classifies
      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 <xref target="l4sid_network_req" format="default"/> for full network element behaviour
      requirements, including classification, ECN-marking ECN marking, and interaction of
      the L4S identifier with other identifiers and per-hop behaviours.</t>
      <t>L4S ECN works with ECN tunnelling and encapsulation behaviour as is,
      except there is one known case where careful attention to configuration
      is required, which is detailed in <xref target="l4sid_encaps" format="default"/>.</t>
      <t>L4S
      <t>This specification of L4S ECN is currently on the experimental track. has Experimental status. So <xref target="l4sid_expts" format="default"/> collects together the general questions and
      issues that remain open for investigation during L4S experimentation.
      Open issues or questions specific to particular components are called
      out in the specifications of each component part, such as the DualQ
      <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" 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
      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" target="RFC9330" format="default"/>.</t>
    </section>
    <section anchor="l4sid_reqs" numbered="true" toc="default">
      <name>Choice of L4S Packet Identifier: Requirements</name>
      <t>This subsection briefly records the process that led to the chosen
      L4S identifier.</t>
      <t>The identifier for packets using the Low Latency, Low Loss, Scalable
      throughput (L4S) L4S service needs to meet the following requirements:</t>
      <ul spacing="normal">
        <li>it SHOULD <bcp14>SHOULD</bcp14> survive end-to-end end to end between source and destination
          end-points:
          endpoints: across the boundary between host and network, between
          interconnected networks, and through middleboxes;</li>
        <li>it SHOULD <bcp14>SHOULD</bcp14> be visible at the IP layer;</li>
        <li>it SHOULD <bcp14>SHOULD</bcp14> be common to IPv4 and IPv6 and be transport-agnostic;</li>
        <li>it SHOULD <bcp14>SHOULD</bcp14> be incrementally deployable;</li>
        <li>it SHOULD <bcp14>SHOULD</bcp14> enable an AQM to classify packets encapsulated by outer
          IP or lower-layer headers;</li>
        <li>it SHOULD <bcp14>SHOULD</bcp14> consume minimal extra codepoints;</li> codepoints; and</li>
        <li>it SHOULD <bcp14>SHOULD</bcp14> be consistent on all the packets of a transport layer transport-layer
          flow, so that some packets of a flow are not served by a different
          queue to others.</li>
      </ul>
      <t>Whether the identifier would be recoverable if the experiment failed
      is a factor that could be taken into account. However, this has not been
      made a requirement, because that would favour schemes that would be
      easier to fail, fail rather than those more likely to succeed.</t>
      <t>It is recognized that any choice of identifier is unlikely to satisfy
      all these requirements, particularly given the limited space left in the
      IP header. Therefore, a compromise will always be necessary, which is
      why all the above requirements are expressed with the word 'SHOULD' "<bcp14>SHOULD</bcp14>" not
      'MUST'.</t>
      "<bcp14>MUST</bcp14>".</t>
      <t>After extensive assessment of alternative schemes, "ECT(1) and CE
      codepoints" was chosen as the best compromise. Therefore, this scheme is
      defined in detail in the following sections, while <xref target="l4sid_ECT1_CE" format="default"/> records its pros and cons against the above
      requirements.</t>
    </section>
    <section anchor="l4sid_transport_req" numbered="true" toc="default">
      <name>Transport Layer
      <name>Transport-Layer Behaviour (the 'Prague L4S Requirements')</name>
      <t>This section defines L4S behaviour at the transport layer, also known
      as the Prague 'Prague L4S Requirements 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">
        <name>Codepoint Setting</name>
        <t>A sender that wishes a packet to receive L4S treatment as it is
        forwarded, MUST
        forwarded <bcp14>MUST</bcp14> set the ECN field in the IP header (v4 or v6) to the
        ECT(1) codepoint.</t>
      </section>
      <section anchor="l4sid_feedback" numbered="true" toc="default">
        <name>Prerequisite Transport Feedback</name>
        <t>For a transport protocol to provide scalable Scalable congestion control
        (<xref target="l4sid_congestion_response" format="default"/>) format="default"/>), it MUST <bcp14>MUST</bcp14> provide feedback
        of the extent of CE marking on the forward path. When ECN was added to
        TCP <xref
        TCP <xref target="RFC3168" format="default"/>, the feedback method reported no
        more than one CE mark per round trip. Some transport protocols derived
        from TCP mimic this behaviour while others report the accurate extent
        of ECN marking. This means that some transport protocols will need to
        be updated as a prerequisite for scalable Scalable congestion control. The
        position for a few well-known transport protocols is given below.</t>
        <dl newline="false" spacing="normal">
          <dt>TCP:</dt>

          <dd>Support for the accurate ECN feedback
            requirements <xref
            requirements <xref target="RFC7560" format="default"/> (such as that provided
            by AccECN <xref AccECN <xref target="I-D.ietf-tcpm-accurate-ecn" format="default"/>) by
            both ends is a prerequisite for scalable Scalable congestion control 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
            support accurate ECN feedback. However, the converse does not
            apply.
	    So even if both ends support AccECN, either of the two ends
            can choose not to use a scalable Scalable congestion control, whatever the
            other end's choice.</dd> choice is.</dd>
            <dt>SCTP:</dt>

          <dd>A suitable ECN feedback mechanism for SCTP
            could add a chunk to report the number of received CE marks (as
            described in a long-expired draft <xref document <xref target="I-D.stewart-tsvwg-sctpecn" format="default"/> or as sketched out in
            Appendix A <xref target="RFC4960" section="A" sectionFormat="bare"/> of the now obsolete now-obsolete second standards track Standards Track
            specification of SCTP <xref SCTP <xref target="RFC4960" format="default"/>).</dd>
          <dt>RTP over UDP:</dt>
          <dd>A prerequisite for scalable Scalable congestion
            control is for both (all) ends of one media-level hop to signal
            ECN support <xref support <xref target="RFC6679" format="default"/> and use the new generic
            RTCP feedback format of <xref target="RFC8888" format="default"/>. The presence of
            ECT(1) implies that both (all) ends of that media-level hop
            support ECN. However, the converse does not apply. So each end of
            a media-level hop can independently choose not to use a scalable Scalable
            congestion control, even if both ends support ECN.</dd>
          <dt>QUIC:</dt>
          <dd>Support for sufficiently fine-grained ECN
            feedback is provided by the v1 IETF QUIC transport <xref transport v1 <xref target="RFC9000" format="default"/>.</dd>
          <dt>DCCP:</dt>
          <dd>The ACK Acknowledgement (ACK) vector in DCCP <xref DCCP <xref target="RFC4340" format="default"/> is already sufficient to report the extent of
            CE marking as needed by a scalable Scalable congestion control.</dd>
        </dl>
      </section>
      <section anchor="l4sid_congestion_response" numbered="true" toc="default">
        <name>Prerequisite Congestion Response</name>
        <t>As a condition for a host to send packets with the L4S identifier
        (ECT(1)), it SHOULD <bcp14>SHOULD</bcp14> implement a congestion control behaviour that
        ensures that, in steady state, the average duration between induced
        ECN marks does not increase as flow rate scales up, all other factors
        being equal. This is termed a scalable Scalable congestion control. This
        invariant duration ensures that, as flow rate scales, the average
        period with no feedback information about capacity does not become
        excessive. It also ensures that queue variations remain small, without
        having to sacrifice utilization.</t>
        <t>With a congestion control that sawtooths to probe capacity, this
        duration is called the recovery time, because each time the sawtooth
        yields, on average it takes this time to recover to its previous high
        point. A scalable Scalable congestion control does not have to sawtooth, but it
        has to coexist with scalable Scalable congestion controls that do.</t>
        <t>For instance, for DCTCP <xref DCTCP <xref target="RFC8257" format="default"/>, TCP Prague
        <xref target="I-D.briscoe-iccrg-prague-congestion-control" format="default"/>, <xref target="PragueLinux" format="default"/> <xref target="PragueLinux" format="default"/>, and the L4S variant of SCReAM <xref SCReAM <xref target="SCReAM-L4S" format="default"/>, format="default"/> <xref target="RFC8298" format="default"/>, the average recovery
        time is always half a round trip (or half a reference round trip),
        whatever the flow rate.</t>
        <t>As with all transport behaviours, a detailed specification
        (probably an experimental Experimental RFC) is expected for each congestion
        control, following the guidelines for specifying new congestion
        control algorithms in <xref in <xref target="RFC5033" format="default"/>. In addition, it
        is expected to document that these L4S-specific matters, matters will be documented, specifically the
        timescale over which the proportionality is averaged, averaged and the control of
        burstiness. The recovery time requirement above is worded as a
        'SHOULD'
        "<bcp14>SHOULD</bcp14>" rather than a 'MUST' "<bcp14>MUST</bcp14>" to allow reasonable flexibility for such
        implementations.</t>
        <t>The condition 'all other factors being equal', equal' allows the recovery
        time to be different for different round trip round-trip times, as long as it
        does not increase with flow rate for any particular RTT.</t>
        <t>Saying that the recovery time remains roughly invariant is
        equivalent to saying that the number of ECN CE marks per round trip
        remains invariant as flow rate scales, all other factors being equal.
        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
        congestion response functions, it is also equivalent to say that the
        congestion window is inversely proportional to the proportion of bytes
        in packets marked with the CE codepoint (see section Section 2 of <xref target="PI2" format="default"/>).</t>
        <!--For example, the timescale over which this rough proportionality applies will depend on the type of application, ranging
from per packet adjustment through smooth adjustment of encoding over perhaps tens of seconds. Low bit-rate flows might
even respond at the timescale of self-admission control solely at the start of each flow. As with any congestion control,
the sender SHOULD also avoid excessive bursts, but this is particularly important with the L4S service.-->

        <t>In order to coexist safely with other Internet traffic, a scalable Scalable
        congestion control is not allowed to tag its packets with the ECT(1)
        codepoint unless it complies with the following numbered requirements
        and recommendations:</t>

        <ol spacing="normal" type="1"><li>A scalable type="1"><li anchor="l4sid_Prague_req-replaceable">A Scalable congestion control MUST <bcp14>MUST</bcp14> be capable of being replaced
            by a Classic congestion control (by application and/or by
            administrative control). If a Classic congestion control is
            activated, it will not tag its packets with the ECT(1) codepoint
            (see <xref target="l4sid_sec_replaceable" format="default"/> for rationale).</li>
          <li>As

          <li anchor="l4sid_Prague_req-loss-response">As well as responding to ECN markings, a scalable Scalable congestion
            control MUST <bcp14>MUST</bcp14> react to packet loss in a way that will coexist
            safely with Classic congestion controls
	    such as standard
            Reno <xref Reno <xref target="RFC5681" format="default"/>, as required by <xref target="RFC5033" format="default"/> (see <xref target="l4sid_sec_fallback_on_loss" format="default"/> for rationale).</li>
          <li>
          <li anchor="l4sid_Prague_req-classic-ecn-response">
            <t>In uncontrolled environments, monitoring MUST <bcp14>MUST</bcp14> be implemented to
            support detection of problems with an ECN-capable AQM at the path
            bottleneck that appears not to support L4S and that might be in a
            shared queue. Such monitoring SHOULD <bcp14>SHOULD</bcp14> be applied to live traffic
            that is using Scalable congestion control. Alternatively,
            monitoring need not be applied to live traffic, if monitoring with
            test traffic has been arranged to cover the paths that live
            traffic takes through uncontrolled environments. </t>
            <t>A function to detect the above problems with an
            ECN-capable AQM MUST <bcp14>MUST</bcp14> also be implemented and used. The detection
            function SHOULD <bcp14>SHOULD</bcp14> be capable of making the congestion control adapt
            its ECN-marking response in real-time real time to coexist safely with
            Classic congestion controls such as standard Reno <xref Reno <xref target="RFC5681" format="default"/>, as required by <xref target="RFC5033" format="default"/>. This
            could be complemented by more detailed offline detection of
            potential problems. If only offline detection is used and
            potential problems with such an AQM are detected on certain paths,
            the scalable Scalable congestion control MUST <bcp14>MUST</bcp14> be replaced by a Classic
            congestion control, at least for the problem paths. </t>
            <t>See <xref target="l4sid_congestion_response_rfcs" format="default"/>, <xref target="l4sid_sec_fallback_on_classic_CE" format="default"/> format="default"/>, and the L4S
            operational guidance <xref guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/>
            for rationale and explanation.</t>
            <t>Note

            <t indent="3">Note that a
            scalable
            Scalable congestion control is not expected to change to setting
            ECT(0) while it transiently adapts to coexist with Classic
            congestion controls, whereas a replacement congestion control that
            solely behaves in the Classic way will set ECT(0).</t>
          </li>
          <li>In
          <li anchor="l4sid_Prague_req-rtt-independence">In the range between the minimum likely RTT and typical RTTs
            expected in the intended deployment scenario, a scalable Scalable
            congestion control MUST <bcp14>MUST</bcp14> converge towards a rate that is as
            independent of RTT as is possible without compromising stability
            or utilization (see <xref target="l4sid_sec_RTT_dependence" format="default"/> for
            rationale).</li>
          <li>A scalable
          <li anchor="l4sid_Prague_req-fractional-window">A Scalable congestion control SHOULD <bcp14>SHOULD</bcp14> remain responsive to
            congestion when typical RTTs over the public Internet are
            significantly smaller because they are no longer inflated by
            queuing delay. It would be preferable for the minimum window of a
            scalable
            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
            spec <xref
            <xref target="RFC3168" format="default"/> sectionFormat="of" section="6.1.2">the ECN spec</xref> (or an equivalent for other
            transports). However, a lower minimum is not set as a formal
            requirement for L4S experiments (see <xref target="l4sid_sec_min_cwnd" format="default"/> for rationale).</li>
          <li>A scalable
          <li anchor="l4sid_Prague_req-reordering">A Scalable congestion control's loss detection SHOULD <bcp14>SHOULD</bcp14> be
            resilient to reordering over an adaptive time interval that scales
            with throughput and adapts to reordering (as in RACK <xref Recent ACK (RACK) <xref target="RFC8985" format="default"/>), as opposed to counting only in fixed units of
            packets (as in the 3 DupACK Duplicate ACK (DupACK) rule of New Reno <xref NewReno <xref target="RFC5681" format="default"/> and <xref target="RFC6675" format="default"/>, which is not
            scalable). As data rates increase (e.g., due to new and/or
            improved technology), congestion controls that detect loss by
            counting in units of packets become more likely to incorrectly
            treat reordering events as congestion-caused loss events (see
            <xref target="l4sid_sec_reordering_tolerance" format="default"/> for further
            rationale). This requirement does not apply to congestion controls
            that are solely used in controlled environments where the network
            introduces hardly any reordering.</li>
          <li>A scalable
          <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
            the limit any lower than 10% of the minimum RTT expected in a
            typical deployment (e.g. additional (e.g., additional queuing of roughly 250 us
            for the public Internet). This would be converted to a number of
            packets by multiplying by the current average packet rate. Then,
            the queue caused by each burst at the bottleneck link would not
            exceed 250us 250 us (under the worst-case assumption that the flow is
            filling the capacity). No normative requirement to limit bursts is
            given here and, here, and until there is more industry experience from the
            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>
        </ol>
        <t>Each sender in a session can use a scalable Scalable congestion control
        independently of the congestion control used by the receiver(s) when
        they send data. Therefore, there might be ECT(1) packets in one
        direction and ECT(0) or Not-ECT in the other.</t>
        <t>Later (<xref target="l4sid_inclusion_dualq" format="default"/>)
        <t>Later, this document
        discusses the conditions for mixing other "'Safe' Unresponsive
        Traffic" (e.g. DNS, LDAP, (e.g., DNS, Lightweight Directory Access Protocol (LDAP), NTP, voice, and game sync packets) with L4S
        traffic.
        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
        ECT(1), except in the (unlikely) case that it satisfies the above
        conditions.</t>
        <section anchor="l4sid_congestion_response_rfcs" numbered="true" toc="default">
          <name>Guidance on Congestion Response in the RFC Series</name>
          <t>RFC 3168
          <t><xref target="RFC3168"/> requires the congestion responses to a CE-marked
          packet and a dropped packet to be the same. RFC 8311 <xref target="RFC8311"/> is a
          standards-track
          Standards Track update to RFC 3168 <xref target="RFC3168"/> that is intended to enable
          experimentation with ECN, including the L4S experiment.
          RFC 8311
          <xref target="RFC8311"/> allows an experimental congestion control's response
          to a CE-marked packet to differ from the response to a dropped
          packet, provided that the differences are documented in an
          experimental
          Experimental RFC, such as the present document.</t>
          <t>BCP 124 <xref
          <t>BCP 124 <xref target="RFC4774" format="default"/> gives guidance
          to protocol designers, when specifying alternative semantics for the
          ECN
          IP-ECN field. RFC 8311 <xref target="RFC8311"/> explained that it did not need to update the
          best current practice in BCP 124 BCP 124 in order to relax the 'equivalence
          with drop' requirement because, although BCP 124 BCP 124 quotes the same
          requirement from RFC 3168, <xref target="RFC3168"/>, the BCP does not impose requirements
          based on it. BCP 124

	  BCP 124 <xref target="RFC4774" format="default"/> describes three options for incremental
          deployment, with Option 3 (in Section 4.3 of
          BCP 124) <xref target="RFC4774" section="4.3"
          sectionFormat="of">BCP 124</xref>) best matching the L4S
          case. Option 3's requirement for end-nodes is that they respond to
          CE marks "in a way that is friendly to flows using IETF-conformant
          congestion control." This echoes other general congestion control
          requirements in the RFC
          series, Series, for example example, <xref target="RFC5033" format="default"/>, which says
          format="default"/> states that "...congestion controllers that have
          a significantly negative impact on traffic using standard congestion
          control may be suspect", or suspect" and <xref target="RFC8085" format="default"/> concerning
          format="default"/>, which concerns UDP congestion control says control, states that

          "Bulk-transfer applications that choose not to implement TFRC or
          TCP-like windowing SHOULD <bcp14>SHOULD</bcp14> implement a congestion
          control scheme that results in bandwidth (capacity) use that
          competes fairly with TCP within an order of magnitude."</t>

          <t>The third normative bullet Item <xref target="l4sid_Prague_req-classic-ecn-response" format="counter"/> in <xref target="l4sid_congestion_response" format="default"/> above (which concerns L4S
          response to congestion from a Classic ECN AQM) aims to ensure that
          these 'coexistence' requirements are satisfied, but it makes some
          compromises. This subsection highlights and justifies those
          compromises
          compromises, and <xref target="l4sid_sec_fallback_on_classic_CE" format="default"/>
          and the L4S operational guidance <xref guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/> give detailed analysis, examples examples,
          and references (the normative text in that bullet takes precedence
          if any informative elaboration leads to ambiguity). The approach is
          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
          the potential severity of the harm if they do. </t>

          <dl newline="false" spacing="normal">
            <dt>Prevalence:</dt>
            <dd>
              <t>There are three cases:</t>
              <ul spacing="normal">
                <li>Drop Tail: Coexistence between L4S and Classic flows is
                  not in doubt where the bottleneck does not support any form
                  of ECN, which has remained by far the most prevalent case
                  since the ECN RFC spec <xref target="RFC3168" format="default"/> was published in 2001.</li>
                <li>L4S: Coexistence is not in doubt if the bottleneck
                  supports L4S.</li>
                <li>
                  <t>Classic ECN <xref target="RFC3168" format="default"/>: ECN: The
                  compromises centre around cases where the bottleneck
                  supports Classic ECN <xref target="RFC3168" format="default"/> but not L4S.
		  But it depends on which sub-case:</t>
                  <ul spacing="normal">
                    <li>Shared Queue with Classic ECN: At the time of
                      writing, the members of the Transport Working group Group are
                      not aware of any current deployments of single-queue
                      Classic ECN bottlenecks in the Internet. Nonetheless, at
                      the scale of the Internet, rarity need not imply small
                      numbers,
                      numbers nor that there will be rarity in the
                      future.</li>
                    <li>
                      <t>Per-Flow-queues
                      <t>Per-Flow Queues with Classic ECN: Most AQMs with
                      per-flow-queuing (FQ)
                      per-flow queuing deployed from 2012 onwards had
                      Classic ECN enabled by default, specifically
                      FQ-CoDel <xref
                      FQ-CoDel <xref target="RFC8290" format="default"/> and
                      COBALT <xref
                      COBALT <xref target="COBALT" format="default"/>. But the compromises
                      only apply to the second of two further sub-cases:</t>
                      <ul spacing="normal">
                        <li>With per-flow-queuing, co-existence per-flow queuing, coexistence between
                          Classic and L4S flows is not normally a problem,
                          because different flows are not meant to be in the
                          same queue (BCP 124 <xref (BCP 124 <xref target="RFC4774" format="default"/> did not foresee the introduction
                          of per-flow-queuing, per-flow queuing, which appeared as a potential
                          isolation technique some eight years after the BCP
                          was published).</li>
                        <li>However, the isolation between L4S and Classic
                          flows is not perfect in cases where the hashes of
                          flow IDs identifiers (IDs) collide or where multiple flows within a
                          layer-3
                          Layer 3 VPN are encapsulated within one flow ID.</li>
                      </ul>
                    </li>
                  </ul>
                </li>
              </ul>
              <t>To summarize, the coexistence problem is confined to
              cases of imperfect flow isolation in an FQ, FQ or in potential
              cases where a Classic ECN AQM has been deployed in a shared
              queue (see the L4S operational guidance <xref guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/> for further details including
              recent surveys attempting to quantify prevalence). Further, if
              one of these cases does occur, the coexistence problem does not
              arise unless sources of Classic and L4S flows are simultaneously
              sharing the same bottleneck queue (e.g. different (e.g., different
              applications in the same household) household), and flows of each type have
              to be large enough to coincide for long enough for any
              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
              will need to answer.</t>
            </dd>
            <dt>Severity:</dt>
            <dd>Where long-running L4S and Classic flows
              coincide in a shared queue, testing of one L4S congestion
              control (TCP Prague) has found that the imbalance in average
              throughput between an L4S and a Classic flow can reach 25:1 in
              favour of L4S in the worst case <xref case <xref target="ecn-fallback" format="default"/>. However, when capacity is most scarce,
              the Classic flow gets a higher proportion of the link, for
              instance
              instance, over a 4 Mb/s link the throughput ratio is below ~10:1
              over paths with a base RTT below 100 ms, and it falls below ~5:1
              for base RTTs below 20ms.</dd> 20 ms.</dd>
          </dl>
          <t>These throughput ratios can clearly fall well outside current RFC
          guidance on coexistence. However, the tendency towards leaving a
          greater share for Classic flows at lower link rate and the very
          limited prevalence of the conditions necessary for harm to occur led
          to the possibility of allowing the RFC requirements to be
          compromised, albeit briefly:</t>
          <ul spacing="normal">
            <li>The recommended approach is still to detect and adapt to a
              Classic ECN AQM in real-time, real time, which is fully consistent with all
              the RFCs on coexistence. In other words, the "SHOULD"s "<bcp14>SHOULD</bcp14>"s in the
              third bullet
              Item <xref target="l4sid_Prague_req-classic-ecn-response" format="counter"/> of <xref target="l4sid_congestion_response" format="default"/> above
              expect the sender to implement something similar to the proof of
              concept proof-of-concept
              code that detects the presence of a Classic ECN AQM and
              falls back to a Classic congestion response within a few round
              trips <xref
              trips <xref target="ecn-fallback" format="default"/>. However, although this
              code reliably detects a Classic ECN AQM, the current code can
              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
              safe way round, and although implementers are expected to be
              able to improve on this proof of concept, concerns have been
              raised that implementers might lose faith in such detection and
              disable it.</li>
            <li>Therefore the third bullet
            <li>Item <xref target="l4sid_Prague_req-classic-ecn-response" format="counter"/> in <xref target="l4sid_congestion_response" format="default"/> above therefore allows a compromise
              where coexistence could briefly diverge from the requirements in the RFC
              Series briefly,
              Series, but mandatory monitoring is required, required in order
              to detect such cases and trigger remedial action. This approach
              tolerates a brief divergence from the RFCs given the likely low
              prevalence and given harm here means a flow progresses more
              slowly than it would otherwise, but it does progress. The L4S operational
              guidance <xref
              guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/> outlines a
              range of example remedial actions that include alterations
              either to
              either the sender or to the network. However, the final
              normative requirement in the third bullet Item <xref target="l4sid_Prague_req-classic-ecn-response" format="counter"/> of <xref target="l4sid_congestion_response" format="default"/> above places ultimate
              responsibility for remedial action on the sender. If coexistence
              problems with a Classic ECN AQM are detected (implying they have
              not been resolved by the network), it says states that the sender "MUST" "<bcp14>MUST</bcp14>"
              revert to a Classic congestion control."</li> control.</li>
          </ul>
          <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
          lower risk
          lower-risk scenarios.</t>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>Filtering or Smoothing of ECN Feedback</name>
        <t><xref target="l4sid_Semantics" format="default"/> below specifies that an L4S AQM is
        expected to signal L4S ECN immediately, to avoid introducing delay due
        to filtering or smoothing. This contrasts with a Classic AQM, which
        filters out variations in the queue before signalling ECN marking or
        drop. In the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" architecture <xref target="RFC9330" format="default"/>, responsibility for smoothing out
        these variations shifts to the sender's congestion control.</t>

        <t>This shift of responsibility has the advantage that each sender can
        smooth variations over a timescale proportionate to its own RTT.
        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
        RTT to ensure stability. For all the typical flows with shorter RTT RTTs
        than the worst-case, this makes congestion control unnecessarily
        sluggish.</t>
        <t>This also gives an L4S sender the choice not to smooth, depending
        on its context (start-up, congestion avoidance, etc.). Therefore, this
        document places no requirement on an L4S congestion control to smooth
        out variations in any particular way. Implementers are encouraged to
        openly publish the approach they take to smoothing, and the smoothing as well as results
        and experience they gain during the L4S experiment.</t>
      </section>
    </section>
    <section anchor="l4sid_network_req" numbered="true" toc="default">
      <name>Network Node Behaviour</name>
      <t/>
      <section numbered="true" toc="default">
        <name>Classification and Re-Marking Behaviour</name>
        <t>A network node that implements the L4S service:</t>
        <ul spacing="normal">
          <li>MUST
          <li><bcp14>MUST</bcp14> classify arriving ECT(1) packets for L4S treatment, unless
            overridden by another classifier (e.g., see (e.g., see <xref target="l4sid_exclusion_dualq" format="default"/>);</li> format="default"/>).</li>
          <li>
            <t>MUST
            <t><bcp14>MUST</bcp14> classify arriving CE packets for L4S treatment as well,
            unless overridden by another classifier or unless the exception
            referred to next applies;</t> applies.</t>

            <t>CE packets might
            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
            (see <xref target="l4sid_ECT1_CE" format="default"/> for rationale). The exception
            is where some flow-aware in-network mechanism happens to be
            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
            implication that such a mechanism is necessary.</t>
          </li>
        </ul>
        <t>An L4S AQM treatment follows similar codepoint transition rules to
        those in RFC 3168. <xref target="RFC3168"/>. Specifically, the ECT(1) codepoint MUST NOT <bcp14>MUST NOT</bcp14> be
        changed to any other codepoint other than CE, and CE MUST NOT <bcp14>MUST NOT</bcp14> be changed to
        any other codepoint. An ECT(1) packet is classified as ECN-capable
        and, 'ECN-capable',
        and if congestion increases, an L4S AQM algorithm will increasingly
        mark the ECN IP-ECN field as CE, otherwise forwarding packets unchanged as
        ECT(1). Necessary conditions for an L4S marking treatment are defined
        in <xref target="l4sid_Semantics" format="default"/>.</t>
        <t>Under persistent overload overload, an L4S marking treatment MUST
        <bcp14>MUST</bcp14> begin applying drop to L4S traffic until the
        overload episode has subsided, as recommended for all AQM methods in
        <xref target="RFC7567" format="default"/>
        (Section 4.2.1), sectionFormat="of" section="4.2.1"/>, which
        follows the similar advice in RFC 3168
        (Section 7). <xref target="RFC3168"
        sectionFormat="of" section="7"/>.  During overload, it MUST
        <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
        satisfied by using drop in only the most overloaded individual
        per-flow AQMs. In a DualQ with flow-aware queue protection
        (e.g. <xref
        (e.g., <xref target="I-D.briscoe-docsis-q-protection" format="default"/>), this
        could be achieved by redirecting packets in those flows contributing
        most to the overload out of the L4S queue so that they are subjected
        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
        node that implements the L4S treatment MUST <bcp14>MUST</bcp14> also implement an AQM
        treatment for the Classic service as defined in <xref target="l4sid_Terminology" format="default"/>. This Classic AQM treatment need not mark
        ECT(0) packets, but if it does, see <xref target="l4sid_Semantics" format="default"/>
        for the strengths of the markings relative to drop. It MUST <bcp14>MUST</bcp14> classify
        arriving ECT(0) and Not-ECT packets for treatment by this Classic AQM
        (for the DualQ Coupled AQM, AQM; see the extensive discussion on
        classification in Sections 2.3 <xref target="RFC9332" section="2.3"
sectionFormat="bare"/> and 2.5.1.1 <xref target="RFC9332" section="2.5.1.1"
sectionFormat="bare"/> of <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" target="RFC9332" format="default"/>).</t>
        <t>In case unforeseen problems arise with the L4S experiment, it MUST <bcp14>MUST</bcp14>
        be possible to configure an L4S implementation to disable the L4S
        treatment.
        Once disabled, all packets of all ECN codepoints will
        receive Classic treatment and ECT(1) packets MUST <bcp14>MUST</bcp14> be treated as if
        they were Not-ECT.</t>
      </section>
      <section anchor="l4sid_Semantics" numbered="true" toc="default">
        <name>The Strength of L4S CE Marking Relative to Drop</name>

        <t>The relative strengths of L4S CE and drop are irrelevant where AQMs
        are implemented in separate queues per-application-flow, per application-flow, which are
        then explicitly scheduled (e.g. with (e.g., with an FQ scheduler as in
        FQ-CoDel <xref
        FQ-CoDel <xref target="RFC8290" format="default"/>). Nonetheless, the relationship
        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" AQM <xref target="RFC9332" format="default"/>, as indicated below.</t>
        <t>Unless an AQM node schedules application flows explicitly, the
        likelihood that the AQM drops a Not-ECT Classic packet (p_C) MUST <bcp14>MUST</bcp14> be
        roughly proportional to the square of the likelihood that it would
        have marked it if it had been an L4S packet (p_L). That is</t>
        <ul empty="true" spacing="normal">
          <li>p_C is:</t>

          <t indent="3">p_C ~= (p_L / k)^2</li>
        </ul> k)<sup>2</sup></t>

        <t>The constant of proportionality (k) does not have to be
        standardized for interoperability, but a value of 2 is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
        The term 'likelihood' is used above to allow for marking and dropping
        to be either probabilistic or deterministic.</t>
        <t>This formula ensures that Scalable and Classic flows will converge
        to roughly equal congestion windows, for the worst case of Reno
        congestion control. This is because the congestion windows of Scalable
        and Classic congestion controls are inversely proportional to p_L and
        sqrt(p_C)
        sqrt(p_C), respectively. So squaring p_C in the above formula
        counterbalances the square root that characterizes Reno-friendly
        flows.</t>
        <t>Note
        <aside><t>Note that, contrary to RFC 3168, <xref target="RFC3168" format="default"/>, an AQM implementing the L4S
        and Classic treatments does not mark an ECT(1) packet under the same
        conditions that it would have dropped a Not-ECT packet, as allowed by
        <xref target="RFC8311" format="default"/>, which updates RFC 3168. <xref target="RFC3168" format="default"/>.
	However, if it
        marks ECT(0) packets, it does so under the same conditions that it would have dropped a
	Not-ECT packet <xref target="RFC3168" format="default"/>.<!--KDS: replace "a Not-ECT packet"
        by "a packet", as any drop should be classic, and also ECT(0),(1) or CE packets can be dropped
BB: But that's not the intended meaning. Yes, a packet with any ECN field can be dropped, but this rule is just about
what /would/ have been done /if/ the ECN field had been one specific value (Not-ECT).
-->
        </t> <xref target="RFC3168" format="default"/>.

        </t></aside>
        <t>Also, In in the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" architecture <xref target="RFC9330" format="default"/>, the sender, not the network, is
        responsible for smoothing out variations in the queue. So, So an L4S AQM
        MUST
        <bcp14>MUST</bcp14> signal congestion as soon as possible. Then, an L4S sender
        generally interprets CE marking as an unsmoothed signal.</t>
        <t>This requirement does not prevent an L4S AQM from mixing in
        additional congestion signals that are smoothed, such as the signals
        from a Classic smoothed AQM that are coupled with unsmoothed L4S
        signals in the coupled DualQ <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" format="default"/>. But DualQ <xref target="RFC9332" format="default"/>, but only as long as the
        onset of congestion can be signalled immediately, immediately and can be
        interpreted by the sender as if it has been signalled immediately,
        which is important for interoperability</t>
      </section>
      <section anchor="l4sid_identification_transport_aware" numbered="true" toc="default">
        <name>Exception for L4S Packet Identification by Network Nodes with Transport-Layer Awareness</name>
        <!--This section doesn't fit very well here. It would be better as an Appendix, then it would need the following introductory
para:

Section 2.3 recognizes that CE packets might have originally been L4S or Classic. It argues that this ambiguity is not
serious, and therefore, for simplicity, it recommends that a packet classifer in the network "SHOULD" classify all CE
packets as L4S. Even though it is probably unnecessary to resolve the ambiguity, the following text provides a way to do
so using per-flow processing in the network. Per-flow processing has other detrimental side-effects, so this text is
controversial, but worth recording, particularly for those cases where per-flow processing is already being used for
other purposes.-->

        <t>To implement L4S packet classification, a network node does not
        need to identify transport-layer flows. Nonetheless, if an L4S network
        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
        MAY
        <bcp14>MAY</bcp14> classify any CE packets in the same flow as if they were Classic
        ECT(0) packets. In all other cases, a network node MUST <bcp14>MUST</bcp14> classify all
        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;
        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
        ECT(1) (this advice will need to be verified as part of L4S
        experiments).</t>
      </section>
      <section anchor="l4sid_other_IDs" numbered="true" toc="default">
        <name>Interaction of the L4S Identifier with other Other Identifiers</name>
        <t>The examples in this section concern how additional identifiers
        might complement the L4S identifier to classify packets between
        class-based queues. Firstly Firstly, <xref target="l4sid_iother_IDs_dualq" format="default"/>
        considers two queues, L4S and Classic, as in the Coupled DualQ
        AQM <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" Coupled
        AQM <xref target="RFC9332" format="default"/>, either
        alone (<xref target="l4sid_inclusion_dualq" format="default"/>) or within a larger
        queuing hierarchy (<xref target="l4sid_exclusion_dualq" format="default"/>). Then Then, <xref target="l4sid_iother_IDs_fq" format="default"/> considers schemes that might combine
        per-flow 5-tuples with other identifiers.</t>
        <section anchor="l4sid_iother_IDs_dualq" numbered="true" toc="default">
          <name>DualQ Examples of Other Identifiers Complementing L4S Identifiers</name>
          <t/>
          <section anchor="l4sid_inclusion_dualq" numbered="true" toc="default">
            <name>Inclusion of Additional Traffic with L4S</name>
            <t>In a typical case for the public Internet Internet, a network element
            that implements L4S in a shared queue might want to classify some
            low-rate but unresponsive traffic (e.g. DNS, (e.g., DNS, LDAP, NTP,
            voice, and game sync packets) into the low latency low-latency queue to mix with
            L4S traffic. In this case case, it would not be appropriate to call the
            queue an L4S queue, because it is shared by L4S and non-L4S
            traffic. Instead, it will be called the low latency low-latency or L queue.
            The L queue then offers two different treatments:</t>
            <ul spacing="normal">
              <li>The
              <li>the L4S treatment, which is a combination of the L4S AQM
                treatment and a priority scheduling treatment;</li>
              <li>The low latency treatment, and</li>
              <li>the low-latency treatment, which is solely the priority
                scheduling treatment, without ECN-marking ECN marking by the AQM.</li>
            </ul>
            <t>To identify packets for just the scheduling treatment, it would
            be inappropriate to use the L4S ECT(1) identifier, because such
            traffic is unresponsive to ECN marking. Examples of relevant
            non-ECN identifiers are:</t>
            <ul spacing="normal">
              <li>address ranges of specific applications or hosts configured
                to be, or known to be, safe, e.g. hard-coded IoT e.g., hard-coded Internet of Things (IoT) devices
                sending low intensity low-intensity traffic;</li>
              <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
                limited burstiness such as the EF (Expedited
                Forwarding <xref <xref target="RFC3246" format="default"/>),
                Voice-Admit <xref format="default"/>,
                VOICE-ADMIT <xref target="RFC5865" format="default"/> format="default"/>, or proposed NQB
                (Non-Queue-Building <xref
                Non-Queue-Building (NQB) <xref target="I-D.ietf-tsvwg-nqb" format="default"/>) format="default"/>
                service classes or equivalent local-use Local-use DSCPs (see <xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="default"/>).</li>
            </ul>
            <t>To be clear, classifying into the L queue based on application
            layer application-layer
            identification (e.g. (e.g., DNS) is an example of a local
            optimization, not a recommendation. Applications will not be able
            to rely on such unsolicited optimization. A more reliable approach
            would be for the sender to set an appropriate IP layer IP-layer identifier,
            such as one of the above Diffserv codepoints.</t>
            <t>In summary, a network element that implements L4S in a shared
            queue MAY <bcp14>MAY</bcp14> classify additional types of packets into the L queue
            based on identifiers other than the ECN IP-ECN field, but the types
            SHOULD
            <bcp14>SHOULD</bcp14> be 'safe' to mix with L4S traffic, where 'safe' is
            explained in <xref target="l4sid_safe_unresponsive" format="default"/>.</t>
            <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
            marking ECN-marking
            treatment, unless it also carried an ECT(1) or CE
            codepoint.
            The specification of an L4S AQM MUST <bcp14>MUST</bcp14> define the
            behaviour for packets with unexpected combinations of codepoints,
            e.g. a
            e.g., a non-ECN-based classifier for the L queue, queue but with ECT(0)
            in the ECN IP-ECN field (for examples with appropriate behaviours, see section 2.5.1.1 Section <xref target="RFC9332" section="2.5.1.1"
sectionFormat="bare"/> of the DualQ
            spec <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled"
            spec <xref target="RFC9332" format="default"/>).</t>
            <t>For clarity, non-ECN identifiers, such as the examples itemized
            above, might be used by some network operators who believe they
            identify non-L4S traffic that would be safe to mix with L4S
            traffic. They are not alternative ways for a host to indicate that
            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
            indicates that it could have originated as ECT(1)). Specifically Specifically,
            ECT(1) indicates that the host claims its behaviour satisfies the
            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 <bcp14>MUST NOT</bcp14> change Not-ECT or ECT(0) in the IP-ECN field to into an
            L4S identifier. This ensures that these codepoints survive for any
            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
            subsequently be ECN-marked by a downstream L4S AQM, but the sender
            would respond to congestion indications thinking it had sent a
            Classic packet. This could result in the flow yielding excessively
            to other L4S flows sharing the downstream bottleneck.</t>
            <section anchor="l4sid_safe_unresponsive" numbered="true" toc="default">
              <name>'Safe' Unresponsive Traffic</name>
              <t>The above section requires unresponsive traffic to be 'safe'
              to mix with L4S traffic. Ideally Ideally, this means that the sender
              never sends any sequence of packets at a rate that exceeds the
              available capacity of the bottleneck link. However, typically an
              unresponsive transport does not even know the bottleneck
              capacity of the path, let alone its available capacity.
              Nonetheless, an application can be considered safe enough if it
              paces packets out (not necessarily completely regularly) with absolute regularity) such
              that its maximum instantaneous rate from packet to packet stays
              well below a typical broadband access rate.</t>
              <t>This is a vague but useful definition, because many low
              latency low-latency
              applications of interest, such as DNS, voice, game sync
              packets, RPC, ACKs, and keep-alives, could match this
              description.</t>
              <t>Low rate streams
              <t>Low-rate streams, such as voice and game sync packets, might
              not use continuously adapting ECN-based congestion control, but
              they ought to at least use a 'circuit-breaker' style of
              congestion response <xref response <xref target="RFC8083" format="default"/>. If the volume
              of traffic from unresponsive applications is high enough to
              overload the link, this will at least protect the capacity
              available to responsive applications. However, queuing delay in
              the L queue will would probably then rise to that controlled by the typically higher level targeted by
              a Classic (drop-based) AQM. If a network operator considers that such
              self-restraint is not enough, it might want to police the L
              queue (see Section 8.2 <xref target="RFC9330" section="8.2"
sectionFormat="bare"/> of the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" architecture <xref target="RFC9330" format="default"/>).</t>
            </section>
          </section>
          <section anchor="l4sid_exclusion_dualq" numbered="true" toc="default">
            <name>Exclusion of Traffic From from L4S Treatment</name>
            <t>To extend the above example, an operator might want to exclude
            some traffic from the L4S treatment for a policy reason,
            e.g. security
            e.g., security (traffic from malicious sources) or commercial
            (e.g. initially
            (e.g., the operator may wish to initially confine the benefits
            of L4S to business customers).</t>

            <t>In this exclusion case, the classifier MUST <bcp14>MUST</bcp14> classify on the
            relevant locally-used locally used identifiers (e.g. source (e.g., source addresses)
            before classifying the non-matching traffic on the end-to-end L4S
            ECN identifier.</t>
            <t>A network node MUST NOT <bcp14>MUST NOT</bcp14> alter the end-to-end L4S ECN identifier
            from L4S to Classic, because an operator decision to exclude
            certain traffic from L4S treatment is local-only. The end-to-end
            L4S identifier then survives for other operators to use, or
            indeed, they can apply their own policy, independently based on
            their own choice of locally-used locally used identifiers. This approach also
            allows any operator to remove its locally-applied locally applied exclusions in
            future, e.g. if e.g., if it wishes to widen the benefit of the L4S
            treatment to all its customers. If a non-compliant or malicious
            network node did swap ECT(1) to ECT(0), the packet could
            subsequently be ECN-marked by a downstream Classic ECN AQM. L4S
            senders are required to detect and handle such treatment (<xref (see Item <xref target="l4sid_Prague_req-classic-ecn-response" format="counter"/> in <xref target="l4sid_congestion_response" format="default"/> item 3), format="default"/>), but that does not
            make this swap OK, because such detection is not known to be
            perfect or immediate.</t>
            <t>A network node that supports L4S but excludes certain packets
            carrying the L4S identifier from L4S treatment MUST <bcp14>MUST</bcp14> still apply
            marking or dropping that is compatible with an L4S congestion
            response.
            For instance, it could either drop such packets with the
            same likelihood as Classic packets or it could ECN-mark them with
            a likelihood appropriate to L4S traffic (e.g. the (e.g., the coupled
            probability in a DualQ coupled Coupled AQM) but aiming for the Classic
            delay target. It MUST NOT <bcp14>MUST NOT</bcp14> ECN-mark such packets with a Classic
            marking probability, which could confuse the sender.</t>
          </section>
          <section numbered="true" toc="default">
            <name>Generalized Combination of L4S and Other Identifiers</name>
            <t>L4S concerns low latency, which it can provide for all traffic
            without differentiation and without <em>necessarily</em>
            affecting bandwidth allocation. Diffserv provides for
            differentiation of both bandwidth and low latency, but its control
            of latency depends on its control of bandwidth. The two
            L4S and Diffserv can be
            combined if a network operator wants to control bandwidth
            allocation but it also wants to provide low latency - latency, i.e., for any
            amount of traffic within one of these allocations of bandwidth
            (rather than only providing low latency by limiting bandwidth)
            <xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="default"/>.</t>
            <t>The DualQ examples so far have been framed in the context of
            providing the default Best Efforts Effort Per-Hop Behaviour (PHB) using
            two queues - -- a Low Latency low-latency (L) queue and a Classic (C) Queue. queue. This
            single DualQ structure is expected to be the most common and
            useful arrangement. But, more generally, an operator might choose
            to control bandwidth allocation through a hierarchy of Diffserv
            PHBs at a node, 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
            PHB.</t>
            <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
            network element would classify it for the L4S treatment
            irrespective of its DSCP. And, if a packet carried (say) (for example) the EF
            DSCP, the network element could classify it into the L queue
            irrespective of its ECN codepoint. However, where the DualQ is in
            a hierarchy of other PHBs, the classifier would classify some
            traffic into other PHBs based on DSCP before classifying between
            the low latency low-latency and Classic queues (based on ECT(1), CE CE, and
            perhaps also the EF DSCP or other identifiers as in the above
            example). <xref target="I-D.briscoe-tsvwg-l4s-diffserv" format="default"/> gives a
            number of examples of such arrangements to address various
            requirements.</t>
            <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
            Diffserv for bandwidth differentiation. It identifies two main
            types of approach, which can be combined: the operator might split
            certain Diffserv PHBs between L4S and a corresponding Classic
            service. Or it might split the L4S and/or the Classic service into
            multiple Diffserv PHBs. In either of these cases, a packet would
            have to be classified on its Diffserv and ECN codepoints.</t>
            <t>In summary, there are numerous ways in which the L4S ECN
            identifier (ECT(1) and CE) could be combined with other
            identifiers to achieve particular objectives. The following
            categorization articulates those that are valid, but it is not
            necessarily exhaustive. Those tagged as 'Recommended-standard-use'
            could be set by the sending host or a network. Those tagged
            as 'Local-use' would only be set by a network:</t>
            <ol spacing="normal" type="1"><li>
                <t>Identifiers Complementing the L4S Identifier</t>
                <ol spacing="normal" type="a"><li>
                    <t>Including More Traffic in the L Queue</t>
                    <t>(Could
                    <t>(could use Recommended-standard-use or
                    Local-use identifiers)</t>
                  </li>
                  <li>
                    <t>Excluding Certain Traffic from the L Queue</t>
                    <t>(Local-use only)</t>
                  </li>
                </ol>
              </li>
              <li>
                <t>Identifiers to place Place L4S classification Classification in a PHB
                Hierarchy</t>
                <t>(Could
                <t>(could use
                Recommended-standard-use or Local-use identifiers)</t>
                <ol spacing="normal" type="a"><li>PHBs Before type="A"><li>PHBs before L4S ECN Classification</li>
                  <li>PHBs After after L4S ECN Classification</li>
                </ol>
              </li>
            </ol>
          </section>
        </section>
        <section anchor="l4sid_iother_IDs_fq" numbered="true" toc="default">
          <name>Per-Flow
          <name>Per-flow Queuing Examples of Other Identifiers Complementing L4S Identifiers</name>
          <t>At a node with per-flow queueing (e.g. FQ-CoDel <xref queuing (e.g., FQ-CoDel <xref target="RFC8290" format="default"/>), the L4S identifier could complement the Layer-4 transport-layer
          flow ID as a further level of flow granularity (i.e. Not-ECT (i.e., Not-ECT
          and ECT(0) queued separately from ECT(1) and CE packets).
          In <xref target="l4sid_ECT1_CE" format="default"/>, the "Risk of
          reordering Classic CE packets" in <xref target="l4sid_ECT1_CE" format="default"/> packets within a flow" discusses the resulting
          ambiguity if packets originally marked set to
          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
          vanishingly small small, and the consequence of such a low level of
          reordering is minimal.</t>
          <t>Alternatively, it could be assumed that it is not in a flow's own
          interest to mix Classic and L4S identifiers. Then Then, the AQM could use
          the ECN IP-ECN field to switch itself between a Classic and an L4S AQM
          behaviour within one per-flow queue. For instance, for ECN-capable
          packets, the AQM might consist of a simple marking threshold threshold, and an
          L4S ECN identifier might simply select a shallower threshold than a
          Classic ECN identifier would.</t>
        </section>
      </section>
      <section anchor="l4sid_bursts_links" numbered="true" toc="default">
        <name>Limiting Packet Bursts from Links</name>
        <t>As well as senders needing to limit packet bursts (<xref target="l4sid_congestion_response" format="default"/>), links need to limit the degree
        of burstiness they introduce. In both cases (senders and links) links), this
        is a tradeoff, trade-off, because batch-handling of packets is done for good
        reason, e.g. processing e.g., for processing efficiency or to make efficient use of
        medium acquisition delay. Some take the attitude that there is no
        point reducing burst delay at the sender below that introduced by
        links (or vice versa). However, delay reduction proceeds by cutting
        down 'the longest pole in the tent', which turns the spotlight on the
        next longest, and so on.</t>
        <t>This document does not set any quantified requirements for links to
        limit burst delay, primarily because link technologies are outside the
        remit of L4S specifications. Nonetheless, the following two
        subsections outline opportunities for addressing bursty links in the
        process of L4S implementation and deployment.</t>
        <section anchor="l4sid_bursts_links_l4s" numbered="true" toc="default">
          <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
          particular link technology without also reviewing opportunities to
          reduce any form of burst delay introduced by that link technology.
          This would at least limit the bursts that the link would otherwise
          introduce into the onward traffic, which would cause jumpy feedback
          to the sender as well as potential extra queuing delay downstream.
          This document does not presume to even give guidance on an
          appropriate target for such burst delay until there is more industry
          experience of L4S. However, as suggested in <xref target="l4sid_congestion_response" format="default"/> format="default"/>, it would not seem necessary to
          limit bursts lower than roughly 10% of the minimum base RTT expected
          in the typical deployment scenario (e.g. 250 (e.g., 250 us burst duration
          for links within the public Internet).</t>
        </section>
        <section anchor="l4sid_bursts_links_l4s_upstream" numbered="true" toc="default">
          <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
          bottlenecks and L4S congestion controls at senders. This is expected
          to highlight interactions with the most bursty upstream links and
          lead operators to tune down the burstiness of those links in their
          network
          networks that are configurable, or configurable or, failing that, to have to
          compromise on the delay target of some L4S AQMs. It might also
          require specific redesign work relevant to the most problematic link
          types. Such knock-on effects of initial L4S deployment would all be a
          part of the learning from the L4S experiment.</t>
          <t>The details of such link changes are beyond the scope of the
          present document.
          Nonetheless, where L4S technology is being
          implemented on an outgoing interface of a device, it would make
          sense to consider opportunities for reducing bursts arriving at
          other incoming interface(s). interfaces. For instance, where an L4S AQM is
          implemented to feed into the upstream WAN interface of a home
          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
          mitigate incoming bursts of aggregated Wi-Fi frames from other Wi-Fi
          stations.</t>
        </section>
      </section>
    </section>
    <section anchor="l4sid_encaps" numbered="true" toc="default">
      <name>Behaviour of Tunnels and Encapsulations</name>
      <section anchor="l4sid_encaps_no_change" numbered="true" toc="default">
        <name>No Change to ECN Tunnels and Encapsulations in General</name>
        <t>The L4S identifier is expected to work through and within any
        tunnel without modification, as long as the tunnel propagates the ECN
        field in any of the ways that have been defined since the first
        variant in the year 2001 <xref 2001 <xref target="RFC3168" format="default"/>. L4S will also
        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"/> format="default"/>, or
        <xref target="I-D.ietf-tsvwg-rfc6040update-shim" format="default"/>. However, it is
        likely that some tunnels still do not implement ECN propagation at
        all. In these cases, L4S will work through such tunnels, but within
        them the outer header of L4S traffic will appear as Classic.</t>
        <t>AQMs are typically implemented where an IP-layer buffer feeds into
        a lower layer, so they are agnostic to link layer link-layer encapsulations.
        Where a bottleneck link is not IP-aware, the L4S identifier is still
        expected to work within any lower layer lower-layer encapsulation without
        modification, as long it propagates the ECN IP-ECN field as defined for the
        link technology, for example example, for MPLS <xref MPLS <xref target="RFC5129" format="default"/> or
        TRILL <xref Transparent
        Interconnection of Lots of Links (TRILL) <xref target="I-D.ietf-trill-ecn-support" format="default"/>. In some of
        these cases, e.g. layer-3 e.g., Layer 3 Ethernet switches, the AQM accesses the
        IP layer
        IP-layer header within the outer encapsulation, so again the L4S
        identifier is expected to work without modification. Nonetheless, the
        programme to define ECN for other lower layers is still in
        progress <xref
        progress <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" format="default"/>.</t>
      </section>
      <section anchor="l4sid_VPN_anti-replay" numbered="true" toc="default">
        <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
        association (SA) of a virtual private network (VPN), VPN, and if the VPN
        egress is employing the optional anti-replay feature, it could
        inappropriately discard Classic packets (or discard the records in
        Classic packets) by mistaking their greater queuing delay for a replay
        attack (see "Dropped Packets for Tunnels with Replay Protection
        Enabled" in <xref target="Heist21" format="default"/> for the potential performance
        impact). This known problem is common to both IPsec <xref IPsec <xref target="RFC4301" format="default"/> and DTLS <xref DTLS <xref target="RFC9147" format="default"/> VPNs, given
        they use similar anti-replay window mechanisms. The mechanism used can
        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
        replay attack and discard all the packets behind the trailing edge of
        the window. The specifications of IPsec AH <xref Authentication Header (AH)
        <xref target="RFC4302" format="default"/> and ESP <xref Encapsulating Security Payload (ESP) <xref target="RFC4303" format="default"/> suggest that
        an implementer scales the size of the anti-replay window with
        interface speed, and DTLS v1.3 <xref v1.3 <xref target="RFC9147" format="default"/> says states that "The
        receiver SHOULD <bcp14>SHOULD</bcp14> pick a window large enough to handle any plausible
        reordering, which depends on the data rate." However, in practice, the
        size of a VPN's anti-replay window is not always scaled
        appropriately.</t>
        <t>If a VPN carrying traffic participating in the L4S experiment
        experiences inappropriate replay detection, the foremost remedy would
        be to ensure that the egress is configured to comply with the above
        window-sizing requirements.</t>
        <t>If an implementation of a VPN egress does not support a
        sufficiently large anti-replay window, e.g. due e.g., due to hardware
        limitations, one of the temporary alternatives listed in order of
        preference below might be feasible instead:</t>
        <ul spacing="normal">
          <li>If the VPN can be configured to classify packets into different
            SAs indexed by DSCP, apply the appropriate locally defined DSCPs
            to Classic and L4S packets. The DSCPs could be applied by the
            network (based on the least significant least-significant bit of the ECN IP-ECN field), or
            by the sending host. Such DSCPs would only need to survive as far
            as the VPN ingress.</li>
          <li>
            <t>If the above is not possible and it is necessary to use L4S,
            either of the following might be appropriate as a last
            resort:</t>
            <ul spacing="normal">
              <li>disable anti-replay protection at the VPN egress, after
                considering the security implications (it is mandatory to
                allow the anti-replay facility to be disabled in both IPsec
                and DTLS);</li> DTLS), or</li>
              <li>configure the tunnel ingress not to propagate ECN to the
                outer, which would lose the benefits of L4S and Classic ECN
                over the VPN.</li>
            </ul>
          </li>
          <!--ToDo: Perhaps better to delete this whole third bullet.-->
          </ul>
        <t>Modification to VPN implementations is outside the present scope,
        which is why this section has so far focused on reconfiguration.
        Although this document does not define any requirements for VPN
        implementations, determining whether there is a need for such
        requirements could be one aspect of L4S experimentation.</t>
      </section>
    </section>
    <section anchor="l4sid_expts" numbered="true" toc="default">
      <name>L4S Experiments</name>
      <t>This section describes open questions that L4S Experiments experiments ought to
      focus on. This section also documents outstanding open issues that will
      need to be investigated as part of L4S experimentation, given they could
      not be fully resolved during the WG working group phase. It also lists metrics that
      will need to be monitored during experiments (summarizing text elsewhere
      in L4S documents) and finally lists some potential future directions
      that researchers might wish to investigate.</t>

      <t>In addition to this section, i) the DualQ spec <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" spec <xref target="RFC9332" format="default"/> sets operational and
      management requirements for experiments with DualQ Coupled AQMs; AQMs, and
      General
      ii) general operational and management requirements for experiments with L4S
      congestion controls are given in Sections <xref target="l4sid_transport_req" format="default"/> format="counter"/>
      and <xref target="l4sid_network_req" format="default"/> format="counter"/> above, e.g. co-existence e.g., coexistence and
      scaling requirements, requirements and incremental deployment arrangements.</t>
      <t>The specification of each scalable Scalable congestion control will need to
      include protocol-specific requirements for configuration and monitoring
      performance during experiments. Appendix A of the guidelines in

      <xref target="RFC5706" format="default"/> sectionFormat="of" section="A"/> provides a helpful checklist.</t>
      <section numbered="true" toc="default">
        <name>Open Questions</name>
        <t>L4S experiments would be expected to answer the following
        questions:</t>
        <ul spacing="normal">
          <li>
            <t>Have all the parts of L4S been deployed, and if so, what
            proportion of paths support it?</t>
            <ul spacing="normal">
              <li>What types of L4S AQMs were deployed, e.g. FQ, e.g., FQ, coupled
                DualQ, uncoupled DualQ, other? And how prevalent was each?</li>
              <li>Are the signalling patterns emitted by the deployed AQMs in
                any way different from those expected when the Prague
                requirements for endpoints were written?</li>
            </ul>
          </li>
          <li>Does use of L4S over the Internet result in a significantly
            improved user experience?</li>
          <li>Has L4S enabled novel interactive applications?</li>
          <li>
            <t>Did use of L4S over the Internet result in improvements to the
            following metrics:</t>
            <ul spacing="normal">
              <li>queue delay (mean and 99th percentile) under various
                loads;</li>
              <li>utilization;</li>
              <li>starvation / fairness;</li> fairness; and</li>
              <li>scaling range of flow rates and RTTs?</li>
            </ul>
          </li>
          <li>How dependent was the performance of L4S service on the
            bottleneck bandwidth or the path RTT?</li>
          <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
            limitation of burstiness from upstream links was needed and/or was
            realized - -- both at senders and at links, especially radio links -- or
            how much did L4S target delay have to be increased to accommodate
            the bursts (see bullet #7 Item <xref target="l4sid_Prague_req-burstiness" format="counter"/> in <xref target="l4sid_congestion_response" format="default"/> target="l4sid_congestion_response"/> and see <xref target="l4sid_bursts_links_l4s_upstream" format="default"/>)?</li> target="l4sid_bursts_links_l4s_upstream"/>)?</li>
          <li>Is the initial experiment with mis-marked mis-identified bursty traffic at
            high RTT (see "Underutilization with Bursty Traffic" in <xref target="Heist21" format="default"/>) indicative of similar problems at lower RTTs
            and, RTTs,
            and if so, how effective is the suggested remedy in Appendix A.1
            of the <xref target="RFC9332" format="default" section="A.1" sectionFormat="of">the DualQ spec <xref target="I-D.ietf-tsvwg-aqm-dualq-coupled" format="default"/> spec</xref> (or possible other
            remedies)?</li>
          <li>
            <t>Was per-flow queue protection typically (un)necessary? </t>
            <ul spacing="normal">
              <li>How well did overload protection or queue protection
                work?</li>
            </ul>
          </li>
          <li>How
          <li><t>How well did L4S flows coexist with Classic flows when sharing
            a bottleneck?</li>
          <li> bottleneck?</t>
            <ul spacing="normal">
              <li>How frequently did problems arise?</li>
              <li>What caused any coexistence problems, and were any problems
                due to single-queue Classic ECN AQMs (this assumes
                single-queue Classic ECN AQMs can be distinguished from FQ
                ones)?</li>
            </ul>
          </li>
          <li>How prevalent were problems with the L4S service due to tunnels
            / encapsulations tunnels/encapsulations
            that do not support ECN decapsulation?</li>
          <li>How easy was it to implement a fully compliant L4S congestion
            control, over various different transport protocols (TCP, QUIC,
            RMCAT, etc.)?</li>
        </ul>
        <t>Monitoring for harm to other traffic, specifically bandwidth
        starvation or excess queuing delay, will need to be conducted
        alongside all early L4S experiments. It is hard, if not impossible,
        for an individual flow to measure its impact on other traffic. So such
        monitoring will need to be conducted using bespoke monitoring across
        flows and/or across classes of traffic.</t>
      </section>
      <section numbered="true" toc="default">
        <name>Open Issues</name>
        <ul spacing="normal">
          <li>What is the best way forward to deal with L4S over single-queue
            Classic ECN AQM bottlenecks, given current problems with
            misdetecting L4S AQMs as Classic ECN AQMs? See the L4S operational
            guidance <xref
            guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/>.</li>
          <li>Fixing the poor Interaction interaction between current L4S congestion
            controls and CoDel with only Classic ECN support during flow
            startup.
            Originally, this was due to a bug in the initialization
            of the congestion EWMA average in the
	    Linux implementation of TCP Prague.
            That was quickly fixed, which removed the main performance impact,
            but further improvement would be useful (either by (by modifying
            CoDel, either
            CoDel or Scalable congestion controls, or both).</li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>Future Potential</name>
        <t>Researchers might find that L4S opens up the following interesting
        areas for investigation:</t>
        <ul spacing="normal">
          <li>Potential
          <li>potential for faster convergence time and tracking of available
            capacity;</li>
          <li>Potential
          <li>potential for improvements to particular link technologies, technologies and
            cross-layer interactions with them;</li>
          <li>Potential
          <li>potential for using virtual queues, e.g. to e.g., to further reduce
            latency jitter, jitter or to leave headroom for capacity variation in
            radio networks;</li>
          <li>Development
          <li>development and specification of reverse path congestion
            control using L4S building blocks (e.g. AccECN, (e.g., AccECN or QUIC);</li>
          <li>Once
          <li>once queuing delay is cut down, what becomes the
            'second-longest pole in the tent' (other than the speed of
            light)?</li>
          <li>Novel
          <li>novel alternatives to the existing set of L4S AQMs;</li>
          <li>Novel AQMs; and</li>
          <li>novel applications enabled by L4S.</li>
        </ul>
      </section>
    </section>
    <section anchor="l4sid_IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>The semantics of the 01 codepoint of the ECN Field field of the IP header is are specified by
      the present
      this Experimental RFC. The process for an experimental Experimental RFC to
      assign this codepoint in the IP header (v4 and v6) is documented in
      Proposed Standard <xref target="RFC8311" format="default"/>, which updates the Proposed
      Standard <xref target="RFC3168" format="default"/>.</t>
      <t>When the present document is published as an RFC, IANA is asked to
      update

      <t>IANA has updated the 01 entry in the registry, "ECN Field (Bits 6-7)" to the
      following registry (see
      https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#ecn-field
      ):</t> <eref target="https://www.iana.org/assignments/dscp-registry/" brackets="angle"/>) as
      follows:</t>
      <table align="center">
	<name>ECN Field (Bits 6-7) Registry</name>
        <thead>
          <tr>
            <th align="left">Binary</th>
            <th align="left">Keyword</th>
            <th align="left">References</th> align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">01</td>
            <td align="left">ECT(1) (ECN-Capable Transport(1))[1]</td>
            <td align="left">
              <xref target="RFC8311" format="default"/> [RFC Errata 5399]
        [RFCXXXX]</td> [RFC Errata 5399]
        RFC 9331</td>
          </tr>
        </tbody>
      </table>
      <t>[XXXX
<t>[1] 	ECT(1) is the number that the RFC Editor assigns to the
      present document (this sentence to be removed by the RFC Editor)].</t> for experimental use only <xref target="RFC8311" section="4.2" sectionFormat="comma"/></t>
    </section>
    <section anchor="l4sid_Security_Considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Approaches to assure the integrity of signals using the new
      identifier are introduced in <xref in <xref target="l4sid_competing_integrity" format="default"/>. See the security considerations in
      the L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" architecture <xref target="RFC9330" format="default"/> for
      further discussion of mis-use misuse of the identifier, as well as extensive
      discussion of policing rate and latency in regard to L4S.</t>

      <t>Defining ECT(1) as the L4S identifier introduces a difference between
      the effects of ECT0 ECT(0) and ECT1 ECT(1) that RFC 3168 <xref target="RFC3168" format="default"/> previously defined as
      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
      operator chooses to locally apply the treatment associated with the
      opposite codepoint (see Sections <xref format="counter" target="l4sid_inclusion_dualq"/> and <xref format="counter" target="l4sid_exclusion_dualq"/>). These sections also describe the
      potential effects if a non-compliant or malicious network node does swap
      one to the other. The present specification does not change the effects
      of other unexpected transitions of the ECN IP-ECN field, which are still as
      described in Section 18 of RFC 3168.</t> <xref target="RFC3168" sectionFormat="of" section="18"/>.</t>
      <t>If the anti-replay window of a VPN egress is too small, it will
      mistake deliberate delay differences as a replay attack, attack and discard
      higher delay
      higher-delay packets (e.g. Classic) (e.g., Classic) carried within the same
      security association (SA) as low delay low-delay packets (e.g. L4S). (e.g., L4S). <xref target="l4sid_VPN_anti-replay" format="default"/> recommends that VPNs used in L4S
      experiments are configured with a sufficiently large anti-replay window,
      as required by the relevant specifications. It also discusses other
      alternatives.</t>
      <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
      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
      enough of the user's Classic (C) traffic (if they are receiving any) to
      cause a significant rate reduction. While the user is actively
      downloading C traffic, the attacker sends C traffic into the VPN to fill
      the remainder of the bottleneck link, then sends intermittent L4S
      packets to maximize the chance of exceeding the VPN's replay window. The
      user can prevent this attack by following the recommendations in <xref target="l4sid_VPN_anti-replay" format="default"/>.<!--ToDo: I'm not sure this para is warranted.
It's a bit lame to say there's an attack if you don't follow advice, and the solution to the attack is to follow the advice.--> format="default"/>.
      </t>
      <t>The recommendation to detect loss in time units prevents the
      ACK-splitting attacks described in <xref target="Savage-TCP" format="default"/>.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
  <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="PRAGUE-CC"/>
<displayreference target="I-D.cardwell-iccrg-bbr-congestion-control" to="BBR-CC"/>
<displayreference target="I-D.mathis-iccrg-relentless-tcp" to="RELENTLESS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml"/>

      </references>
      <references>
        <name>Informative References</name>

<!-- [I-D.ietf-tsvwg-aqm-dualq-coupled]; companion document 9332 - title matches as of 1/17/23 -->
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> anchor='RFC9332' target='https://www.rfc-editor.org/info/rfc9332'>
<front>
            <title>Key words
<title>Dual-Queue Coupled Active Queue Management (AQM) for use in RFCs to Indicate Requirement Levels</title> Low Latency, Low Loss, and Scalable Throughput (L4S)</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/> initials='K' surname='De Schepper' fullname='Koen De Schepper'>
<organization />
</author>
<author initials='B' surname='Briscoe' fullname='Bob Briscoe' role="editor">
<organization />
</author>
<author initials='G' surname='White' fullname='Greg White'>
<organization />
</author>
    <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This month="January" year="2023"/>
</front>
<seriesInfo name="RFC" value="9332"/>
<seriesInfo name="DOI" value="10.17487/RFC9332"/>
</reference>

<!-- [I-D.ietf-tsvwg-l4s-arch]; companion document defines these words 9330 - title matches as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion of 1/17/23 -->
<reference anchor='RFC9330' target='https://www.rfc-editor.org/info/rfc9330'>
<front>
<title>Low Latency, Low Loss, and suggestions for improvements.</t>
            </abstract> Scalable Throughput (L4S) Internet Service: Architecture</title>
<author initials='B' surname='Briscoe' fullname='Bob Briscoe' role='editor' />
<author initials='K' surname='De Schepper' fullname='Koen De Schepper' />
<author initials='M' surname='Bagnulo' fullname='Marcelo Bagnulo' />
<author initials='G' surname='White' fullname='Greg White' />
    <date month="January" year="2023"/>
</front>
<seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/> value="9330"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> value="10.17487/RFC9330"/>
</reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3540.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4341.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4342.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5622.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5865.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5562.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5706.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6077.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6675.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7560.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7567.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8290.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8298.xml"/>

<!-- [I-D.ietf-tcpm-accurate-ecn] IESG state I-D Exists as of 1/17/23-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tcpm-accurate-ecn.xml"/>

<!-- [I-D.ietf-tsvwg-ecn-encap-guidelines] Expired as of 1/17/23 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tsvwg-ecn-encap-guidelines.xml"/>

<!-- [I-D.ietf-tsvwg-rfc6040update-shim] Expired as of 1/17/23 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tsvwg-rfc6040update-shim.xml"/>

<!-- [I-D.ietf-trill-ecn-support] in MISSREF state as of 1/17/23. xi:include
incorrectly shows Eastlake's name as "D. E. Eastlake" but author name
preferences show he wants "D. Eastlake 3rd" -->
<reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3168" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"> anchor="I-D.ietf-trill-ecn-support">
  <front>
            <title>The Addition
    <title>TRILL (TRansparent Interconnection of Explicit Lots of Links): ECN (Explicit Congestion Notification (ECN) to IP</title>
            <author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
              <organization/>
            </author> Notification) Support</title>
    <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/> initials="D." surname="Eastlake 3rd" fullname="Donald Eastlake 3rd">
      <organization>Huawei</organization>
    </author>
    <author initials="D." surname="Black" fullname="D. Black">
              <organization/> initials="B." surname="Briscoe" fullname="Bob Briscoe">
      <organization>CableLabs</organization>
    </author>
    <date year="2001" month="September"/>
            <abstract>
              <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use month="February" day="25" year="2018"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-trill-ecn-support-07"/>
</reference>

<!-- [I-D.stewart-tsvwg-sctpecn] IESG state Expired as of two bits in 1/17/23. xi:include incorrectly
shows Stewart's name as "R. R. Stewart" when the IP header.  [STANDARDS-TRACK]</t>
            </abstract> draft only has
"R. Stewart" -->
<reference anchor="I-D.stewart-tsvwg-sctpecn">
  <front>
    <title>ECN for Stream Control Transmission Protocol (SCTP)</title>
    <author initials="R." surname="Stewart" fullname="Randall R. Stewart">
      <organization>Adara Networks</organization>
    </author>
    <author initials="M." surname="Tüxen" fullname="Michael Tüxen">
      <organization>Muenster Univ. of Appl. Sciences</organization>
    </author>
    <author initials="X." surname="Dong" fullname="Xuesong Dong">
      <organization>Huawei</organization>
    </author>
    <date month="January" day="15" year="2014"/>
  </front>
  <seriesInfo name="RFC" value="3168"/>
          <seriesInfo name="DOI" value="10.17487/RFC3168"/> name="Internet-Draft" value="draft-stewart-tsvwg-sctpecn-05"/>
</reference>

<!-- [I-D.briscoe-tsvwg-l4s-diffserv] IESG state Expired as of 1/17/23. xi:include wrong date: -->
<reference anchor="RFC4774" target="https://www.rfc-editor.org/info/rfc4774" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml"> anchor="I-D.briscoe-tsvwg-l4s-diffserv">
  <front>
            <title>Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field</title>
    <title>Interactions between Low Latency, Low Loss, Scalable Throughput (L4S) and Differentiated Services</title>
    <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/> fullname="Bob Briscoe" surname="Briscoe" initials="B">
      <organization>CableLabs</organization>
    </author>
    <date year="2006" month="November"/>
            <abstract>
              <t>There have been a number month="November" day="1" year="2018"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-briscoe-tsvwg-l4s-diffserv-02"/>
</reference>

<!-- [I-D.ietf-tsvwg-nqb] IESG state I-D Exists.-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tsvwg-nqb.xml"/>

<!-- [I-D.ietf-tsvwg-l4sops] IESG state	I-D Exists as of proposals for alternate semantics 1/17/23. xi:include missing editor role-->
<reference anchor="I-D.ietf-tsvwg-l4sops">
  <front>
    <title>Operational Guidance for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168.  This document discusses some Deployment of the issues L4S in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics.  This document evolved
    </title>
    <author fullname="Greg White" surname="White" initials="G" role="editor">
      <organization>CableLabs</organization>
    </author>
    <date month="April" day="28" year="2022"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-l4sops-03"/>
</reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml"/>

<!-- [I-D.ietf-tcpm-generalized-ecn] IESG state I-D Exists as a result of discussions with the authors of one recent proposal for such alternate semantics.  This document specifies an Internet Best Current Practices 1/1/7/23 -->
<xi:include
    href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tcpm-generalized-ecn.xml"/>

        <reference anchor="ARED01" target="https://www.icsi.berkeley.edu/icsi/node/2032">
          <front>
            <title>Adaptive RED: An Algorithm for Increasing the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract> Robustness of
          RED's Active Queue Management</title>
            <author fullname="Sally Floyd" initials="S." surname="Floyd">
              <organization>ACIRI</organization>
            </author>
            <author fullname="Ramakrishna Gummadi" initials="R." surname="Gummadi">
              <organization>ACIRI</organization>
            </author>
            <author fullname="S. Shenker" initials="S." surname="Shenker">
              <organization>ACIRI</organization>
            </author>
            <date month="August" year="2001"/>
          </front>
          <seriesInfo name="BCP" value="124"/>
          <seriesInfo name="RFC" value="4774"/>
          <seriesInfo name="DOI" value="10.17487/RFC4774"/>
          <refcontent>ACIRI Technical Report 301</refcontent>
        </reference>

<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 Wrong date.-->
<reference anchor="RFC6679" target="https://www.rfc-editor.org/info/rfc6679" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml"> anchor="I-D.sridharan-tcpm-ctcp">
  <front>
            <title>Explicit
    <title>Compound TCP: A New TCP Congestion Notification (ECN) Control for RTP over UDP</title> High-Speed and Long Distance Networks
    </title>
    <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization/>
            </author>
            <author initials="I." surname="Johansson" fullname="I. Johansson">
              <organization/> surname="Sridharan" fullname="Murari Sridharan">
      <organization>Microsoft</organization>
    </author>
    <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization/> initials="K." surname="Tan" fullname="Kun Tan">
      <organization>Microsoft Research</organization>
    </author>
    <author initials="P." surname="O'Hanlon" fullname="P. O'Hanlon">
              <organization/> initials="D." surname="Bansal" fullname="Deepak Bansal">
      <organization>Microsoft</organization>
    </author>
    <author initials="K." surname="Carlberg" fullname="K. Carlberg">
              <organization/> initials="D." surname="Thaler" fullname="Dave Thaler">
      <organization>Microsoft</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 feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE).  Signalling and procedures for negotiation of capabilities and initialisation methods are also defined.  [STANDARDS-TRACK]</t>
            </abstract> month="November" day="3" year="2008"/>
  </front>
  <seriesInfo name="RFC" value="6679"/>
          <seriesInfo name="DOI" value="10.17487/RFC6679"/> name="Internet-Draft" value="draft-sridharan-tcpm-ctcp-02"/>
</reference>
      </references>
      <references>
        <name>Informative References</name>

<!-- [I-D.briscoe-docsis-q-protection] in MISSREF state as of 1/17/23. xi:include is missing editor role -->
<reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2474" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"> anchor="I-D.briscoe-docsis-q-protection">
  <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>
    <title>The DOCSIS® Queue Protection Algorithm to Preserve Low Latency</title>
    <author initials="F." surname="Baker" fullname="F. Baker">
              <organization/> fullname="Bob Briscoe" role="editor">
      <organization>Independent</organization>
    </author>
    <author initials="D." surname="Black" fullname="D. Black">
              <organization/> fullname="Greg White">
      <organization>CableLabs</organization>
    </author>
    <date year="1998" month="December"/>
            <abstract>
              <t>This document defines the IP header field, called the DS (for differentiated services) field.  [STANDARDS-TRACK]</t>
            </abstract> day="13" month="May" year="2022"/>
  </front>
  <seriesInfo name="RFC" value="2474"/>
          <seriesInfo name="DOI" value="10.17487/RFC2474"/> name="Internet-Draft" value="draft-briscoe-docsis-q-protection-06"/>
</reference>

<!-- [I-D.briscoe-iccrg-prague-congestion-control] Expired as of 1/17/23. Missing editor role. -->
<reference anchor="RFC2309" target="https://www.rfc-editor.org/info/rfc2309" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml"> anchor="I-D.briscoe-iccrg-prague-congestion-control">
  <front>
            <title>Recommendations on Queue Management and
    <title>Prague Congestion Avoidance in the Internet</title> Control</title>
    <author initials="B." surname="Braden" fullname="B. Braden">
              <organization/> fullname="Koen De Schepper" surname="De Schepper" initials="K.">
      <organization>Nokia Bell Labs</organization>
    </author>
    <author initials="D." surname="Clark" fullname="D. Clark">
              <organization/> fullname="Olivier Tilmans">
      <organization>Nokia Bell Labs</organization>
    </author>
    <author initials="J." surname="Crowcroft" fullname="J. Crowcroft">
              <organization/> 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="B." surname="Davie" fullname="B. Davie">
              <organization/> initials="N." surname="Cardwell" fullname="Neal Cardwell">
      <organization>Google</organization>
    </author>
    <author initials="S." surname="Deering" fullname="S. Deering">
              <organization/> initials="Y." surname="Cheng" fullname="Yuchung Cheng">
      <organization>Google</organization>
    </author>
    <author initials="D." surname="Estrin" fullname="D. Estrin">
              <organization/> initials="S." surname="Hassas Yeganeh" fullname="Soheil Hassas Yeganeh">
      <organization>Google</organization>
    </author>
    <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/> initials="I." surname="Swett" fullname="Ian Swett">
      <organization>Google</organization>
    </author>
    <author initials="V." surname="Jacobson" fullname="V. fullname="Van Jacobson">
              <organization/>
      <organization>Google</organization>
    </author>
    <date month="March" day="7" year="2022"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-congestion-control-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>
            <title>TCP BBR v2 Alpha/Preview Release</title>
            <author/>
	    <date month="June" year="2022"/>
          </front>
          <refcontent>commit 17700ca</refcontent>
        </reference>

      <reference anchor="DCttH19" target="https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf">
          <front>
            <title>'Data Centre to the Home': Ultra-Low Latency for All</title>
            <author initials="G." surname="Minshall" fullname="G. Minshall">
              <organization/> fullname="Koen De Schepper" initials="K." surname="De Schepper">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author initials="C." surname="Partridge" fullname="C. Partridge">
              <organization/> fullname="Olga Bondarenko" initials="O." surname="Bondarenko">
              <organization>Simula Research Lab</organization>
            </author>
            <author initials="L." surname="Peterson" fullname="L. Peterson">
              <organization/> fullname="Olivier" 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="July" year="2019"/>
          </front>
          <refcontent>Updated RITE project Technical Report</refcontent>
        </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="Ramakrishnan" fullname="K. Ramakrishnan">
              <organization/> surname="De Schepper">
            <organization>Nokia Bell Labs</organization>
          </author>
          <author initials="S." surname="Shenker" fullname="S. Shenker">
              <organization/> fullname="Olga Albisser" initials="O." surname="Albisser">
            <organization>Simula Research Lab</organization>
          </author>
          <author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
              <organization/> fullname="Olivier Tilmans" initials="O." surname="Tilmans">
            <organization>Nokia Bell Labs</organization>
          </author>
          <author initials="L." surname="Zhang" fullname="L. Zhang">
              <organization/> fullname="Bob Briscoe" initials="B." surname="Briscoe">
            <organization>Independent (bobbriscoe.net)</organization>
          </author>
          <date year="1998" month="April"/>
            <abstract>
              <t>This memo presents two recommendations to the Internet community 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 Internet.  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 information for the Internet community.  It does not specify an Internet standard of any kind.</t>
            </abstract> month="September" year="2022"/>
        </front>
          <seriesInfo name="RFC" value="2309"/>
          <seriesInfo name="DOI" value="10.17487/RFC2309"/> value="10.48550/arXiv.2209.01078"/>
        <refcontent>Preprint submitted to IEEE/ACM Transactions on Networking</refcontent>
      </reference>

        <reference anchor="RFC3540" target="https://www.rfc-editor.org/info/rfc3540" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3540.xml"> anchor="PI2" target="https://dl.acm.org/citation.cfm?doid=2999572.2999578">
          <front>
            <title>Robust Explicit Congestion Notification (ECN) Signaling with Nonces</title>
            <title>PI^2: A Linearized AQM for both Classic and Scalable
          TCP</title>
            <author initials="N." surname="Spring" fullname="N. Spring">
              <organization/> fullname="Koen De Schepper" initials="K." surname="De Schepper">
              <organization>Bell Labs</organization>
            </author>
            <author initials="D." surname="Wetherall" fullname="D. Wetherall">
              <organization/> fullname="Olga Bondarenko" initials="O." surname="Bondarenko">
              <organization>Simula Research Lab</organization>
            </author>
            <author initials="D." surname="Ely" fullname="D. Ely">
              <organization/> fullname="Ing-jyh Tsang" initials="I." surname="Tsang">
              <organization>Bell Labs</organization>
            </author>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>BT</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 unfair share of network bandwidth.  The ECN-nonce uses the two ECN-Capable Transport (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 memo defines an Experimental Protocol for the Internet community.</t>
            </abstract> month="December" year="2016"/>
          </front>
	  <seriesInfo name="RFC" value="3540"/>
          <seriesInfo name="DOI" value="10.17487/RFC3540"/> value="10.1145/2999572.2999578"/>
          <refcontent>Proceedings of ACM CoNEXT 2016, pp. 105-119</refcontent>
        </reference>

        <reference anchor="RFC3246" target="https://www.rfc-editor.org/info/rfc3246" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3246.xml"> anchor="VCP" target="https://doi.acm.org/10.1145/1080091.1080098">
          <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>
            <title>One more bit is enough</title>
            <author initials="K." surname="Benson" fullname="K. Benson"> fullname="Yong Xia" initials="Y." surname="Xia">
              <organization/>
            </author>
            <author initials="J.Y." surname="Le Boudec" fullname="J.Y. Le Boudec"> fullname="Lakshminarayanan Subramanian" initials="L." surname="Subramanian">
              <organization/>
            </author>
            <author initials="W." surname="Courtney" fullname="W. Courtney"> fullname="Ion Stoica" initials="I." surname="Stoica">
              <organization/>
            </author>
            <author fullname="Shivkumar Kalyanaraman" 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"> surname="Kalyanaraman">
              <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 Services 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 certain configured rate. This document obsoletes RFC 2598.  [STANDARDS-TRACK]</t>
            </abstract> month="August" year="2005"/>
          </front>
          <seriesInfo name="RFC" value="3246"/>
          <seriesInfo name="DOI" value="10.17487/RFC3246"/> value="10.1145/1080091.1080098"/>
	  <refcontent>SIGCOMM '05: Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 37–48</refcontent>
        </reference>

        <reference anchor="RFC3649" target="https://www.rfc-editor.org/info/rfc3649" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml"> anchor="QV" target="https://riteproject.files.wordpress.com/2015/12/rite-deliverable-2-3.pdf">
          <front>
            <title>HighSpeed TCP for Large Congestion Windows</title>
            <title>Report on Prototype Development and Evaluation of Network and Interaction Techniques</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/> fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>BT</organization>
            </author>
            <author fullname="Per Hurtig" initials="P." surname="Hurtig">
              <organization>Karlstad University</organization>
            </author>
            <date year="2003" month="December"/>
            <abstract>
              <t>The proposals in this document are experimental.  While they may be deployed in the current Internet, they do not represent a consensus that this 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 month="September" year="2015"/>
          </front>
          <refcontent>RITE Technical Report, Deliverable 2.3, Appendix C.2: "Up to TCP's congestion control mechanism for use with TCP connections Speed with large congestion windows.  The congestion control mechanisms Queue View"</refcontent>
        </reference>

        <reference anchor="Alizadeh-stability" target="https://dl.acm.org/doi/10.1145/1993744.1993753">
          <front>
            <title>Analysis of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments.  For example, for a Standard TCP connection with 1500-byte packets DCTCP: Stability, Convergence, and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window
          Fairness</title>
            <author fullname="Mohamed Alizadeh" initials="M." surname="Alizadeh"/>
            <author fullname="Adel Javanmard" initials="A." surname="Javanmard"/>
            <author fullname="Balaji Prabhakar" initials="B." surname="Prabhakar"/>
            <date month="June" year="2011"/>
          </front>
	  <seriesInfo name="DOI" value="10.1145/1993744.1993753"/>
          <refcontent>SIGMETRICS '11: Proceedings of 83,333 segments, the ACM SIGMETRICS Joint International Conference on Measurement and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours).  This is widely acknowledged as an unrealistic constraint.  To address his limitation Modeling of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.</t>
            </abstract> Computer Systems, pp. 73-84</refcontent>
          <format target="https://people.csail.mit.edu/alizadeh/papers/dctcp_analysis-sigmetrics11.pdf" type="PDF"/>
        </reference>

        <reference anchor="TCPPrague" target="https://www.ietf.org/mail-archive/web/tcpprague/current/msg00001.html">
          <front>
            <title>Notes: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40,
          Prague</title>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Simula</organization>
            </author>
            <date month="July" year="2015"/>
          </front>
          <seriesInfo name="RFC" value="3649"/>
          <seriesInfo name="DOI" value="10.17487/RFC3649"/>
          <refcontent>message to the tcpPrague mailing list</refcontent>
        </reference>

        <reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4301" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"> anchor="sub-mss-prob" target="https://arxiv.org/abs/1904.07598">
          <front>
            <title>Security Architecture
            <title>Scaling TCP's Congestion Window for the Internet Protocol</title> Small Round Trip
          Times</title>
            <author initials="S." surname="Kent" fullname="S. Kent">
              <organization/> fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>BT</organization>
            </author>
            <author fullname="Koen De Schepper" initials="K." surname="Seo" fullname="K. Seo">
              <organization/> surname="De Schepper">
              <organization>Bell Labs</organization>
            </author>
            <date year="2005" month="December"/>
            <abstract>
              <t>This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer.  This document obsoletes RFC 2401 (November 1998).  [STANDARDS-TRACK]</t>
            </abstract> month="May" year="2015"/>
          </front>
	  <seriesInfo name="RFC" value="4301"/>
          <seriesInfo name="DOI" value="10.17487/RFC4301"/> value="10.48550/arXiv.1904.07598"/>
          <refcontent>BT Technical Report: TR-TUB8-2015-002</refcontent>
        </reference>

        <reference anchor="RFC4302" target="https://www.rfc-editor.org/info/rfc4302" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"> anchor="ecn-fallback" target="https://arxiv.org/abs/1911.00710">
          <front>
            <title>IP Authentication Header</title>
            <title>TCP Prague Fall-back on Detection of a Classic ECN
          AQM</title>
            <author initials="S." surname="Kent" fullname="S. Kent">
              <organization/> fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <date year="2005" month="December"/>
            <abstract>
              <t>This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4
            <author fullname="Asad Sajjad Ahmed" initials="A." surname="Ahmed">
              <organization>Simula and IPv6.  This document obsoletes RFC 2402 (November 1998).  [STANDARDS-TRACK]</t>
            </abstract> Uni Oslo</organization>
            </author>
            <date month="February" year="2021"/>
          </front>
	  <seriesInfo name="RFC" value="4302"/>
          <seriesInfo name="DOI" value="10.17487/RFC4302"/> value="10.48550/arXiv.1911.00710"/>
          <refcontent>Technical Report: TR-BB-2019-002</refcontent>
        </reference>

        <reference anchor="RFC4303" target="https://www.rfc-editor.org/info/rfc4303" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"> anchor="Ahmed19" target="https://www.duo.uio.no/handle/10852/70966">
          <front>
            <title>IP Encapsulating Security Payload (ESP)</title>
            <title>Extending TCP for Low Round Trip Delay</title>
            <author initials="S." surname="Kent" fullname="S. Kent">
              <organization/> fullname="Asad Sajjad Ahmed" initials="A.S." surname="Ahmed">
              <organization>Simula and Uni Oslo</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 partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998).  [STANDARDS-TRACK]</t>
            </abstract> month="August" year="2019"/>
          </front>
          <seriesInfo name="RFC" value="4303"/>
          <seriesInfo name="DOI" value="10.17487/RFC4303"/>
          <refcontent>Master's Thesis, University of Oslo</refcontent>
        </reference>

        <reference anchor="RFC4340" target="https://www.rfc-editor.org/info/rfc4340" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"> anchor="A2DTCP" target="https://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6871352">
          <front>
            <title>Datagram Congestion Control Protocol (DCCP)</title>
            <title>Adaptive-Acceleration Data Center TCP</title>
            <author fullname="Tao Zhang" initials="T." surname="Zhang">
              <organization/>
            </author>
            <author initials="E." surname="Kohler" fullname="E. Kohler"> fullname="Jianxin Wang" initials="J." surname="Wang">
              <organization/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley"> fullname="Jiawei Huang" initials="J." surname="Huang">
              <organization/>
            </author>
            <author initials="S." surname="Floyd" fullname="S. Floyd"> fullname="Yi Huang" initials="Y." surname="Huang">
              <organization/>
            </author>
            <author fullname="Jianer Chen" initials="J." surname="Chen">
              <organization/>
            </author>
            <author fullname="Yi Pan" initials="Y." surname="Pan">
              <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-controlled unreliable datagrams.  DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.  [STANDARDS-TRACK]</t>
            </abstract> month="June" year="2015"/>
          </front>
	  <seriesInfo name="RFC" value="4340"/>
          <seriesInfo name="DOI" value="10.17487/RFC4340"/> value="10.1109/TC.2014.2345393"/>
          <refcontent>IEEE Transactions on Computers, Volume 64, Issue 6, pp. 1522-1533</refcontent>
        </reference>

        <reference anchor="RFC4341" target="https://www.rfc-editor.org/info/rfc4341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4341.xml"> anchor="PragueLinux" target="https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s">
          <front>
            <title>Profile
            <title>Implementing the 'TCP Prague' Requirements for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control</title> L4S</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/> fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <author initials="E." surname="Kohler" fullname="E. Kohler">
              <organization/> fullname="Koen De Schepper" initials="K." surname="De Schepper">
              <organization>Nokia Bell Labs</organization>
            </author>
            <date year="2006" month="March"/>
            <abstract>
              <t>This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP).  CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical
            <author fullname="Olga Albisser" initials="O." surname="Albisser">
              <organization>Simula</organization>
            </author>
            <author fullname="Joakim Misund" initials="J." surname="Misund">
              <organization>University of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control.  [STANDARDS-TRACK]</t>
            </abstract> Oslo</organization>
            </author>
            <author fullname="Olivier Tilmans" initials="O." surname="Tilmans">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
              <organization>ETHZ</organization>
            </author>
            <author fullname="Asad Sajjad Ahmed" initials="A." surname="Ahmed">
              <organization>Simula</organization>
            </author>
            <date month="March" year="2019"/>
          </front>
          <seriesInfo name="RFC" value="4341"/>
          <seriesInfo name="DOI" value="10.17487/RFC4341"/>
          <refcontent>Proceedings of Linux Netdev 0x13</refcontent>
          <format target="https://www.files.netdevconf.info/f/4d6939d5f1fb404fafd1/?dl=1" type="PDF"/>
        </reference>

        <reference anchor="RFC4342" target="https://www.rfc-editor.org/info/rfc4342" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4342.xml"> anchor="LinuxPacedChirping" target="https://legacy.netdevconf.info/0x13/session.html?talk-chirp">
          <front>
            <title>Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)</title>
            <title>Paced Chirping - Rethinking TCP start-up</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/> fullname="Joakim Misund" initials="J." surname="Misund">
              <organization>University of Oslo</organization>
            </author>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <date month="March" year="2019"/>
          </front>
          <refcontent>Proceedings of Linux Netdev 0x13</refcontent>
        </reference>

        <reference anchor="TCP-CA" target="https://ee.lbl.gov/papers/congavoid.pdf">
	  <front>
	    <title>Congestion Avoidance and Control</title>
	    <author initials="E." surname="Kohler" fullname="E. Kohler"> fullname="Van Jacobson" initials="V." surname="Jacobson">
	      <organization/>
	    </author>
	     <author initials="J." surname="Padhye" fullname="J. Padhye"> fullname="Michael J. Karels" initials="M. J." surname="Karels">
	      <organization/>
	    </author>
	    <date year="2006" month="March"/>
            <abstract>
              <t>This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP).  CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.  [STANDARDS-TRACK]</t>
            </abstract> month="November" year="1988"/>
	  </front>
          <seriesInfo name="RFC" value="4342"/>
          <seriesInfo name="DOI" value="10.17487/RFC4342"/>
	  <refcontent>Laurence Berkeley Labs Technical Report</refcontent>
	</reference>

        <reference anchor="RFC5033" target="https://www.rfc-editor.org/info/rfc5033" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5033.xml"> anchor="Savage-TCP" target="https://dl.acm.org/doi/abs/10.1145/505696.505704">
          <front>
            <title>Specifying New
            <title>TCP Congestion Control Algorithms</title> with a Misbehaving Receiver</title>
            <author fullname="Stefan Savage" initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/> surname="Savage">
              <organization>University of Washington</organization>
            </author>
            <author initials="M." surname="Allman" fullname="M. Allman">
              <organization/> fullname="Neal Cardwell" initials="N." surname="Cardwell">
              <organization>University of Washington</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).  Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles.  Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control.  Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals.  The goal
            <author fullname="David Wetherall" initials="D." surname="Wetherall">
              <organization>University of this document is to provide guidance for considering alternate congestion control algorithms within the IETF.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract> Washington</organization>
            </author>
            <author fullname="Tom Anderson" initials="T." surname="Anderson">
              <organization>University of Washington</organization>
            </author>
            <date month="October" year="1999"/>
          </front>
          <seriesInfo name="BCP" value="133"/>
          <seriesInfo name="RFC" value="5033"/>
          <seriesInfo name="DOI" value="10.17487/RFC5033"/> value="10.1145/505696.505704"/>
	  <refcontent>ACM SIGCOMM Computer Communication Review, Volume 29, Issue 5, pp. 71–78</refcontent>
        </reference>

<reference anchor="RFC5129" target="https://www.rfc-editor.org/info/rfc5129" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml"> anchor="Heist21" target="https://github.com/heistp/l4s-tests">
          <front>
            <title>Explicit Congestion Marking in MPLS</title>
            <author initials="B." surname="Davie" fullname="B. Davie">
            <title>L4S Tests</title>
            <author>
              <organization/>
            </author>
            <date month="August" year="2021"/>
          </front>
          <refcontent>commit e21cd91</refcontent>
        </reference>

        <reference anchor="SCReAM-L4S" target="https://github.com/EricssonResearch/scream">
          <front>
            <title>SCReAM</title>
            <author/>
            <date month="November" year="2022"/>
          </front>
	  <refcontent>commit 140e292</refcontent>
        </reference>

      <reference anchor="DualPI2Linux" target="https://www.netdevconf.org/0x13/session.html?talk-DUALPI2-AQM">
        <front>
          <title>DUALPI2 - Low Latency, Low Loss and Scalable (L4S)
          AQM</title>
          <author fullname="Olga Albisser" initials="O." surname="Albisser">
            <organization>Simula Research Lab</organization>
          </author>
          <author fullname="Koen De Schepper" initials="K." surname="De Schepper">
            <organization>Nokia Bell Labs</organization>
          </author>
          <author fullname="Bob Briscoe" initials="B." surname="Briscoe" fullname="B. Briscoe">
              <organization/> surname="Briscoe">
            <organization>Independent</organization>
          </author>
          <author initials="J." surname="Tay" fullname="J. Tay">
              <organization/> fullname="Olivier Tilmans" initials="O." surname="Tilmans">
            <organization>Nokia Bell Labs</organization>
          </author>
          <author fullname="Henrik Steen" initials="H." surname="Steen">
            <organization>Simula Research Lab</organization>
          </author>
          <date year="2008" month="January"/>
            <abstract>
              <t>RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header.  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 Notification (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> month="March" year="2019"/>
        </front>
          <seriesInfo name="RFC" value="5129"/>
          <seriesInfo name="DOI" value="10.17487/RFC5129"/>
        <refcontent>Proceedings of Linux Netdev 0x13</refcontent>
        <format target="https://www.files.netdevconf.org/f/febbe8c6a05b4ceab641/?dl=1" type="PDF"/>
      </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/rfc5348" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml"> anchor="COBALT" target="https://ieeexplore.ieee.org/abstract/document/8847054">
        <front>
            <title>TCP Friendly Rate Control (TFRC): Protocol Specification</title>
          <title>Design and Evaluation of COBALT Queue Discipline</title>
          <author fullname="Jendaipou Palmei" initials="J." surname="Palmei">
            <organization/>
          </author>
          <author fullname="Shefali Gupta" initials="S." surname="Floyd" fullname="S. Floyd"> surname="Gupta">
            <organization/>
          </author>
          <author initials="M." surname="Handley" fullname="M. Handley"> fullname="Pasquale Imputato" initials="P." surname="Imputato">
            <organization/>
          </author>
          <author fullname="Jonathan Morton" initials="J." surname="Padhye" fullname="J. Padhye"> surname="Morton">
            <organization/>
          </author>
          <author initials="J." surname="Widmer" fullname="J. Widmer"> fullname="Mohit P. Tahiliani" initials="M. P." surname="Tahiliani">
            <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 year="2008" month="September"/>
            <abstract>
              <t>This document specifies TCP Friendly Rate Control (TFRC).  TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment.  It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.</t>
              <t>This document obsoletes RFC 3448 and updates RFC 4342.  [STANDARDS-TRACK]</t>
            </abstract> month="July" year="2019"/>
        </front>
	<seriesInfo name="RFC" value="5348"/>
          <seriesInfo name="DOI" value="10.17487/RFC5348"/> value="10.1109/LANMAN.2019.8847054"/>
	<refcontent>IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN)</refcontent>
      </reference>

      <reference anchor="RFC5622" target="https://www.rfc-editor.org/info/rfc5622" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5622.xml"> anchor="Dukkipati06" target="https://dl.acm.org/doi/10.1145/1111322.1111336">
        <front>
            <title>Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)</title>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/>
            </author>
            <author initials="E." surname="Kohler" fullname="E. Kohler">
              <organization/>
            </author>
            <date year="2009" month="August"/>
            <abstract>
              <t>This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP).  CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets.  CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time.  The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion.  CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.  This memo defines an  Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5622"/>
          <seriesInfo name="DOI" value="10.17487/RFC5622"/>
        </reference>
        <reference anchor="RFC5865" target="https://www.rfc-editor.org/info/rfc5865" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5865.xml">
          <front>
            <title>A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic</title>
            <author initials="F." surname="Baker" fullname="F. Baker">
              <organization/>
            </author>
            <author initials="J." surname="Polk" fullname="J. Polk">
              <organization/>
            </author>
            <author initials="M." surname="Dolly" fullname="M. Dolly">
              <organization/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t>This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic.  This traffic class conforms to the Expedited Forwarding Per-Hop Behavior.  This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission.  This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5865"/>
          <seriesInfo name="DOI" value="10.17487/RFC5865"/>
        </reference>
        <reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4960" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
          <front>
            <title>Stream Control Transmission Protocol</title>
            <author initials="R." surname="Stewart" fullname="R. Stewart" role="editor">
              <organization/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t>This document obsoletes RFC 2960 and RFC 3309.  It describes the Stream Control Transmission Protocol (SCTP).  SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t>
              <t>SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP.  It offers the following services to its users:</t>
              <t>--  acknowledged error-free non-duplicated transfer of user data,</t>
              <t>--  data fragmentation to conform to discovered path MTU size,</t>
              <t>--  sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</t>
              <t>--  optional bundling of multiple user messages into a single SCTP packet, and</t>
              <t>--  network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</t>
              <t> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4960"/>
          <seriesInfo name="DOI" value="10.17487/RFC4960"/>
        </reference>
        <reference anchor="RFC5562" target="https://www.rfc-editor.org/info/rfc5562" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5562.xml">
          <front>
            <title>Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets</title>
            <author initials="A." surname="Kuzmanovic" fullname="A. Kuzmanovic">
              <organization/>
            </author>
            <author initials="A." surname="Mondal" fullname="A. Mondal">
              <organization/>
            </author>
            <author initials="S." surname="Floyd" fullname="S. Floyd">
              <organization/>
            </author>
            <author initials="K." surname="Ramakrishnan" fullname="K. Ramakrishnan">
              <organization/>
            </author>
            <date year="2009" month="June"/>
            <abstract>
              <t>The proposal in this document is Experimental.  While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets.</t>
              <t>This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable.  For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets.  However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN.  Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network.  The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable.  If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network.  If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer).  This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5562"/>
          <seriesInfo name="DOI" value="10.17487/RFC5562"/>
        </reference>
        <reference anchor="RFC5681" target="https://www.rfc-editor.org/info/rfc5681" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
          <front>
            <title>TCP Congestion Control</title>
            <author initials="M." surname="Allman" fullname="M. Allman">
              <organization/>
            </author>
            <author initials="V." surname="Paxson" fullname="V. Paxson">
              <organization/>
            </author>
            <author initials="E." surname="Blanton" fullname="E. Blanton">
              <organization/>
            </author>
            <date year="2009" month="September"/>
            <abstract>
              <t>This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.  In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.  This document obsoletes RFC 2581.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5681"/>
          <seriesInfo name="DOI" value="10.17487/RFC5681"/>
        </reference>
        <reference anchor="RFC5706" target="https://www.rfc-editor.org/info/rfc5706" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5706.xml">
          <front>
            <title>Guidelines for Considering Operations and Management of New Protocols 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 document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered.  This memo provides information for the Internet community.</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/rfc6040" 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 notification (ECN) field of the IP header should be constructed on entry to and exit from any 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 decapsulation, 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 field 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 supported.  Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility.  Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification.  A thorough 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 that 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/rfc6077" 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. Papadimitriou" 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 congestion control that are known today.  This includes several new challenges that 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 open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed.   This document is not an Internet Standards Track specification; it is published 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/rfc6660" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml">
          <front>
            <title>Encoding Three Pre-Congestion Notification (PCN) States in the 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 protect 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.  Egress 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 the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain.  The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere.  Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix.  The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is 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/rfc6675" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6675.xml">
          <front>
            <title>A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (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 for TCP that is based on the use of the selective acknowledgment (SACK) TCP option.  The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it.   [STANDARDS-TRACK]</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/rfc7560" 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. Scheffenegger">
              <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 network 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 the sender.  ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT).  In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center 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 update 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/rfc7567" 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="editor">
              <organization/>
            </author>
            <author initials="G." surname="Fairhurst" fullname="G. Fairhurst" role="editor">
              <organization/>
            </author>
            <date year="2015" month="July"/>
            <abstract>
              <t>This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance.  It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet.  It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are 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/rfc7713" 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 same flow.  Today, network elements at any layer may signal congestion to the receiver 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 congestion information back into the network in-band at the IP layer, such that the 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" (RFC 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/rfc5925" 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 specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association 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 traffic 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 to 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 fully 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/rfc8033" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8033.xml">
          <front>
            <title>Proportional Integral Controller Enhanced (PIE): A Lightweight 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 network cause high latency and latency variation.  As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance.  There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.</t>
              <t>This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value. Simulation results, theoretical 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 overhead 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/rfc8083" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml">
          <front>
            <title>Multimedia Congestion Control: Circuit Breakers for Unicast RTP 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 telephony, video conferencing, and telepresence applications.  Such applications are often run on best-effort UDP/IP networks.  If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience.  The congestion 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 which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion.  It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able 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 breaker 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/rfc8085" 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-passing transport that has no inherent congestion control mechanisms.  This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP.  Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</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 Internet transport must employ mechanisms to prevent congestion collapse and to establish 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 protocols (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 multicast 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/rfc8174" 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</title>
            <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 protocol  specifications.  This document aims to reduce the ambiguity by clarifying that 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/rfc8290" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8290.xml">
          <front>
            <title>The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm</title>
            <author initials="T." surname="Hoeiland-Joergensen" fullname="T. Hoeiland-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 Active Queue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.</t>
              <t>FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic.  It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic.  It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient 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/rfc8298" 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 conversational media services such as interactive video.  The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm.  The algorithm is evaluated over both simulated Internet bottleneck 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://datatracker.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 network
   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-ecn-encap-guidelines.xml">
          <front>
            <title>Guidelines for Adding Congestion Notification to Protocols that 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 congestion
   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-guidelines-17"/>
        </reference>
        <reference anchor="I-D.ietf-tsvwg-rfc6040update-shim" target="https://datatracker.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-rfc6040update-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" made 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-rfc6040update-shim-15"/>
        </reference>
        <reference anchor="I-D.ietf-trill-ecn-support" target="https://datatracker.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 (Explicit 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 element 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://datatracker.ietf.org/api/v1/doc/document/draft-ietf-tsvwg-aqm-dualq-coupled/" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-aqm-dualq-coupled.xml">
          <front>
            <title>DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (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-coupled-24"/>
        </reference>
        <reference anchor="I-D.stewart-tsvwg-sctpecn" target="https://www.ietf.org/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 Control Transmission Protocol (SCTP).</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-stewart-tsvwg-sctpecn-05"/>
        </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.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-l4s-arch.xml">
          <front>
            <title>Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: 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 Internet
   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 support 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://datatracker.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-diffserv.xml">
          <front>
            <title>Interactions between Low Latency, Low Loss, Scalable Throughput (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 latency 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-diffserv-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/public/rfc/bibxml-ids/reference.I-D.ietf-tsvwg-nqb.xml">
          <front>
            <title>A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated 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.ietf.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</title>
            <author fullname="Greg White"/>
            <date day="28" month="April" year="2022"/>
            <abstract>
              <t>This document is intended to provide guidance in order to ensure
   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/rfc8311" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml">
          <front>
            <title>Relaxing Restrictions on Explicit Congestion Notification (ECN) 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 congestion to endpoints.  It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss.  This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation 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 makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram 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 provides 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://datatracker.ietf.org/api/v1/doc/document/draft-ietf-tcpm-generalized-ecn/" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tcpm-generalized-ecn.xml">
          <front>
            <title>ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control 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 when 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-ecn-10"/>
        </reference>
        <reference anchor="ARED01" target="https://www.icir.org/floyd/red.html">
          <front>
            <title>Adaptive RED: An Algorithm for Increasing the Robustness of
          RED's Active Queue Management</title>
            <author fullname="Sally Floyd" initials="S." surname="Floyd">
              <organization>ACIRI</organization>
            </author>
            <author fullname="Ramakrishna Gummadi" initials="R." surname="Gummadi">
              <organization>ACIRI</organization>
            </author>
            <author fullname="S. Shenker" initials="S." surname="Shenker">
              <organization>ACIRI</organization>
            </author>
            <date month="August" year="2001"/>
          </front>
          <seriesInfo name="ACIRI Technical Report" value=""/>
        </reference>
        <reference anchor="RFC8257" target="https://www.rfc-editor.org/info/rfc8257" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8257.xml">
          <front>
            <title>Data Center TCP (DCTCP): TCP Congestion Control for Data Centers</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. Balasubramanian">
              <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 occurred.  DCTCP then scales the TCP congestion window based on this estimate.  This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches.  This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating 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 deployments 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/rfc8312" 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. Scheffenegger">
              <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 stability 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 implementations and to solicit community feedback through experimentation on the performance of 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/rfc8511" 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 tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck.  This can cause noticeable performance degradation for TCP connections 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 therefore likely to be short.  Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet 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/rfc8985" 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 for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (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 used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative 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/rfc8888" 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 fine-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 feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion 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/rfc9000" 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 communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion 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/rfc9001" 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="editor">
              <organization/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t>This document describes how Transport Layer Security (TLS) is used 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/rfc9147" 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 Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, 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 exception 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.ietf.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 control  &#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://datatracker.ietf.org/api/v1/doc/document/draft-briscoe-docsis-q-protection/" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.briscoe-docsis-q-protection.xml">
          <front>
            <title>The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency</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 queue
   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-protection-06"/>
        </reference>
        <reference anchor="I-D.briscoe-iccrg-prague-congestion-control" target="https://datatracker.ietf.org/api/v1/doc/document/draft-briscoe-iccrg-prague-congestion-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-congestion-control-01"/>
        </reference>
        <reference anchor="I-D.cardwell-iccrg-bbr-congestion-control" target="https://datatracker.ietf.org/api/v1/doc/document/draft-cardwell-iccrg-bbr-congestion-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-congestion-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 multiplicative reduction to cwnd after a loss, cwnd is reduced by the number of lost segments. It can be modeled as a strict implementation of van Jacobson's Packet Conservation Principle. During recovery, new segments are injected into the network in exact accordance with the segments that are reported to have been delivered to the receiver by the returning ACKs. This algorithm offers a valuable new congestion control property: the TCP portion of the control loop has exactly unity gain, which should make it easier to implement simple controllers in network devices to accurately control queue sizes across a huge range of scales. Relentless 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 protocols have equivalent responses to these congestion signals. To function appropriately in a shared environment, Relentless Congestion Control requires that the network allocates capacity through some technique such as Fair Queuing, Approximate Fair Dropping, etc. The salient features of these algorithms are that they segregate the traffic into distinct flows, and send different congestion signals to each flow. This alternative congestion control paradigm is described in a separate document, also under consideration by the ICCRG. The goal of the document is to illustrate some new protocol features and properties might be possible if 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 standard congestion control and the "TCP-friendly" paradigm.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-mathis-iccrg-relentless-tcp-00"/>
        </reference>
        <reference anchor="BBRv2" target="https://github.com/google/bbr/blob/v2alpha/README.md">
          <front>
            <title>BRTCP BBR v2 Alpha/Preview Release</title>
            <author fullname="Neal Cardwell" initials="N" surname="Cardwell">
              <organization/>
            </author>
            <date/>
          </front>
          <seriesInfo name="GitHub repository;" value="Linux congestion control module"/>
        </reference>
        <!--{ToDo: DCttH ref will need to be updated, once stable}-->

      <reference anchor="DCttH19" target="https://bobbriscoe.net/pubs.html#DCttH_TR">
          <front>
            <title>`Data Centre to the Home': Ultra-Low Latency for All</title>
            <author fullname="Koen De Schepper" initials="K." surname="De Schepper">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author fullname="Olga Bondarenko" initials="O." surname="Bondarenko">
              <organization>Simula Research Lab</organization>
            </author>
            <author fullname="Olivier" 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="July" year="2019"/>
          </front>
          <seriesInfo name="Updated RITE project Technical Report" value=""/>
          <format target="https://bobbriscoe.net/projects/latency/dctth_journal_draft20190726.pdf" type="PDF"/>
        </reference>
        <reference anchor="PI2" target="https://dl.acm.org/citation.cfm?doid=2999572.2999578">
          <front>
            <title>PI^2 : A Linearized AQM for both Classic and Scalable
          TCP</title>
            <author fullname="Koen De Schepper" initials="K." surname="De Schepper">
              <organization>Bell Labs</organization>
            </author>
            <author fullname="Olga Bondarenko" initials="O." surname="Bondarenko">
              <organization>Simula Research Lab</organization>
            </author>
            <author fullname="Ing-jyh Tsang" initials="I." surname="Tsang">
              <organization>Bell Labs</organization>
            </author>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>BT</organization>
            </author>
            <date month="December" year="2016"/>
          </front>
          <seriesInfo name="Proc. ACM CoNEXT 2016" value="pp.105-119"/>
        </reference>
        <reference anchor="VCP" target="https://doi.acm.org/10.1145/1080091.1080098">
          <front>
            <title>One more bit is enough</title>
            <author fullname="Yong Xia" initials="Y." surname="Xia">
              <organization/>
            </author>
            <author fullname="Lakshminarayanan Subramanian" initials="L." surname="Subramanian">
              <organization/>
            </author>
            <author fullname="Ion Stoica" initials="I." surname="Stoica">
              <organization/>
            </author>
            <author fullname="Shivkumar Kalyanaraman" initials="S." surname="Kalyanaraman">
              <organization/>
            </author>
            <date month="" year="2005"/>
          </front>
          <seriesInfo name="Proc. SIGCOMM'05, ACM CCR" value="35(4)37--48"/>
          <format target="https://conferences.sigcomm.org/sigcomm/2005/paper-XiaSub.pdf" type="PDF"/>
        </reference>
        <reference anchor="QV" target="https://riteproject.files.wordpress.com/2015/12/rite-deliverable-2-3.pdf">
          <front>
            <title>Up to Speed with Queue View</title>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>BT</organization>
            </author>
            <author fullname="Per Hurtig" initials="P." surname="Hurtig">
              <organization>Uni Karlstad</organization>
            </author>
            <date month="August" year="2015"/>
          </front>
          <seriesInfo name="RITE Technical Report" value="D2.3; Appendix C.2"/>
        </reference>
        <reference anchor="Alizadeh-stability" target="https://people.csail.mit.edu/alizadeh/papers/dctcp_analysis-sigmetrics11.pdf">
          <front>
            <title>Analysis of DCTCP: Stability, Convergence, and
          Fairness</title>
            <author fullname="Mohamed Alizadeh" initials="M." surname="Alizadeh"/>
            <author fullname="Adel Javanmard" initials="A." surname="Javanmard"/>
            <author fullname="Balaji Prabhakar" initials="B." surname="Prabhakar"/>
            <date month="June" year="2011"/>
          </front>
          <seriesInfo name="ACM SIGMETRICS 2011" value=""/>
        </reference>
        <reference anchor="TCPPrague" target="https://www.ietf.org/mail-archive/web/tcpprague/current/msg00001.html">
          <front>
            <title>Notes: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40,
          Prague</title>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Simula</organization>
            </author>
            <date month="July" year="2015"/>
          </front>
          <seriesInfo name="tcpprague mailing list archive" value=""/>
        </reference>
        <reference anchor="sub-mss-prob" target="https://arxiv.org/abs/1904.07598">
          <front>
            <title>Scaling TCP's Congestion Window for Small Round Trip
          Times</title>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>BT</organization>
            </author>
            <author fullname="Koen De Schepper" initials="K." surname="De Schepper">
              <organization>Bell Labs</organization>
            </author>
            <date month="May" year="2015"/>
          </front>
          <seriesInfo name="BT Technical Report" value="TR-TUB8-2015-002"/>
          <format target="https://arxiv.org/pdf/1904.07598" type="PDF"/>
        </reference>
        <reference anchor="ecn-fallback" target="https://arxiv.org/abs/1911.00710">
          <front>
            <title>TCP Prague Fall-back on Detection of a Classic ECN
          AQM</title>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <author fullname="Asad Sajjad Ahmed" initials="A.S." surname="Ahmed">
              <organization>Simula and Uni Oslo</organization>
            </author>
            <date month="April" year="2020"/>
          </front>
          <seriesInfo name="bobbriscoe.net Technical Report" value="TR-BB-2019-002"/>
        </reference>
        <reference anchor="Ahmed19" target="https://www.duo.uio.no/handle/10852/70966">
          <front>
            <title>Extending TCP for Low Round Trip Delay</title>
            <author fullname="Asad Sajjad Ahmed" initials="A.S." surname="Ahmed">
              <organization>Simula and Uni Oslo</organization>
            </author>
            <date month="August" year="2019"/>
          </front>
          <seriesInfo name="Master's Thesis, Uni Oslo" value=""/>
          <format target="https://www.duo.uio.no/bitstream/handle/10852/70966/main.pdf?sequence=5&amp;isAllowed=y" type="PDF"/>
        </reference>
        <reference anchor="Paced-Chirping" target="https://riteproject.files.wordpress.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 anchor="A2DTCP" target="https://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6871352">
          <front>
            <title>Adaptive-Acceleration Data Center TCP</title>
            <author fullname="Tao Zhang" initials="T." surname="Zhang">
              <organization/>
            </author>
            <author fullname="Jianxin Wang" initials="J." surname="Wang">
              <organization/>
            </author>
            <author fullname="Jiawei Huang" initials="J." surname="Huang">
              <organization/>
            </author>
            <author fullname="Yi Huang" initials="Y." surname="Huang">
              <organization/>
            </author>
            <author fullname="Jianer Chen" initials="J." surname="Chen">
              <organization/>
            </author>
            <author fullname="Yi Pan" initials="Y." surname="Pan">
              <organization/>
            </author>
            <date month="June" year="2015"/>
          </front>
          <seriesInfo name="IEEE Transactions on Computers" value="64(6):1522-1533"/>
        </reference>
        <reference anchor="PragueLinux" target="https://www.netdevconf.org/0x13/session.html?talk-tcp-prague-l4s">
          <front>
            <title>Implementing the `TCP Prague' Requirements for Low Latency
          Low Loss Scalable Throughput (L4S)</title>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <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</organization>
            </author>
            <author fullname="Joakim Misund" initials="J." surname="Misund">
              <organization>University of Oslo</organization>
            </author>
            <author fullname="Olivier Tilmans" initials="O." surname="Tilmans">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
              <organization>ETHZ</organization>
            </author>
            <author fullname="Asad Sajjad Ahmed" initials="A.S." surname="Ahmed">
              <organization>Simula</organization>
            </author>
            <date month="March" year="2019"/>
          </front>
          <seriesInfo name="Proc. Linux Netdev 0x13" value=""/>
          <format target="https://www.files.netdevconf.info/f/4d6939d5f1fb404fafd1/?dl=1" type="PDF"/>
        </reference>
        <reference anchor="LinuxPacedChirping" target="https://www.netdevconf.org/0x13/session.html?talk-chirp">
          <front>
            <title>Paced Chirping - Rethinking TCP start-up</title>
            <author fullname="Joakim Misund" initials="J." surname="Misund">
              <organization>University of Oslo</organization>
            </author>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <date month="March" year="2019"/>
          </front>
          <seriesInfo name="Proc. Linux Netdev 0x13" value=""/>
          <format target="https://www.files.netdevconf.info/f/da8cc04a608a448f890e/?dl=1" type="PDF"/>
        </reference>
        <reference anchor="TCP-CA" target="https://ee.lbl.gov/papers/congavoid.pdf">
          <front>
            <title>Congestion Avoidance and Control</title>
            <author fullname="Van Jacobson" initials="V." surname="Jacobson">
              <organization/>
            </author>
            <author fullname="Michael J. Karels" initials="M.J." surname="Karels">
              <organization/>
              <address>
                <postal>
                  <street/>
                  <city/>
                  <region/>
                  <code/>
                  <country/>
                </postal>
                <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>
            <title>TCP Congestion Control with a Misbehaving Receiver</title>
            <author fullname="Stefan Savage" initials="S." surname="Savage">
              <organization>Uni Washington</organization>
            </author>
            <author fullname="Neal Cardwell" initials="N." surname="Cardwell">
              <organization>Uni Washington</organization>
            </author>
            <author fullname="David Wetherall" initials="D." surname="Wetherall">
              <organization>Uni Washington</organization>
            </author>
            <author fullname="Tom Anderson" initials="T." surname="Anderson">
              <organization>Uni Washington</organization>
            </author>
            <date month="October" year="1999"/>
          </front>
          <seriesInfo name="ACM SIGCOMM Computer Communication Review" value="29(5):71--78"/>
        </reference>
        <reference anchor="Heist21" target="https://github.com/heistp/l4s-tests/">
          <front>
            <title>L4S Tests</title>
            <author fullname="Pete Heist" initials="P." surname="Heist">
              <organization/>
            </author>
            <author fullname="Jonathan Morton" initials="J." surname="Morton">
              <organization/>
            </author>
            <date month="May" year="2021"/>
          </front>
          <seriesInfo name="GitHub" value="README"/>
        </reference>
        <reference anchor="SCReAM-L4S" target="https://github.com/EricssonResearch/scream/blob/master/README.md">
          <front>
            <title>SCReAM</title>
            <author fullname="Ingemar Johansson" initials="I" surname="Johansson">
              <organization/>
            </author>
            <date/>
          </front>
          <seriesInfo name="GitHub repository;" value=""/>
          <format target="https://github.com/google/bbr/blob/v2alpha/README.md" type="Source code"/>
        </reference>
        <reference anchor="DualPI2Linux" target="https://www.netdevconf.org/0x13/session.html?talk-DUALPI2-AQM">
          <front>
            <title>DUALPI2 - Low Latency, Low Loss and Scalable (L4S)
          AQM</title>
            <author fullname="Olga Albisser" initials="O." surname="Albisser">
              <organization>Simula Research Lab</organization>
            </author>
            <author fullname="Koen De Schepper" initials="K." surname="De Schepper">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <author fullname="Olivier Tilmans" initials="O." surname="Tilmans">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author fullname="Henrik Steen" initials="H." surname="Steen">
              <organization>Simula Research Lab</organization>
            </author>
            <date month="March" year="2019"/>
          </front>
          <seriesInfo name="Proc. Linux Netdev 0x13" value=""/>
          <format target="https://www.files.netdevconf.org/f/febbe8c6a05b4ceab641/?dl=1" type="PDF"/>
        </reference>
        <reference anchor="COBALT" target="https://doi.org/10.1109/LANMAN.2019.8847054">
          <front>
            <title>Design and Evaluation of COBALT Queue Discipline</title>
            <author initials="J." surname="Palmei"/>
            <author initials="S." surname="Gupta"/>
            <author initials="P." surname="Imputato"/>
            <author initials="J." surname="Morton"/>
            <author initials="M." surname="Tahiliani"/>
            <author initials="S." surname="Avallone"/>
            <author initials="D." surname="Taht"/>
            <date year="2019"/>
          </front>
          <seriesInfo name="In Proc. IEEE Int'l Symp. on Local and Metropolitan Area Networks" value="2019, pp1--6"/>
        </reference>
        <reference anchor="Dukkipati06" target="https://dl.acm.org/doi/10.1145/1111322.1111336">
          <front>
            <title>Why Flow-Completion Time is the Right Metric
          <title>Why Flow-Completion Time is the Right Metric for Congestion
          Control</title>
          <author fullname="Nandita Dukkipati" initials="N." surname="Dukkipati">
            <organization>Stanford Uni</organization> University</organization>
          </author>
          <author fullname="Nick McKeown" initials="N." surname="McKeown">
            <organization>Stanford Uni</organization> University</organization>
          </author>
          <date month="January" year="2006"/>
        </front>
	<seriesInfo name="ACM CCR" value="36(1):59--62"/>
          <format target="http://yuba.stanford.edu/rcp/flowCompTime-dukkipati.pdf" type="PDF"/> name="DOI" value="10.1145/1111322.1111336"/>
        <refcontent>ACM SIGCOMM Computer Communication Review, Volume 36, Issue 1, pp. 59-62</refcontent>
      </reference>

        <reference anchor="Bufferbloat" target="https://bufferbloat.net/">
          <front>
            <title>Bufferbloat</title>
            <author fullname="">
              <organization/>
            <author>
             <organization>The Bufferbloat community</organization>
            </author>
            <date/>
          </front>
          <annotation>(last accessed 27 Aug 2022)</annotation>
        </reference>

      </references>
    </references>

    <section anchor="l4sps_tcp-prague-reqs" numbered="true" toc="default">
      <name>Rationale for the 'Prague L4S Requirements'</name>
      <t>This appendix is informative, not normative. It gives a list of
      modifications to current scalable Scalable congestion controls so that they can
      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
      it can set the L4S identifier in packets it sends into the Internet. As
      well as rationale for safety improvements (the requirements in <xref target="l4sid_transport_req" format="default"/>) format="default"/>), this appendix also includes preferable
      performance improvements (optimizations).</t>
      <t>The requirements and recommendations in <xref target="l4sid_transport_req" format="default"/>) format="default"/> have become known as the Prague 'Prague L4S
      Requirements,
      Requirements', because they were originally identified at an ad hoc
      meeting during IETF-94 IETF 94 in Prague <xref Prague <xref target="TCPPrague" format="default"/>. They
      were originally called the 'TCP Prague Requirements', but they are not
      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
      specific implementation of the requirements.</t>
      <t>At the time of writing, DCTCP <xref DCTCP <xref target="RFC8257" format="default"/> is the
      most widely used scalable Scalable transport protocol. In its current form, DCTCP
      is specified to be deployable only in controlled environments. Deploying
      it in the public Internet would lead to a number of issues, both from both
      the safety and the performance perspective. The modifications and
      additional mechanisms listed in this section will be necessary for its
      deployment over the global Internet. Where an example is needed, DCTCP
      is used as a base, but the requirements in <xref target="l4sid_transport_req" format="default"/> apply equally to other scalable Scalable
      congestion controls, covering adaptive real-time media, etc., not just
      capacity-seeking behaviours.</t>
      <section numbered="true" toc="default">
        <name>Rationale for the Requirements for Scalable Transport Protocols</name>
        <t/>
        <section numbered="true" toc="default">
          <name>Use of L4S Packet Identifier</name>
          <t>Description: A scalable Scalable congestion control needs to distinguish
          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>
          <t>Motivation: It needs to be possible for a network node to
          classify L4S packets without flow state into a queue that applies an
          L4S ECN marking ECN-marking behaviour and isolates L4S packets from the queuing
          delay of Classic packets.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Accurate ECN Feedback</name>
          <t>Description: The transport protocol for a scalable Scalable congestion
          control needs to provide timely, accurate feedback about the extent
          of ECN marking experienced by all packets (see the precise normative
          requirement wording in <xref target="l4sid_feedback" format="default"/>).</t>
          <t>Motivation: Classic congestion controls only need feedback about
          the existence of a congestion episode within a round trip, not
          precisely how many packets were marked with ECN ECN-marked or dropped.
          Therefore, in 2001, when ECN feedback was added to TCP <xref TCP <xref target="RFC3168" format="default"/>, it could not inform the sender of more than one
          ECN mark per RTT.
          Since then, requirements for more accurate ECN
          feedback in TCP have been defined in <xref target="RFC7560" format="default"/> format="default"/>, and
          <xref target="I-D.ietf-tcpm-accurate-ecn" format="default"/> specifies a change to
          the TCP protocol to satisfy these requirements. Most other transport
          protocols already satisfy this requirement (see <xref target="l4sid_feedback" format="default"/>).</t>
        </section>
        <section anchor="l4sid_sec_replaceable" numbered="true" toc="default">
          <name>Capable of Replacement by Classic Congestion Control</name>
          <t>Description: It needs to be possible to replace the
          implementation of a scalable Scalable congestion control with a Classic
          control (see the precise normative requirement wording in <xref target="l4sid_congestion_response" target="l4sid_Prague_req-replaceable" format="default"/>).</t>
          <t>Motivation: L4S is an experimental protocol, therefore protocol; therefore, it seems
          prudent to be able to disable it at source in case of insurmountable
          problems, perhaps due to some unexpected interaction on a particular
          sender; over a particular path or network; or with a particular
          receiver
          receiver, or even ultimately an insurmountable problem with the
          experiment as a whole.</t>
        </section>
        <section anchor="l4sid_sec_fallback_on_loss" numbered="true" toc="default">
          <name>Fall back Back to Classic Congestion Control on Packet Loss</name>
          <t>Description: As well as responding to ECN markings in a scalable
          way, a scalable Scalable congestion control needs to react to packet loss in
          a way that will coexist safely with a Reno congestion
          control <xref
          control <xref target="RFC5681" format="default"/> (see the precise normative
          requirement wording in <xref target="l4sid_congestion_response" target="l4sid_Prague_req-loss-response" format="default"/>).</t>
          <t>Motivation: Part of the safety conditions for deploying a
          scalable
          Scalable congestion control on the public Internet is to make sure
          that it behaves properly when it builds a queue at a network
          bottleneck that has not been upgraded to support L4S. Packet loss
          can have many causes, but it usually has to be conservatively
          assumed that it is a sign of congestion. Therefore, on detecting
          packet loss, a scalable Scalable congestion control will need to fall back to
          Classic congestion control behaviour. If it does not comply, it
          could starve Classic traffic.</t>
          <t>A scalable Scalable congestion control can be used for different types of
          transport, e.g. for e.g., for real-time media or for reliable transport
          like TCP. Therefore, the particular Classic congestion control
          behaviour to fall back on will need to be dependent on the specific
          congestion control implementation.
	  In the particular case of DCTCP,
          the DCTCP specification <xref specification <xref target="RFC8257" format="default"/> states that
          "It is RECOMMENDED that an implementation deal with
          "A DCTCP sender <bcp14>MUST</bcp14> react to loss episodes in
          the same way as conventional TCP." For safe deployment, <xref target="l4sid_congestion_response" format="default"/> requires TCP,...".  To ensure any specification of a
          scalable Scalable congestion control for is safe to deploy over the public Internet to define Internet, Item
          <xref target="l4sid_Prague_req-loss-response" format="counter"/> of <xref target="l4sid_congestion_response" format="default"/> in the
          above requirement present spec
          does not require precisely the same response as Reno TCP, but it does
          require a "MUST".</t> response that will coexist safely with Classic congestion controls
          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
          receive a high proportion of packets marked with the CE bit set codepoint and
          also experience loss. Current DCTCP implementations each react
          differently to this situation. At least one implementation reacts One approach is to react only to the drop
          signal (e.g. by (e.g., by halving the CWND) and at least cwnd); another DCTCP implementation reacts approach is to both signals (e.g. by
          halving the CWND due react to the drop and also further reducing the CWND
          based on the proportion of marked packet). both
          signals, which reduces cwnd by more than half. A third approach for the
          public Internet compromise
          between these two has been proposed that adjusts where the loss response is adjusted to
          result in a halving when combined with the any ECN response. response earlier in the same
          round. We believe
          that further experimentation is needed to understand what is the
          best behaviour for the public Internet, which may or may not be one of
          these existing approaches.</t>
        </section>
        <section anchor="l4sid_sec_fallback_on_classic_CE" numbered="true" toc="default">
          <name>Coexistence with Classic Congestion Control at Classic ECN bottlenecks</name> Bottlenecks</name>
          <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
          such an AQM has been implemented in a shared queue, in which case
          any long-running scalable Scalable flow would predominate over any
          simultaneous long-running Classic flow sharing the queue. The
          precise requirement wording in <xref target="l4sid_congestion_response" target="l4sid_Prague_req-classic-ecn-response" format="default"/> is written so that such a
          problem could either be resolved either in real-time, real time or via administrative
          intervention.</t>
          <t>Motivation: Similarly to the discussion in <xref target="l4sid_sec_fallback_on_loss" format="default"/>, this requirement in <xref target="l4sid_congestion_response" format="default"/> is a safety condition to ensure
          an L4S congestion control coexists well with Classic flows when it
          builds a queue at a shared network bottleneck that has not been
          upgraded to support L4S. Nonetheless, if necessary, it is considered
          reasonable to resolve such problems over management timescales
          (possibly involving human intervention) because:</t>
          <ul spacing="normal">
            <li>although a Classic flow can considerably reduce its
              throughput in the face of a competing scalable Scalable flow, it still
              makes progress and does not starve;</li>
            <li>implementations of a Classic ECN AQM in a queue that is
              intended to be shared are believed to be rare;</li> rare; and</li>
            <li>detection of such AQMs is not always clear-cut; so focused
              out-of-band testing (or even contacting the relevant network
              operator) would improve certainty.</li>
          </ul>
          <t>Therefore, the
          <t>The relevant normative requirement (<xref target="l4sid_congestion_response" format="default"/>) is therefore divided into three stages:
          monitoring, detection detection, and action:</t>
          <dl newline="false" spacing="normal">
            <dt>Monitoring:</dt>
            <dd>Monitoring involves collection of the
              measurement data to be analysed. Monitoring is expressed as a
              'MUST'
              "<bcp14>MUST</bcp14>" for uncontrolled environments, although the placement of
              the monitoring function is left open. Whether monitoring has to
              be applied in real-time real time is expressed as a 'SHOULD'. "<bcp14>SHOULD</bcp14>".
              This allows
              for the possibility that the operator of an L4S sender
              (e.g. a CDN)
              (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
              resources to monitor live traffic.</dd>
            <dt>Detection:</dt>
            <dd>Detection involves analysis of the
              monitored data to detect the likelihood of a Classic ECN AQM.
              Detection can either directly detect actual coexistence problems
              between flows, flows or it can aim to identify AQM technologies that
              are likely to present coexistence problems, based on knowledge
              of AQMs deployed at the time. The requirements recommend that
              detection occurs live in real-time. real time. However, detection is
              allowed to be deferred (e.g. it (e.g., it might involve further
              testing targeted at candidate AQMs);</dd> AQMs).</dd>
            <dt>Action:</dt>
            <dd>
              <t>This involves the act of switching the
              sender to a Classic congestion control. This might occur in
              real-time
              real time within the congestion control for the subsequent
              duration of a flow, or it might involve administrative action to
              switch to Classic congestion control for a specific interface or
              for a certain set of destination addresses.</t>
              <t>Instead of the sender taking action itself, the
              operator of the sender (e.g. a (e.g., a CDN) might prefer to ask the
              network operator to modify the Classic AQM's treatment of L4S
              packets; or to ensure L4S packets bypass the AQM; or to upgrade
              the AQM to support L4S (see the L4S operational
              guidance <xref
              guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/>). Once
              If L4S
              flows then no longer shared the Classic ECN AQM AQM, they would obviously
              no longer detect it, and the requirement to act on it would no
              longer apply.</t>
            </dd>
          </dl>
          <t>The whole set of normative requirements concerning Classic ECN
          AQMs in <xref target="l4sid_congestion_response" format="default"/> is worded so that
          it does not apply in controlled environments, such as private
          networks or data centre data-centre networks. CDN servers placed within an
          access ISP's network can be considered as a single controlled
          environment, but any onward networks served by the access network,
          including all the attached customer networks, would be unlikely to
          fall under the same degree of coordinated control. Monitoring is
          expressed as a 'MUST' "<bcp14>MUST</bcp14>" for these uncontrolled segments of paths
          (e.g. beyond
          (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
          in that segment. Nonetheless, the intent of the wording is to only
          require occasional monitoring of these uncontrolled regions, regions and not
          to burden CDN operators if monitoring never uncovers any potential
          problems.</t>
          <t>More detailed discussion of all the above options and
          alternatives can be found in the L4S operational guidance <xref guidance <xref target="I-D.ietf-tsvwg-l4sops" format="default"/>.</t>
          <t>Having said all the above, the approach recommended in <xref target="l4sid_congestion_response" format="default"/> is to monitor, detect detect, and act
          in real-time real time on live traffic. A passive monitoring algorithm to
          detect a Classic ECN AQM at the bottleneck and fall back to Classic
          congestion control is described in an extensive technical
          report <xref
          report <xref target="ecn-fallback" format="default"/>, which also provides a
          link to Linux source code, code and a large online visualization of its
          evaluation results. Very briefly, the algorithm primarily monitors
          RTT variation using the same algorithm that maintains the mean
          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
          other metrics such as the presence of CE marking and congestion
          avoidance phase having stabilized. The report also identifies
          further work to improve the approach, for instance instance, improvements with
          low capacity
          low-capacity links and combining the measurements with a cache of
          what had been learned about a path in previous connections. The
          report also suggests alternative approaches.</t>
          <t>Although using passive measurements within live traffic (as
          above) can detect a Classic ECN AQM, it is much harder (perhaps
          impossible) to determine whether or not the AQM is in a shared
          queue. Nonetheless, this is much easier using active test traffic
          out-of-band,
          out-of-band because two flows can be used. Section 4 of the same
          report <xref
          report <xref target="ecn-fallback" format="default"/> describes a simple
          technique to detect a Classic ECN AQM and determine whether it is in
          a shared queue, which is summarized here.</t>
          <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
          two parallel long-running flows. It could serve one with a Classic
          congestion control (C, that sets ECT(0)) and one with a scalable Scalable CC
          (L, that sets ECT(1)). If neither flow induces any ECN marks, it can
          be presumed that the path does not contain a Classic ECN AQM. If either
          flow induces some ECN marks, the server could measure the relative
          flow rates and round trip round-trip times of the two flows.
          <xref target="l4sid_tab_active_AQN_test" format="default"/> shows the AQM that can be
          inferred for various cases (presuming the no more types of AQM behaviours behaviour than those known at
          the time of writing).</t>
          <table anchor="l4sid_tab_active_AQN_test" align="center">
            <name>Out-of-band testing
            <name>Out-of-Band Testing with two parallel flows. L:=L4S, C:=Classic.</name> Two Parallel Flows</name>
            <thead>
              <tr>
                <th align="left">Rate</th>
                <th align="left">RTT</th>
                <th align="left">Inferred AQM</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">L &gt; C</td>
                <td align="left">L = C</td>
                <td align="left">Classic ECN AQM (FIFO)</td>
              </tr>
              <tr>
                <td align="left">L = C</td>
                <td align="left">L = C</td>
                <td align="left">Classic ECN AQM (FQ)</td>
              </tr>
              <tr>
                <td align="left">L = C</td>
                <td align="left">L &lt; C</td>
                <td align="left">FQ-L4S AQM</td>
              </tr>
              <tr>
                <td align="left">L ~= C</td>
                <td align="left">L &lt; C</td>
                <td align="left">Coupled DualQ align="left">DualQ Coupled AQM</td>
              </tr>
            </tbody>
            <tfoot>
              <tr>
                <th colspan="3" align="center">L = L4S; C = Classic</th>
              </tr>
            </tfoot>
          </table>

          <t>Finally, we motivate the recommendation in <xref target="l4sid_congestion_response" format="default"/> that a scalable Scalable congestion
          control is not expected to change to setting ECT(0) while it adapts
          its behaviour to coexist with Classic flows. This is because the
          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
          the bottleneck:</t>
          <ul spacing="normal">
            <li>If, as recommended, the sender changes only its behaviour but
              not its codepoint to Classic, its codepoint will still be
              compatible with either an L4S or a Classic AQM. If the
              bottleneck does actually support both, it will still classify
              ECT(1) into the same L4S queue, where the sender can measure
              that switching to Classic behaviour was wrong, wrong so that it can
              switch back.</li>
            <li>In contrast, if the sender changes both its behaviour and its
              codepoint to Classic, even if the bottleneck supports both, it
              will classify ECT(0) into the Classic queue, reinforcing the
            sender's incorrect decision so that it never switches back.</li>

            <li>Also, not changing its codepoint avoids the risk of being flipped
              to a different path by a load balancer or multipath routing that
              hashes on the whole of the ex-ToS former Type-of-Service (ToS) byte (unfortunately (which is unfortunately still a
              common pathology).</li>
          </ul>
          <t>Note
          <aside><t>Note that if a flow is configured to <em>only</em>
          use a Classic congestion control, it is then entirely appropriate
          not to use ECT(1).</t> ECT(1).</t></aside>
        </section>
        <section anchor="l4sid_sec_RTT_dependence" numbered="true" toc="default">
          <name>Reduce RTT dependence</name> Dependence</name>
          <t>Description: A scalable Scalable congestion control needs to reduce RTT
          bias as much as possible at least over the low to typical low-to-typical range of
          RTTs that will interact in the intended deployment scenario (see the
          precise normative requirement wording in <xref target="l4sid_congestion_response" target="l4sid_Prague_req-rtt-independence" format="default"/>).</t>
          <t>Motivation: The throughput of Classic congestion controls is
          known to be inversely proportional to RTT, so one would expect flows
          over very low RTT paths to nearly starve flows over larger RTTs.
          However, Classic congestion controls have never allowed a very low
          RTT path to exist because they induce a large queue. For instance,
          consider two paths with base RTT 1 ms 1 ms and 100 ms. 100 ms. If a
          Classic congestion control induces a 100 ms 100 ms queue, it turns
          these RTTs into 101 ms 101 ms and 200 ms 200 ms, leading to a throughput
          ratio of about 2:1. Whereas if a scalable Scalable congestion control induces
          only a 1 ms 1 ms queue, the ratio is 2:101, leading to a throughput
          ratio of about 50:1.</t>
          <t>Therefore, with very small queues, long RTT flows will
          essentially starve, unless scalable Scalable congestion controls comply with
          this
          the requirement in <xref target="l4sid_congestion_response" format="default"/>.</t>
          <t>Over higher than typical RTTs, L4S flows can use the same RTT
          bias as in current Classic congestion controls and still work
          satisfactorily. So, So there is no additional requirement in <xref target="l4sid_congestion_response" format="default"/> for high RTT L4S flows to
          remove RTT bias - -- they can can, but they don't have to.</t>
          <t>One way for a Scalable congestion control to satisfy these
          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
          (rtt_virt) that is a function of the actual RTT (rtt). Example
          functions might be:</t>

          <ul empty="true" spacing="normal"> spacing="normal" empty="true">
            <li>
              <tt>rtt_virt = max(rtt, 25ms)</tt></li> 25 ms)</tt></li>
            <li>
              <tt>rtt_virt = rtt + 10ms</tt></li> 10 ms</tt></li>
          </ul>
          <t>These example functions are chosen so that, as the actual
          RTT reduces from high to low, the virtual RTT reduces less (see
          <xref target="I-D.briscoe-iccrg-prague-congestion-control" format="default"/> for
          details).</t>
          <t>However, short RTT flows can more rapidly respond to changes in
          available capacity, whether due to other flows arriving and
          departing or radio capacity varying. So it would be wrong to require
          short RTT flows to be as sluggish as long-RTT long RTT flows, which would
          unnecessarily under-utilize underutilize capacity and result in unnecessary
          overshoots and undershoots (instability). Therefore, rather than
          requiring strict RTT-independence, RTT independence, the wording says in Item <xref target="l4sid_Prague_req-rtt-independence" format="counter"/> of <xref target="l4sid_congestion_response" format="default"/> is "as independent
          of RTT as possible without compromising stability or utilization".
          This allows shorter RTT flows to exploit their agility
          advantage.</t>
        </section>
        <section anchor="l4sid_sec_min_cwnd" numbered="true" toc="default">
          <name>Scaling down Down to fractional congestion windows</name> Fractional Congestion Windows</name>
          <t>Description: A scalable Scalable congestion control needs to remain
          responsive to congestion when typical RTTs over the public Internet
          are significantly smaller because they are no longer inflated by
          queuing delay (see the precise normative requirement wording in
          <xref target="l4sid_congestion_response" target="l4sid_Prague_req-fractional-window" format="default"/>).</t>
          <t>Motivation: As currently specified, the minimum congestion window
          of ECN-capable TCP (and its derivatives) is expected to be 2 sender
          maximum segment sizes (SMSS), or 1 SMSS after a retransmission
          timeout. Once the congestion window reaches this minimum, if there
          is further ECN-marking, ECN marking, TCP is meant to wait for a retransmission
          timeout before sending another segment (see section 6.1.2 of the ECN
          spec <xref <xref target="RFC3168" format="default"/>).
          sectionFormat="of" section="6.1.2">the ECN spec</xref>). In
          practice, most known window-based congestion control algorithms
          become unresponsive to ECN congestion signals at this point. No
          matter how much ECN marking, the congestion window no longer
          reduces. Instead, the sender's lack of any further congestion
          response forces the queue to grow, overriding any AQM and increasing
          queuing delay (making the window large enough to become responsive
          again). This can result in a stable but deeper queue, or it might
          drive the queue to loss, then in which case the retransmission timeout mechanism
          acts as a backstop.</t>
          <t>Most window-based congestion controls for other transport
          protocols have a similar minimum window, albeit when measured in
          bytes for those that use smaller packets.</t>
          <t>L4S mechanisms significantly reduce queueing queuing delay so, over the
          same path, the RTT becomes lower. Then Then, this problem becomes
          surprisingly common <xref common <xref target="sub-mss-prob" format="default"/>. This is
          because, for the same link capacity, smaller RTT implies a smaller
          window. For instance, consider a residential setting with an
          upstream broadband Internet access of 8 Mb/s, 8 Mb/s, assuming a max
          segment size of 1500 B. 1500 B. Two upstream flows will each have the
          minimum window of 2 SMSS 2 SMSS if the RTT is 6 ms 6 ms or less, which
          is quite common when accessing a nearby data centre. So, So any more
          than two such parallel TCP flows will become unresponsive to ECN and
          increase queuing delay.</t>
          <t>Unless scalable Scalable congestion controls address the requirement in
          <xref target="l4sid_congestion_response" format="default"/> from the start, they will
          frequently become unresponsive to ECN, negating the low latency low-latency
          benefit of L4S, for themselves and for others.</t>
          <t>That would seem to imply that scalable Scalable congestion controllers
          ought to be required to be able work with a congestion window less
          than 1 SMSS. 1 SMSS. For instance, if an ECN-capable TCP gets an
          ECN-mark
          ECN mark when it is already sitting at a window of 1 SMSS,
          RFC 3168 1 SMSS,
          <xref target="RFC3168" format="default"/> requires it to defer sending for a retransmission
          timeout. A less drastic but more complex mechanism can maintain a
          congestion window less than 1 SMSS 1 SMSS (significantly less if
          necessary), as described in <xref target="Ahmed19" format="default"/>. Other
          approaches are likely to be feasible.</t>
          <t>However, the requirement in <xref target="l4sid_congestion_response" format="default"/> is worded as a "SHOULD" "<bcp14>SHOULD</bcp14>" because
          it is believed that the existence of a minimum window is not all
          bad. When competing with an unresponsive flow, a minimum window
          naturally protects the flow from starvation by at least keeping some
          data flowing.</t>
          <t>By stating the requirement to go lower than 1 SMSS 1 SMSS as a
          "SHOULD",
          "<bcp14>SHOULD</bcp14>", while the requirement in RFC 3168 <xref target="RFC3168" format="default"/> still stands as
          well, we shall be able to watch the choices of minimum window evolve
          in different scalable 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 anchor="l4sid_sec_reordering_tolerance" numbered="true" toc="default">
          <name>Measuring Reordering Tolerance in Time Units</name>
          <t>Description: When detecting loss, a scalable Scalable congestion control
          needs to be tolerant to reordering over an adaptive time interval,
          which scales with throughput, rather than counting only in fixed
          units of packets, which does not scale (see the precise normative
          requirement wording in <xref target="l4sid_congestion_response" target="l4sid_Prague_req-reordering" format="default"/>).</t>
          <t>Motivation: A primary purpose of L4S is scalable throughput (it's
          in the name). Scalability in all dimensions is, of course, also a
          goal of all IETF technology. The inverse linear congestion response
          in <xref target="l4sid_congestion_response" format="default"/> is necessary, but not
          sufficient, to solve the congestion control scalability problem
          identified in <xref target="RFC3649" format="default"/>. As well as maintaining
          frequent ECN signals as rate scales, it is also important to ensure
          that a potentially false perception of loss does not limit
          throughput scaling.</t>
          <t>End-systems
          <t>End systems cannot know whether a missing packet is due to loss
          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
          space has not been filled, either after a certain number of
          subsequent packets has arrived (e.g. the (e.g., the 3 DupACK rule of
          standard TCP congestion control <xref control <xref target="RFC5681" format="default"/>) or
          after a certain amount of time (e.g. the (e.g., the RACK
          approach <xref
          approach <xref target="RFC8985" format="default"/>).</t>
          <t>As we attempt to scale packet rate over the years:</t>
          <ul spacing="normal">
            <li>Even if only <em>some</em> sending hosts
              still deem that loss has occurred by counting reordered packets,
              <em>all</em> networks will have to keep
              reducing the time over which they keep packets in order. If some
              link technologies keep the time within which reordering occurs
              roughly unchanged, then loss over these links, as perceived by
              these hosts, will appear to continually rise over the years.</li>
            <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
              roughly invariant.</li>
          </ul>
          <t>Therefore, hosts have an incentive to detect loss in time
          units (so as not to fool themselves too often into detecting losses
          when there are none). And for hosts that are changing their
          congestion control implementation to L4S, there is no downside to
          including time-based loss detection code in the change (loss
          recovery implemented in hardware is an exception, which is covered later).
          Therefore, requiring L4S hosts to detect loss in time-based units
          would not be a burden.</t>

          <t>If the requirement in <xref target="l4sid_congestion_response" format="default"/>
          were not placed on L4S hosts, even though it would be no burden on
          hosts to comply, all networks would face unnecessary uncertainty
          over whether some L4S hosts might be detecting loss by counting
          packets. Then Then, <em>all</em> link technologies will would
          have to unnecessarily keep reducing the time within which reordering
          occurs. That is not a problem for some link technologies, but it
          becomes increasingly challenging for other link technologies to
          continue to scale, particularly those relying on channel bonding for
          scaling, such as LTE, 5G 5G, and DOCSIS.</t> Data Over Cable Service Interface Specification (DOCSIS).</t>
          <t>Given Internet paths traverse many link technologies, any scaling
          limit for these more challenging access link technologies would
          become a scaling limit for the Internet as a whole.</t>
          <t>It might be asked how it helps to place this loss detection
          requirement only on L4S hosts, because networks will still face
          uncertainty over whether non-L4S flows are detecting loss by
          counting DupACKs. The answer is that those link technologies for
          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
          the L4S identifier is visible at the IP layer). Therefore, they can
          focus their processing and memory resources into scaling non-L4S
          (Classic) traffic. Then, the higher the proportion of L4S traffic,
          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
          the solution instead of part of the problem.</t>
          <t>Requirement ("MUST") ("<bcp14>MUST</bcp14>") or recommendation ("SHOULD")? ("<bcp14>SHOULD</bcp14>")? As explained
          above, this is a subtle interoperability issue between hosts and
          networks, which seems to need a "MUST". "<bcp14>MUST</bcp14>". Unless networks can be
          certain that all L4S hosts follow the time-based approach, they
          still have to cater for the worst case - -- continually squeeze
          reordering into a smaller and smaller duration - -- just for hosts that
          might be using the counting approach. However, it was decided to
          express this as a recommendation, using "SHOULD". "<bcp14>SHOULD</bcp14>". The main
          justification was that networks can still be fairly certain that L4S
          hosts will follow this recommendation, because following it offers
          only gain and no pain.</t>
          <t>Details:</t>

          <t>The speed of time spent recovering a loss recovery is much more significant for short
          flows than long, therefore long; therefore, a good compromise is to adapt the
          reordering window; window from a small fraction of the RTT at the start of
          a flow, flow to a larger fraction of the RTT for flows that continue for
          many round trips.</t>
          <t>This is broadly the approach adopted by TCP RACK (Recent
          ACKnowledgements) <xref <xref target="RFC8985" format="default"/>. However, RACK
          starts with the 3 DupACK approach, because the RTT estimate is not
          necessarily stable. As long as the initial window is paced, such
          initial use of 3 DupACK counting would amount to time-based loss
          detection and therefore would satisfy the time-based loss detection
          recommendation of <xref target="l4sid_congestion_response" format="default"/>. This
          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
          round trip.</t>

          <t>As mentioned above, hardware implementations of loss recovery
          using DupACK counting exist (e.g. some (e.g., some implementations of
          RoCEv2 for RDMA).
          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
          control (as distinct from loss recovery) is implemented in software.
          But they cannot easily satisfy this loss recovery requirement.
          However, it is believed they do not need to, because such
          implementations are believed to solely exist in controlled
          environments, where the network technology keeps reordering
          extremely low anyway. This is why controlled environments with
          hardly any reordering are excluded from the scope of the normative
          recommendation in <xref target="l4sid_congestion_response" format="default"/>.</t>
          <t>Detecting loss in time units also prevents the ACK-splitting
          attacks described in <xref target="Savage-TCP" format="default"/>.</t>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>Scalable Transport Protocol Optimizations</name>
        <t/>
        <section numbered="true" toc="default">
          <name>Setting ECT in Control Packets and Retransmissions</name>
          <t>Description: This item concerns TCP and its derivatives
          (e.g. SCTP)
          (e.g., SCTP) as well as RTP/RTCP <xref RTP/RTCP <xref target="RFC6679" format="default"/>.
          The original specification of ECN for TCP precluded the use of ECN
          on control packets and retransmissions. Similarly, RFC 6679 <xref target="RFC6679" format="default"/>
          precludes the use of ECT on RTCP datagrams, in case the path changes
          after it has been checked for ECN traversal. To improve performance,
          scalable
          Scalable transport protocols ought to enable ECN at the IP layer in
          TCP control packets (SYN, SYN-ACK, pure ACKs, etc.) and in
          retransmitted packets. The same is true for other transports,
          e.g. SCTP,
          e.g., SCTP and RTCP.</t>
          <t>Motivation (TCP): RFC 3168 <xref target="RFC3168" format="default"/> prohibits the use of ECN on these
          types of TCP packet, packets, based on a number of arguments. This means
          these packets are not protected from congestion loss by ECN, which
          considerably harms performance, particularly for short flows.
          ECN++ <xref
          ECN++ <xref target="I-D.ietf-tcpm-generalized-ecn" format="default"/> proposes
          experimental use of ECN on all types of TCP packet packets as long as AccECN
          feedback <xref
          feedback <xref target="I-D.ietf-tcpm-accurate-ecn" format="default"/> is
          available (which itself satisfies the accurate feedback requirement
          in <xref target="l4sid_feedback" format="default"/> for using a scalable Scalable congestion
          control).</t>
          <t>Motivation (RTCP): L4S experiments in general will need to
          observe the rule in the RTP ECN spec <xref spec <xref target="RFC6679" format="default"/>
          that precludes ECT on RTCP datagrams. Nonetheless, as ECN usage
          becomes more widespread, it would be useful to conduct specific
          experiments with ECN-capable RTCP to gather data on whether such
          caution is necessary.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Faster than Additive Increase</name>
          <t>Description: It would improve performance if scalable Scalable congestion
          controls did not limit their congestion window increase to the
          standard additive increase of 1 SMSS 1 SMSS per round trip <xref trip <xref target="RFC5681" format="default"/> during congestion avoidance. The same is true for
          derivatives of TCP congestion control, including similar approaches
          used for real-time media.</t>
          <t>Motivation: As currently defined <xref defined <xref target="RFC8257" format="default"/>,
          DCTCP uses the conventional Reno additive increase in the congestion
          avoidance phase. When the available capacity suddenly increases
          (e.g. when
          (e.g., when another flow finishes, finishes or if radio capacity
          increases) it can take very many round trips to take advantage of
          the new capacity. TCP Cubic <xref CUBIC <xref target="RFC8312" format="default"/> was
          designed to solve this problem, but as flow rates have continued to
          increase, the delay accelerating into available capacity has become
          prohibitive. See, for instance, the examples in Section 5.1 <xref target="RFC9330" section="5.1"
sectionFormat="bare"/> of the
          L4S architecture <xref target="I-D.ietf-tsvwg-l4s-arch" architecture <xref target="RFC9330" format="default"/>. Even
          when out of its Reno-compatibility Reno-friendly mode, every 8x 8 times scaling of Cubic's CUBIC's flow
          rate leads to 2x 2 times more acceleration delay.</t>
          <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
          disappeared and seek available capacity more rapidly, while
          minimizing the impact on other flows (Classic and
          scalable) <xref
          Scalable) <xref target="LinuxPacedChirping" format="default"/>. Alternatively,
          approaches such as Adaptive Acceleration (A2DTCP <xref Adaptive-Acceleration Data Center TCP (A2DTCP) <xref target="A2DTCP" format="default"/>) have been proposed to address this problem in
          data centres, which might be deployable over the public
          Internet.</t>
        </section>
        <section numbered="true" toc="default">
          <name>Faster Convergence at Flow Start</name>
          <t>Description: It would improve performance if scalable Scalable congestion
          controls converged (reached their steady-state share of the
          capacity) faster than Classic congestion controls or at least no
          slower. This affects the flow start behaviour of any L4S congestion
          control derived from a Classic transport that uses TCP slow start,
          including those for real-time media.</t>
          <t>Motivation: As an example, a new DCTCP flow takes longer than a
          Classic congestion control to obtain its share of the capacity of
          the bottleneck when there are already ongoing flows using the
          bottleneck capacity.
          In a data centre environment data-centre environment, DCTCP takes about
          a factor of
          1.5 to 2 times longer to converge due to the much higher
          typical level of ECN marking that DCTCP background traffic induces,
          which causes new flows to exit slow start early <xref early <xref target="Alizadeh-stability" format="default"/>. In testing for use over the public
          Internet
          Internet, the convergence time of DCTCP relative to a regular
          loss-based TCP slow start is even less favourable <xref target="Paced-Chirping" favourable <xref target="LinuxPacedChirping" format="default"/> due to the shallow ECN marking ECN-marking threshold
          needed for L4S. It is exacerbated by the typically greater mismatch
          between the link rate of the sending host and typical Internet
          access bottlenecks. This problem is detrimental in general, general but
          would particularly harm the performance of short flows relative to
          Classic congestion controls.</t>
        </section>
      </section>
    </section>
    <section anchor="l4sid_ECT1_CE" numbered="true" toc="default">
      <name>Compromises in the Choice of L4S Identifier</name>
      <t>This appendix is informative, not normative. As explained in <xref target="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
      identifier involves tradeoffs. trade-offs. This appendix records the pros and cons
      of the choice that was made.</t>
      <t>Non-normative recap of the chosen codepoint scheme:</t>
      <ul empty="true" spacing="normal"> spacing="normal" empty="true">
	<li>
          <t>Packets with ECT(1) and conditionally packets with CE signify L4S
          semantics as an alternative to the semantics of Classic
          ECN <xref
          ECN <xref target="RFC3168" format="default"/>, specifically:</t>
          <ul spacing="normal">
            <li>The ECT(1) codepoint signifies that the packet was sent by an
              L4S-capable sender.</li>
            <li>Given the shortage of codepoints, both the L4S and Classic ECN sides
              of an AQM have to use the same CE codepoint to indicate that a
              packet has experienced congestion. If a packet that had already
              been marked CE in an upstream buffer arrived at a subsequent
              AQM, this AQM would then have to guess whether to classify CE
              packets as L4S or Classic ECN.
              Choosing the L4S treatment is a
              safer choice, because then a few Classic packets might arrive
              early,
              early rather than a few L4S packets arriving late.</li>
            <li>Additional information might be available if the classifier
              were transport-aware. Then Then, it could classify a CE packet for
              Classic ECN treatment if the most recent ECT packet in the same
              flow had been marked set to ECT(0). However, the L4S service ought not
              to
              need transport-layer awareness.</li>
          </ul>
        </li>
      </ul>
      <t>Cons:</t>
      <dl newline="false" spacing="normal">
        <dt>Consumes the last ECN codepoint:</dt>
        <dd>The L4S service could
          potentially supersede the service provided by Classic ECN, therefore ECN; therefore,
          using ECT(1) to identify L4S packets could ultimately mean that the
          ECT(0) codepoint was 'wasted' purely to distinguish one form of ECN
          from its successor.</dd>
        <dt>ECN hard in some lower layers:</dt>
        <dd>It is not always
          possible to support the equivalent of an IP-ECN field in an AQM
          acting in a buffer below the IP layer <xref layer <xref target="I-D.ietf-tsvwg-ecn-encap-guidelines" format="default"/>. Then, depending on
          the lower layer lower-layer scheme, the L4S service might have to drop rather
          than mark frames even though they might encapsulate an ECN-capable
          packet.</dd>
        <dt>Risk of reordering Classic CE packets within a flow:</dt>
        <dd anchor="l4sid_CE_reordering">
          <t>Classifying
          all CE packets into the L4S queue risks any CE packets that were
          originally ECT(0) being incorrectly classified as L4S. If there were
          delay in the Classic queue, these incorrectly classified CE packets
          would arrive early, which is a form of reordering. Reordering within
          a microflow can cause TCP senders (and senders of similar
          transports) to retransmit spuriously. However, the risk of spurious
          retransmissions would be extremely low for the following
          reasons:</t>
          <ol spacing="normal" type="1"><li>It is quite unusual to experience queuing at more than one
              bottleneck on the same path (the available capacities have to be
              identical).</li>

            <li>In only a subset of these unusual cases would the first
              bottleneck support Classic ECN marking while and the second
              supported
              L4S ECN marking, which marking. This would be the only scenario
              where some ECT(0) packets could be CE marked by an AQM
              supporting Classic ECN then while subsequently the remainder experienced remaining ECT(0) packets would experience further
              delay through the Classic side of a subsequent L4S DualQ
              AQM.</li>
            <li>
              <t>Even then, when a few packets are delivered early, it takes
              very unusual conditions to cause a spurious retransmission, in
              contrast to when some packets are delivered late. The first
              bottleneck has to apply CE-marks CE marks to at least N contiguous
              packets
              packets, and the second bottleneck has to inject an uninterrupted
              sequence of at least N of these packets between two packets
              earlier in the stream (where N is the reordering window that the
              transport protocol allows before it considers a packet is
              lost).</t>
              <ul empty="true" spacing="normal"> spacing="normal" empty="true">

                <li>For example example, consider N=3, and consider the sequence of
                  packets 100, 101, 102, 103,... and imagine Imagine that packets
                  150,151,152
                  150, 151, 152 from later in the flow are injected as follows:
                  100, 150, 151, 101, 152, 102, 103... 103,... If this were late
                  reordering, even one packet arriving out of sequence would
                  trigger a spurious retransmission, but there is no spurious
                  retransmission here with early reordering, because packet
                  101 moves the cumulative ACK counter forward before 3
                  packets have arrived out of order.
                  Later, when packets 148,
                  149, 153... 153,... arrive, even though there is a 3-packet hole,
                  there will be no problem, because the packets to fill the
                  hole are already in the receive buffer.</li>
              </ul>
            </li>
            <li>Even with the current TCP recommendation of N=3 <xref N=3 <xref target="RFC5681" format="default"/> format="default"/>, spurious retransmissions will be unlikely for
              all the above reasons. As RACK <xref RACK <xref target="RFC8985" format="default"/> is
              becoming widely deployed, it tends to adapt its reordering
              window to a larger value of N, which will make the chance of a
              contiguous sequence of N early arrivals vanishingly small.</li>
            <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
              that supports Classic ECN marking marking, and it takes great care to
              separate out flows and to space any markings evenly along each
              flow.</li>
          </ol>
          <t>It is extremely unlikely that the above set of 5
          eventualities that are each unusual in themselves would all happen
          simultaneously. But, even if they did, the consequences would hardly
          be dire: the odd spurious fast retransmission. Whenever the traffic
          source (a Classic congestion control) mistakes the reordering of a
          string of CE marks for a loss, one might think that it will reduce
          its congestion window as well as emitting a spurious retransmission.
          However, it would have already reduced its congestion window when
          the CE markings arrived early. If it is using ABE <xref ABE <xref target="RFC8511" 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
          detects that the retransmission was spurious.</t>
          <t>In conclusion, the impact of early reordering on
          spurious retransmissions due to CE being ambiguous will generally be
          vanishingly small.</t>
        </dd>
        <dt>Insufficient anti-replay window in some pre-existing VPNs:</dt>
        <dd>If
          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
          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
          relevant specifications.
	  However, in some VPN implementations implementations, the
          maximum anti-replay window is insufficient to cater for a large
          delay difference at prevailing packet rates. <xref target="l4sid_VPN_anti-replay" format="default"/> suggests alternative work-rounds
          for such cases, but end-users end users using L4S over a VPN will need to be
          able to recognize the symptoms of this problem, in order to seek out
          these work-rounds.</dd>
        <dt>Hard to distinguish Classic ECN AQM:</dt>
        <dd>
          <t>With this scheme,
          when a source receives ECN feedback, it is not explicitly clear
          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
          will recognize the ECT(0) packets as Classic and apply the
          appropriate Classic ECN marking ECN-marking behaviour.</t>
          <t>However, in the absence of explicit disambiguation
          of the CE markings, an L4S source needs to use heuristic techniques
          to work out which type of congestion response to apply (see <xref target="l4sid_sec_fallback_on_classic_CE" format="default"/>).
          Otherwise, if
          long-running Classic flow(s) flows are sharing a Classic ECN AQM
          bottleneck with long-running L4S flow(s), which then flows, and the L4S flows apply an L4S
          response to the Classic CE signals, the L4S flows they would then outcompete the
          Classic flow(s). flows. Experiments have shown that L4S flows can take
          about 20 times more capacity share than equivalent Classic flows.
          Nonetheless, as link capacity reduces (e.g. to (e.g., to 4 Mb/s), the
          inequality reduces. So Classic flows always make progress and are
          not starved.</t>
          <t>When L4S was first proposed (in
          2015, 14 years after the Classic ECN spec <xref spec <xref target="RFC3168" format="default"/> was published), it was believed that Classic ECN
          AQMs had failed to be deployed, deployed because research measurements had
          found little or no evidence of CE marking.
          In subsequent years years,
          Classic ECN was included in per-flow-queuing (FQ) deployments,
          however FQ deployments;
          however, an FQ scheduler stops an L4S flow outcompeting Classic,
          because it enforces equality between flow rates. It is not known
          whether there have been any non-FQ deployments of Classic ECN AQMs
          in the subsequent years, years or whether there will be any in future.</t>
          <t>An algorithm for detecting a Classic ECN AQM as soon
          as a flow stabilizes after start-up has been proposed <xref proposed <xref target="ecn-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
          reasonably good for Classic ECN AQMs, in a wide range of
          circumstances.
          However, although it can correctly detect an L4S ECN
          AQM in many circumstances, its it is often incorrect at low link
          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>
        </dd>
        <dt>Non-L4S service for control packets:</dt>
        <dd>Solely for the
          case of TCP, the Classic ECN RFCs <xref RFCs <xref target="RFC3168" format="default"/> and
          <xref target="RFC5562" format="default"/> require a sender to clear the ECN IP-ECN field to
          Not-ECT on retransmissions and on certain control packets packets,
          specifically pure ACKs, window probes probes, and SYNs. When L4S packets are
          classified by the ECN IP-ECN field, these TCP control packets would not be
          classified into an L4S queue, queue and could therefore be delayed
          relative to the other packets in the flow. This would not cause
          reordering (because retransmissions are already out of order, and
          these control packets typically carry no data). However, it would
          make critical TCP control packets more vulnerable to loss and delay.
          To address this problem, ECN++ <xref 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
          long as appropriate ECN feedback is available in each case.</dd>
      </dl>
      <t>Pros:</t>
      <dl newline="false" spacing="normal">
        <dt>Should work e2e:</dt> end to end:</dt>
        <dd>The ECN IP-ECN field generally propagates
          end-to-end
          end to end across the Internet without being wiped or mangled, at
          least over fixed networks. Unlike the DSCP, the setting of the ECN
          field is at least meant to be forwarded unchanged by networks that
          do not support ECN.</dd>
        <dt>Should work in tunnels:</dt>
        <dd>The L4S identifiers work
          across and within any tunnel that propagates the ECN IP-ECN field in any of
          the variant ways it has been defined since ECN-tunneling was first
          specified in the year 2001 <xref 2001 <xref target="RFC3168" format="default"/>. However,
          it is likely that some tunnels still do not implement ECN
          propagation at all.</dd>
        <dt>Should work for many link technologies:</dt>
        <dd>At most, but
          not all, path bottlenecks there is IP-awareness, IP awareness, so that L4S AQMs
          can be located where the IP-ECN field can be manipulated.
          Bottlenecks at lower layer lower-layer nodes without IP-awareness either IP awareness have to either use
          drop to signal congestion or have a specific congestion notification
          facility has to be defined for that link technology, including
          propagation to and from IP-ECN. The programme to define these is
          progressing
          progressing, and in each case so far far, the scheme already defined for
          ECN inherently supports L4S as well (see <xref target="l4sid_encaps_no_change" format="default"/>).</dd>
        <dt>Could migrate to one codepoint:</dt>
        <dd>If all Classic ECN
          senders eventually evolve to use the L4S service, the ECT(0)
          codepoint could be reused for some future purpose, purpose but only once use
          of ECT(0) packets had has reduced to zero, or near-zero, near zero, which might
          never happen.</dd>
        <dt>L4 not required:</dt>
        <dd>Being based on the ECN IP-ECN field, this
          scheme does not need the network to access transport layer transport-layer flow
          identifiers.
          IDs. Nonetheless, it does not preclude solutions that
          do.</dd>
      </dl>
    </section>
    <section numbered="true" toc="default">
      <name>Potential Competing Uses for the ECT(1) Codepoint</name>
      <t>The ECT(1) codepoint of the ECN IP-ECN field has already been assigned once
      for the ECN nonce <xref nonce spec <xref target="RFC3540" format="default"/>, which has now been
      categorized as historic <xref Historic <xref target="RFC8311" format="default"/>. ECN is probably
      the only remaining field in the Internet Protocol that is common to IPv4
      and IPv6 and still has potential to work end-to-end, end to end, with tunnels and
      with lower layers. Therefore, ECT(1) should not be reassigned to a
      different experimental use (L4S) without carefully assessing competing
      potential uses.
      These fall into the following categories:</t> categories described below.</t>
      <section anchor="l4sid_competing_integrity" numbered="true" toc="default">
        <name>Integrity of Congestion Feedback</name>
        <t>Receiving hosts can fool a sender into downloading faster by
        suppressing feedback of ECN marks (or of losses if retransmissions are
        not necessary or available otherwise).</t>
        <t>The historic Historic ECN nonce protocol <xref spec <xref target="RFC3540" format="default"/>
        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
        packet was lost or congestion marked, the receiver would miss that bit
        of the sequence. An ECN Nonce nonce receiver had to feed back the least
        significant least-significant
        bit of the sum, so it could not suppress feedback of a
        loss or mark without a 50-50 chance of guessing the sum
        incorrectly.</t>
        <t>It is highly unlikely that ECT(1) will be needed as a nonce for
        integrity protection of congestion notifications in future. The ECN
        Nonce RFC <xref
        nonce spec <xref target="RFC3540" format="default"/> has been reclassified as
        historic,
        Historic, partly because other ways (that do not consume a codepoint
        in the IP header) have been developed to protect feedback integrity of
        TCP and other transports <xref transports <xref target="RFC8311" format="default"/>. For
        instance:</t>
        <ul spacing="normal">
          <li>the
          <li>The sender can test the integrity of a small random sample of
            the receiver's feedback by occasionally setting the IP-ECN field
            to a value normally only set by the network. Then
            Then, it can test
            whether the receiver's feedback faithfully reports what it expects
            (see para Paragraph 2 of Section 20.2 of the ECN spec <xref <xref target="RFC3168" format="default"/>. sectionFormat="of" section="20.2">the ECN spec</xref>. This works for loss loss, and it will work for the
            accurate ECN feedback <xref feedback <xref target="RFC7560" format="default"/> intended for
            L4S. Like the (historic) (Historic) ECN nonce, nonce spec, this technique does not
            protect against a misbehaving sender. But it allows a well-behaved
            sender to check that each receiver is correctly feeding back
            congestion notifications.</li>
          <li>A network can check that its ECN markings (or packet losses)
            have been passed correctly round around the full feedback loop by
            auditing congestion exposure (ConEx) <xref Congestion Exposure (ConEx) <xref target="RFC7713" format="default"/>. This assures that the integrity of congestion
            notifications and feedback messages must have both been preserved.
            ConEx information is also available anywhere along the network
            path, so it can be used to enforce a congestion response. Whether
            the receiver or a downstream network is suppressing congestion
            feedback or the sender is unresponsive to the feedback, or both,
            ConEx is intended to neutralise neutralize any advantage that any of these
            three parties would otherwise gain.</li>
          <li>Congestion feedback fields in transport layer transport-layer headers are
            immutable end-to-end, end to end and therefore amenable to end-to-end
            integrity protection. This preserves the integrity of a receiver's
            feedback messages to the sender, but it does not protect against
            misbehaving receivers or misbehaving senders. The TCP
            authentication option (TCP-AO <xref
            Authentication Option (TCP-AO) <xref target="RFC5925" format="default"/>), format="default"/>,
            QUIC's end-to-end protection <xref target="RFC9001" format="default"/> format="default"/>, or
            end-to-end IPsec integrity protection <xref target="RFC4303" format="default"/> can
            be used to detect any tampering with congestion feedback (whether
            malicious or accidental). respectively accidental), respectively, in TCP, QUIC QUIC, or any
            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
            paths, where middleboxes can make verification fail in their
            attempts to improve performance or security, e.g. by e.g., by
            resegmentation or shifting the sequence space.</li>
        </ul>
        <t>At the time of writing, It it is becoming common to protect the
        integrity of transport feedback using QUIC. However, it is still not
        common to protect the integrity of the wider congestion feedback, feedback loop,
        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 numbered="true" toc="default">
        <name>Notification of Less Severe Congestion than CE</name>
        <t>Various researchers have proposed to use ECT(1) as a less severe
        congestion notification than CE, particularly to enable flows to fill
        available capacity more quickly after an idle period, when another
        flow departs or when a flow starts, e.g. VCP <xref e.g., the Variable-structure congestion Control Protocol (VCP) <xref target="VCP" format="default"/>, format="default"/> and Queue View (QV) <xref (QV) <xref target="QV" format="default"/>.</t>
        <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
        future standardisation standardization of rapid flow acceleration, which is an
        important and enduring problem <xref problem <xref target="RFC6077" format="default"/>.</t>
        <t>Pre-Congestion Notification (PCN) is another scheme that assigns
        alternative semantics to the ECN IP-ECN field. It uses ECT(1) to signify a
        less severe level of pre-congestion notification than CE <xref CE <xref target="RFC6660" format="default"/>. However, the ECN IP-ECN field only takes on the PCN
        semantics if packets carry a Diffserv codepoint defined to indicate
        PCN marking within a controlled environment. PCN is required to be
        applied solely to the outer header of a tunnel across the controlled
        region in order not to interfere with any end-to-end use of the ECN
        field. Therefore, a PCN region on the path would not interfere with
        the L4S service identifier defined in <xref target="l4sid_identification" format="default"/>.</t>
      </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">
          <t hangText="From briscoe-...-00 to briscoe-...-01:">Technical
          changes:<list style="symbols">
              <t/>
            </list>Editorial changes:<list style="symbols">
              <t/>
            </list></t>
        </list></t>
    </section>
-->

    <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 <contact fullname="Richard Scheffenegger"/>, <contact
    fullname="John Leslie"/>, <contact fullname="David Täht"/>, <contact
    fullname="Jonathan Morton"/>, <contact fullname="Gorry Fairhurst"/>,
    <contact fullname="Michael Welzl"/>, <contact fullname="Mikael
    Abrahamsson"/>, and <contact fullname="Andrew McGregor"/> for the
    discussions that led to this specification.
      Ing-jyh  <contact fullname="Ing-jyh
    (Inton) Tsang Tsang"/> was a contributor to the early drafts draft versions of this
    document. And thanks 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 <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,
      Pete Heist, Stuart Cheshire, Vidhi Goel, Mirja Kuehlewind, Ermin
      Sakic and Martin Duke 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 draft, and document. And thanks to Ingemar Johansson <contact fullname="Ingemar Johansson"/> for
    reviewing and providing substantial text. Thanks also to the area
    reviewers: Valery Smyslov, Maria <contact fullname="Valery Smyslov"/>, <contact fullname="Maria
    Ines
      Robles, Bernard Aboba, Lars Eggert, Roman Danyliw and Eric Vyncke. Robles"/>, <contact fullname="Bernard Aboba"/>, <contact
    fullname="Lars Eggert"/>, <contact fullname="Roman Danyliw"/>, and <contact
    fullname="Éric Vyncke"/>.  Thanks to Sebastian Moeller <contact fullname="Sebastian
    Moeller"/> for identifying the interaction with VPN anti-replay and to Jonathan Morton
    <contact fullname="Jonathan Morton"/> for identifying the attack based on
    this. Particular thanks to tsvwg chairs Gorry Fairhurst, David Black <contact fullname="Gorry
    Fairhurst"/>, <contact fullname="David Black"/>, and
      Wes Eddy <contact fullname="Wes
    Eddy"/> for patiently helping this and the other L4S drafts documents through the
    IETF process. <xref target="l4sps_tcp-prague-reqs" format="default"/> listing format="default"/>, which lists the Prague L4S Requirements Requirements, is based on text authored by Marcelo <contact
    fullname="Marcelo Bagnulo Braun Braun"/> that was originally an appendix to
    <xref target="I-D.ietf-tsvwg-l4s-arch" 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 IETF 94 <xref target="TCPPrague"
    format="default"/>.</t>
    <t>The authors' contributions were part-funded partly funded by
    the European Community under its Seventh Framework Programme through the
    Reducing Internet Transport Latency (RITE) project (ICT-317700). The
    contribution of Koen <contact fullname="Koen De Schepper Schepper"/> was also part-funded
    partly funded by the 5Growth and DAEMON EU H2020 projects. Bob Briscoe <contact
    fullname="Bob Briscoe"/> was also funded partly funded by the Research Council of
    Norway through the TimeIn project, partly by CableLabs CableLabs, and partly by the
    Comcast Innovation Fund. The views expressed here are solely those of the
    authors.</t>

    </section>

</back>
</rfc>