Ultra-Low Queuing Delay for All

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, interactive video, jumping around streaming video like YouTube, and all those little transfers over the Web. That’s pretty much everything.

Two flows might not coincide that often, but when they do, 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 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 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.

.

IETF specifications

There are three parts to standardisation, the identifier, the network algorithm and the host algorithm:

  1. A proposed new identifier for Low Latency, Low Loss, Scalable throughput (L4S) packets
    <draft-briscoe-tsvwg-ecn-l4s-id>
  2. Then network operators can deploy a new simple active queue management algorithm, that complies with the few constraints specified here:
    <draft-briscoe-aqm-dualq-coupled>
    Example algorithms are given in an appendix.
  3. And host developers can deploy new scalable TCP algorithms, e.g. Data Centre TCP (DCTCP):
    <draft-ietf-tcpm-dctcp>
    Without steps #1 & #2, 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 TCP 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:

    • One of these requirements is 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:
      <draft-ietf-tcpm-accurate-ecn>

IETF Bar BoF supporting materials

  • Ultra Low Queuing Delay for All; Bar BoF [odp|pdf]
  • L4S: A gradually deployable simplifying clean-slate opportunity [ppt|pdf]

Papers and Magazine Articles

  • Article in the IETF Journal describing the Demo in Bits-N-Bites at the IETF in Prague, July 2015.
    Bob Briscoe, “Ultra-Low Delay for All” IETF Journal, Nov 2015.
  • Pre-print of paper explaining why scalable TCP algorithms solve the problem (in plain english and maths), how the Dual Queue Coupled AQM algorithm works, and recording the results of extensive testbed experiments.
    De Schepper, K., Bondarenko, O., Tsang, I.-J. and Briscoe, B. “`Data Centre to the Home’: Ultra-Low Latency for All” (Under submission, 2015)
  • Report (RITE project deliverable D3.3) including:
    • QoS Simplification Objectives from a network operator (BT) (Section 3.1)
    • HTTP Adaptive Streaming (HAS) and Web tests of DualQ Coupled (Section 3)
    • Panoramic Interactive Video and Web tests of DualQ Coupled (Section 4)

Source Code

  • Dual Queue Coupled AQM for Linux (access available shortly)
  • Data Centre TCP for Linux (in the kernel), for FreeBSD (link <TBA>) and ns2.
  • Accurate ECN Feedback for Linux (initial – not the full spec, not fully tested)

Getting Involved