Skip to main content

Finding inspiration for low-latency Wi-Fi at the supermarket

Queues are an unavoidable fact of life. At the supermarket, the bank, or, worst of all, the airport. Various tactics are employed to reduce waiting times. At the supermarket you have individual queues per cashier, and they’ll open another checkout if needed. Alternatively, there’s a single queue for self-serve. At the airport, you have several queues according to priority boarding, and you can often pay to board more quickly.

In our telecom networks, I think we can learn a thing or two from these queuing tactics. In fact, it’s essential that we do because latency—when data packets are forced to queue—is becoming a huge issue. More and more Internet traffic is generated by apps that require exceptionally low latency, whether it’s mission-critical services, cloud computing or, especially, online gaming.

In the network, latency is, of course, an end-to-end phenomenon. But whenever we want to improve an end-to-end issue, we should always start with the weakest link. That weak spot is in-home Wi-Fi.

That’s why I’m proud that we’re the first technology vendor to introduce L4S into our Wi-Fi devices, the Nokia WiFi portfolio.

What’s L4S? I’m glad you asked! L4S is the—thankfully simple—acronym for “low loss, low latency, scalable throughput”. It’s the answer to managing delay in the vastness of the Internet. We’ve written a technical paper on L4S as it’s very technical, but I’ll try and summarize how it works.

Today, the Internet mainly uses Transmission Control Protocol (TCP) to manage traffic, but that prioritizes accurate delivery over timely delivery. TCP generates bursty traffic that relies on buffers in the network to achieve high throughput. During times of congestion buffers can build up resulting in bufferbloat and high latency. Active queue management (AQM) is a mechanism to prevent bufferbloat and the accompanied latency. AQM is not as widely deployed as you might expect as it has been difficult to tune the parameters to get good performance over a range of conditions. Bell Labs has developed an AQM scheme that works extremely well without tuning with the fabulously named “proportional integral controller improved with a square”, or PI2 for short. PI2 works well for classic TCP traffic, but still can’t guarantee consistent very low latency.

In data centers, they use Data Center TCP (DCTCP), which marks data packets to indicate when congestion is encountered allowing the source to more quickly become aware and to react to the onset of congestion. The much quicker response allows buffers to be much smaller without experiencing packet loss, and therefore to experience much lower latency. However, DCTCP is only effective in a closed environment at a smaller scale, like in a data center, not the whole World Wide Web. To take DCTCP out of the data center, the IETF is developing TCP Prague.

L4S when used with TCP Prague and similar schemes meets the dual challenges of guaranteeing low latency at scale. It does this by following supermarkets and airports and—gasp!—adding a second queue in the network node. One queue handles classic TCP Internet traffic, prioritizing legacy applications; the other handles low latency traffic using L4S. What makes low latency traffic fairly share the network with classic traffic is a new coupled-dual-queue AQM (DualPI2) that directs packets to either the L4S AQM or a classic path AQM such as PI2, based on a the Explicit Congestion Notification (ECN) bits that are also used in DCTCP. A coupling between the two AQM paths provides fairness. I liken the end result to the helpful assistant at my supermarket who seems to have a sixth sense for pointing me towards the best queue, depending on whether my caddy is overflowing, or I only have a chocolate bar to buy.

We’ve tested L4S in various scenarios combining classic and low-latency traffic and achieved sub-millisecond average queuing delays and zero congestion loss. Gaming traffic can be guaranteed, classic traffic is uncompromised.

So that’s why we’ve put it straight into our Wi-Fi portfolio, starting with our popular Nokia WiFi Beacon 1.

Share your thoughts on this topic by joining the Twitter discussion with @nokianetworks or @nokia using #wifi

Laszlo Gyalog

About Laszlo Gyalog

Within Nokia’s Fixed Networks Division, Laszlo leads the Broadband Devices marketing, focusing on how to extend a broadband offer into the home with meshed Wi-Fi, and how to fully optimize the Wi-Fi performance with advanced analytics. Outside business hours, Laszlo enjoys toying around with anything technology related (he is an engineer after all), photography and going for long walks with his wife and their dog.

Tweet me @Laszlo_G

Article tags