<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-tsvwg-l4s-arch" target="https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-18">
   <front>
      <title>Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture</title>
      <author initials="B." surname="Briscoe" fullname="Bob Briscoe">
         <organization>Independent</organization>
      </author>
      <author initials="K." surname="De Schepper" fullname="Koen De Schepper">
         <organization>Nokia Bell Labs</organization>
      </author>
      <author initials="M." surname="Bagnulo" fullname="Marcelo Bagnulo">
         <organization>Universidad Carlos III de Madrid</organization>
      </author>
      <author initials="G." surname="White" fullname="Greg White">
         <organization>CableLabs</organization>
      </author>
      <date month="July" day="7" 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.

   The architecture primarily concerns incremental deployment.  It
   defines mechanisms that allow the new class of L4S congestion
   controls to coexist with &#x27;Classic&#x27; 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 &#x27;Classic&#x27; congestion controller, and that competing
   flows continuing to use &#x27;Classic&#x27; 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.

   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.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-l4s-arch-18" />
   
</reference>
