On a recent Preseem podcast episode, we welcomed Jason Livingood, Vice President of Technology Policy, Product and Standards at Comcast, to chat about L4S, working latency, congestion control, and lots more.
Jason leads Comcast’s efforts in developing and deploying new open standards. In this role, he supports applied R&D via collaboration with the research community, engaging with governments, regulators, and other external key stakeholders on technology policy issues, and provides leadership on end-user product technology roadmap.
Jason is also a member of the board of directors at the Internet Engineering Task Force (IETF) and the Alliance for Telecommunications Industry Solutions, and a member of the Technical Advisory Council at the FCC.
What follows is a recap of the episode, but you can listen to the full discussion here. As always, the podcast is hosted by Dan Siemon, Chief Product Officer, and Jeremy Austin, Senior Product Manager at Preseem.
What is L4S?
For those unfamiliar with the term, L4S stands for Low-Latency, Low-Loss, Scalable Throughput. Comcast is currently rolling out an L4S trial and their goal is to dramatically improve on what Jason called the “working latency or network responsiveness of someone’s internet connection.”
An example of poor working latency came with the mass shift to remote work that happened when the COVID-19 pandemic began, where even those with 1GB fiber-to-the-home connections would occasionally experience delays with video calls.
“And the reason wasn’t lack of bandwidth, it was a latency problem,” said Jason. He said people only really pay attention to idle latency (e.g. when doing a ping test). However, once you start to actually use the connection, that’s where working latency comes into play. Addressing that is “the next frontier of performance improvement,” Jason said.
Working Latency and How L4S Can Help
Working latency is a relatively new term, and Jeremy asked why it’s taken so long for the industry to name it. As Jason explained, for a long time network engineers saw increased capacity, which often gets described as “speed,” as the way to improve end-user quality.
And while it’s true that increasing capacity can be a good proxy for improving quality of experience (QoE), the rise of real-time applications like video conferencing is placing new demands on networks at a scale not seen before.
There’s also been a larger philosophical challenge at play, Jason added. That is, many engineers thought you could have one of two things: either you could have very high throughput or very low latency, but you couldn’t have both. However, this was just an assumption and not backed up with data or proof.
Jason said L4S aims for dramatically lower working latency. As an example, in networks that don’t currently use Active Queue Management (AQM), you could be looking at a working latency of hundreds of milliseconds to whole seconds for just one roundtrip. Also, if you’re on a mobile app, that means lots of roundtrips that are then going to stack up on top of each other, further increasing latency to as much as 4 to 5 seconds.
Even with AQM, you might be at 25-250 ms of delay, depending on how far out you’re going from the access network. The objective with L4S is sub-10ms. Jason said Comcast is conducting field trials right now to see if this is achievable, and added that they’d be happy with a 99th percentile working latency of 25ms.
Where Does Latency Come From?
Or more specifically, where does latency come from in relation to congestion control algorithms? As Jason explained, when many of the TCP congestion control algorithms were originally developed, you’d have one computer connected to a connection with a limited number of flows (often just one). In the modern era, however, with dozens of IoT devices and multiple personal devices online, there are not only multiple flows but the amount of bandwidth that’s needed is constantly changing.
The challenge is finding a flow controller that has a very tight control loop and can quickly adapt to changing conditions. Otherwise, you can get dramatic back-off to reduce consumption, creating the classic sawtooth pattern. Part of the objective with L4S is to tighten those sawtooths, so they’re really tiny and able to adapt to the constantly changing traffic flows.
Dan added that, during those big “sawtooths,” queues build up in the network and that’s what creates latency. Buffering and not propagation latency is the problem, and it’s specifically those TCP flows filling the buffers that are a major cause.
L4S and the Evolving Internet
The panel also discussed whether L4S was essentially creating a two-channel internet, one with traditional congestion control, and one with a more aggressive lower-latency congestion control, with applications able to opt into the channel they prefer.
Jason agreed and said that, unlike previous approaches, with L4S the application is expected to do the marking. This is because the app developer knows their app best and it’s very hard for networks to guess that and get it right.
He added that often when network operators deploy systems that are doing prioritization or trying to infer what type of application is being used, it’s possible at one point in time to get it right, but by that time the applications are already multiple steps ahead because they’re iterating at a different pace. As a result, it becomes impossible to keep up.
L4S also gets around having to use things like DPI, traffic is examined and then prioritized based on the type of flow. That’s a lot more difficult with the pervasive encryption we have today, Jason said, and also those systems will always get it wrong at some point.
In the case of a large ISP like Comcast, “getting it wrong” can have major negative consequences for millions of subscribers. Jason also said it’s important to point out that both queues are at the same priority level and both share the same bandwidth. There’s no higher priority or lower priority at work with L4S, it’s simply dividing traffic by congestion control behavior.
The Comcast L4S Trial
Jason explained that Comcast is in the early stages of deploying L4S and is the first ISP to conduct field trials. He said they’ve had “overwhelming customer interest” in participating in the trials. This “really demonstrates to me that people have a better understanding of what latency, delay and lag is than they did a few years ago, maybe as a benefit of working from home during the pandemic,” he said.
After talking about what the trial will entail and how Comcast will measure success, the panel talked about the potential impact of L4S.
“This is potentially a seismic shift in the way that we think about networks and network services and (how we) deploy them,” Jason said. “And for years we’ve always thought just throw bandwidth at people and things get better,” but even people on smaller plans can still have a great internet experience if they have really low latency.
As Stuart Cheshire from Apple has mentioned, app developers have always assumed that there is delay when you access something over the network, usually high (and highly variable) delay. However, if you took that core foundational assumption away, and made it so that delay was roughly the same as on your LAN or local device, that drop in latency under load could fundamentally change the kinds of things that app developers could do, Jason said. This could significantly improve AR/VR capabilities, for example.
Jason pointed out that over the years people have just gotten used to hiccups during video calls or audio and video not syncing, and have been conditioned to think that that’s “just how the internet works”—something you just have to put up with it now and then. However, he said, “I think that’s just this latency problem and that can go away. It doesn’t have to work that way.”
If you’re interested in getting geeky with our team on these and other technical topics affecting internet service providers, follow the Preseem podcast and listen to all of our episodes here.
