Thread by @programmingart

Apple's @vidhigoel07 had a great session at #WWDC last week, talking about improving network latency through:

🔛implementation tuning (for example buffer sizing)
🔜network assistance (like L4S, the new Low-Latency, Low-Loss proposal!).

developer.apple.com/videos/play/ww…

Some thoughts👇

A big part of observed network latencies/delays is due to so-called bufferbloat:

Too large intermediate buffers, both on the endpoints and in the network, cause packets to stay in the buffer too long, delaying them.

On the endpoints, this can be improved by tuning buffer sizes for different protocols (TCP/QUIC, TLS and HTTP have their own buffers!). Default sizes are often too high.

Other good sources:
- blog.cloudflare.com/http-2-priorit…
- slideshare.net/kazuho/program… (the first I ever saw from @kazuho!)

In the network this is often done by Active Queue Management (AQM). This basically comes down to intentionally but smartly dropping some packets if buffers fill up, causing the senders' congestion controllers to slow down, reducing buffer occupancy

@mtaht is the expert on this!

However, using packet loss for this isn't ideal... why can't the network just tell senders to slow down in another way?

That's exactly what ECN (Explicit Congestion Notification) was made for. Here, middleboxes give explicit signals that congestion is (going to be) occurring.

ECN works, but has some problems.

A new, similar proposal called L4S (low-latency, low-loss, scalable throughput) aims to improve on the same ideas: ietf.org/archive/id/dra…

Apple is now (one of) the first to provide an L4S implementation to help test this new approach!

While L4S (like ECN) needs explicit network support to properly work (middleboxes need to set bits in packet headers), I do think this is the next big frontier for big network latency improvements.

And having good endpoint implementations is a crucial step!

Apple has also been working on a new way to measure bufferbloat with a specialized "Round-Trips per Minute" metric and tools to test it: ietf.org/archive/id/dra…

They even mention @hawkinsw's Go implementation (achievement unlocked!):

In conclusion, choosing the correct protocols (like HTTP/3) is often just the first step.

After that comes careful tuning of both endpoints and intermediate networks to squeeze out optimal performance, and that work is still very much active and ongoing!