L4S: Ultra-Low Queuing Delay for All

Low Latency Low Loss Scalable throughput (L4S) – a new default service for the Internet

We are so used to the unpredictability of queuing delay, we don’t know how good the Internet would feel without it. The RITE project has developed simple technology to make queuing delay a thing of the past—not just for a select few apps, but for all. With the resources on this page you can get a feel for the difference, understand how the solution works and help make it happen.

Queuing Delay? What’s the Problem?

The large majority of Internet traffic is capacity-seeking, usually by using TCP. Until each flow completes it will fill available capacity and the buffers intended to absorb bursts. This adds queuing delay for the flow itself and for other applications running at the same time.

People think voice and gaming need low delay, because they don’t work well otherwise. But, nowadays the performance of nearly every application depends at least as much on delay as on bandwidth, e.g. instant messaging, conversational video, interactive video, remote presence, jumping around streaming video like YouTube, and all those little interactive transfers over the web, web services, finance apps, as well as cloud-based apps, cloud-rendered video, remote desktop, video-assisted control of remote machinery and industrial process control. That’s pretty much everything.

In the presence of other long-running traffic flow(s) or when the application is itself a long-running flow, even with a well-tuned network, the base delay typically doubles, halving performance. Sometimes it can be a lot worse. So queuing delay is one of the main causes of the Internet’s unpredictability. Some delay-sensitive applications are capacity-seeking themselves, e.g. interactive video. For them, queuing delay is ever-present, because they inflict it on themselves.

“Ultra-Low Queuing Delay for All” in 4 minutes

Video of cloud-rendered Panoramic Interactive Video (PIV) compiled during the IETF Bits-N-Bites Exhibition, Prague, July 2015.

“Ultra-Low Queuing Delay for All” in 30 minutes

30-minute video Presentation of DualQ Coupled AQM, IETF AQM wg, July 2015, Prague

Click the image for a video presentation, live demo and questions about the DualQ Coupled AQM, The slot starts 33mins into the session.

Presented by Koen De Schepper of Bell Labs at the IETF-93 Active Queue Management (AQM) working group, Prague, Jul 2015.

The live demo is by remote login to Bell Labs’ testbed in Antwerp, which uses real network equipment: data centre, core, backhaul, DSL access and home networks.

Videos used in IETF dispatch WG “Ultra-Low Queuing Delay for All Apps” slot

(Note, these videos have no soundtrack, because they were intended to complement remote attendance at the meeting)

Video extract showing ultra-low delay finger-gesture Interaction with a cloud-rendered Panoramic Interactive Video (PIV) of a Football Stadium. The network paths for both the L4S (DCTCP) and the Classic (TCP Cubic) clients use the same broadband residential, DSL access and core networks built using production equipment. They both have a base delay of 7ms; downstream capacity of 40Mb/s; and 2-3 other background TCP flows in progress. The PIV application uses one TCP flow for the media, which consumes no more than about 4Mb/s, adapting if less is available.

.

Standards specifications

As the IETF L4S architecture explains, there are three main parts to IETF standardisation: the identifier (#1), the network algorithms (#2) and the host algorithms (#3):

  • IETF: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture and Problem Statement
    <draft-ietf-tsvwg-l4s-arch>
  1. An identifier for L4S packets
    • The IETF’s proposed new identifier for Low Latency, Low Loss, Scalable throughput (L4S) packets
      <draft-ietf-tsvwg-ecn-l4s-id>
      and the IETF’s enabling standards track RFC to make way for this
      <RFC8311>
    • The IETF is also in the process of assigning new standards track Diffserv codepoint to identify non-queue-building (NQB) traffic that could share the L4S queue with L4S traffic without all the usual bandwidth prioritization baggage of Diffserv:
      <draft-ietf-tsvwg-nqb>
  2. Then network operators can ensure L4S flows are isolated from existing Internet traffic in terms of latency, but they coexist in terms of throughput.
  3. And host developers can deploy new scalable TCP algorithms, e.g.
    • the Prague Congestion Control
      <draft-briscoe-iccrg-prague-congestion-control>
    • The L4S variant of SCReAM for real-time media;
      (L4S support is currently in the code:
      <https://github.com/EricssonResearch/scream/blob/master/README.md>
      but not yet described in the spec:
      <RFC8298>)
    • TCP Alpha/Preview Release of BBRv2;
      (L4S support is currently in the code:
      <https://github.com/google/bbr/blob/v2alpha/README.md>
      but not yet described in the draft spec:
      <draft-cardwell-iccrg-bbr-congestion-control-02>)
    • Prague and the L4S Support in BBRv2 are based on Data Centre TCP (DCTCP):
      <RFC8257>
      but DCTCP no longer works well over the Internet – it has not been maintained for this purpose.
    • Without steps #2 & #3, scalable TCPs are too aggressive to coexist with classic TCPs like Reno and Cubic, so DCTCP was initially confined to controlled networks like Data Centres, where all classic traffic sources could be upgraded (or isolated). To be safe over the public Internet, scalable congestion control algorithms will need to comply with the list of requirements agreed at an informally convened meeting in Prague that have become know as the TCP Prague requirements,  even though they apply whatever the transport protocol, not just TCP (e.g. QUIC, RTP). The IETF has since defined draft safety requirements for scalable congestion controls here: <draft-ietf-tsvwg-ecn-l4s-id#section-4>. This in turn refers to the following IETF specifications that address specific TCP Prague requirements:
      • Accurate ECN feedback, which the IETF has recognised will need an update to the TCP protocol, and it has stated the requirements a solution should comply with:
        <RFC7560>
        A candidate protocol to satisfy these requirements has been developed and adopted by the IETF:
        <draft-ietf-tcpm-accurate-ecn>
      • Adding ECN to TCP control packets:
        <draft-ietf-tcpm-generalized-ecn>
      • Recent ACKnowledgements: “RACK: a time-based fast loss detection algorithm for TCP”
        <draft-ietf-tcpm-rack>

Presentations

This list of presentations is not currently being maintained.

  • Ultra Low Queuing Delay for All; Koen De Schepper, Bob Briscoe, Olga Bondarenko & Inton Tsang, IETF ad hoc meeting (‘Bar BoF’) (Apr 2016) [odp|pdf]
  • L4S: A gradually deployable simplifying clean-slate opportunity, Bob Briscoe & Koen De Schepper, IETF ad hoc meeting (‘Bar BoF’) (Apr 2016) [ppt|pdf]
  • PI2 AQM for classic and scalable congestion control, Koen De Schepper (Bell Labs), Bob Briscoe, Olga Bondarenko (Simula), Ing-Jyh (Inton) Tsang (Bell Labs), Internet Research Task Force (IRTF) Internet congestion control research group (ICCRG), (Apr 2016) [pdf]
  • L4S Birds of a Feather (‘BoF’) held at the IETF in Berlin (Jul 2016)
  • L4S: Ultra-Low Queuing Delay for All; Bob Briscoe, Koen De Schepper, Olga Bondarenko & Inton Tsang, Stock presentation for network operators (Jul 2017) [odp|pdf]
  • “Flow-start: Faster and Less Overshoot with Paced Chirping” Joakim Misund and Bob Briscoe, Internet Congestion Control Research Group (Jul 2018), a proposed flow-start algorithm for TCP Prague [pdf]

Papers and Magazine Articles

Implementations

Source Code

Component Parts – Source Code

Implementations – Closed Source

Evaluations

Getting Involved