[Bloat] Re: The hell has frozen: Latency mentioned at APNIC 62, during a keynote!

[Bloat] Re: The hell has frozen: Latency mentioned at APNIC 62, during a keynote!

[Stuart Cheshire]

> On Sep 10, 2026, at 10:37, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:
> 
> "The scarce resource is not bandwidth, or compute. It is latency."
> 
> https://conference.apnic.net/62/assets/presentation-files/93297823-389f-4ff6-ba5f-73cfe12a367b.pdf
> 
> Incredible. Thanks to Mohit for catching this gem.

Nice, but I would not express it that way.

Calling latency a “scarce resource” sends the wrong message. It reinforces the incorrect idea that low-latency service is a rare commodity, in short supply, that can only be provided to the small privileged minority that can afford it. This is the wrong-headed thinking behind priorities, traffic classes, DiffServ, etc. People assume latency, like bandwidth, is a zero-sum game. (“Better latency for me means worse latency for you.”) The great insight of L4S is that latency is not a zero-sum game. *All* traffic can receive low latency, and that benefit is not counterbalanced by some corresponding degradation elsewhere. L4S with short queues is just universally better than tail-drop with long queues, and there is no hidden caveat or disclaimer on that statement.

Instead of the word “scarce” I would use “important” or “valuable”.

It is true that milliseconds are precious -- once wasted you can’t get them back, but there is no scarcity of them.

Stuart Cheshire

[Bloat] Re: The hell has frozen: Latency mentioned at APNIC 62, during a keynote!

[Neal Cardwell]

On Thu, Sep 17, 2026 at 11:24 AM Stuart Cheshire via Bloat <
bloat@lists.bufferbloat.net> wrote:

> > On Sep 10, 2026, at 10:37, Frantisek Borsik <frantisek.borsik@gmail.com>
> wrote:
> >
> > "The scarce resource is not bandwidth, or compute. It is latency."
> >
> >
> https://conference.apnic.net/62/assets/presentation-files/93297823-389f-4ff6-ba5f-73cfe12a367b.pdf
> >
> > Incredible. Thanks to Mohit for catching this gem.
>
> Nice, but I would not express it that way.
>
> Calling latency a “scarce resource” sends the wrong message. It reinforces
> the incorrect idea that low-latency service is a rare commodity, in short
> supply, that can only be provided to the small privileged minority that can
> afford it. This is the wrong-headed thinking behind priorities, traffic
> classes, DiffServ, etc. People assume latency, like bandwidth, is a
> zero-sum game. (“Better latency for me means worse latency for you.”) The
> great insight of L4S is that latency is not a zero-sum game. *All* traffic
> can receive low latency, and that benefit is not counterbalanced by some
> corresponding degradation elsewhere. L4S with short queues is just
> universally better than tail-drop with long queues, and there is no hidden
> caveat or disclaimer on that statement.
>
> Instead of the word “scarce” I would use “important” or “valuable”.
>
> It is true that milliseconds are precious -- once wasted you can’t get
> them back, but there is no scarcity of them.


Well said.

Likewise, I would not call latency a "resource". The link is the resource.
Latency is a performance characteristic. Effective management of the
resource (with L4S or other schemes) can yield both low latency and high
throughput.

Calling latency a "resource" makes it sound like something that can be
built or purchased. One cannot build or purchase low latency. You can
purchase hardware that allows low latency, but you still have to deploy
protocols that know how to use the signals to achieve low latency and high
throughput.

So rather than saying: "The scarce resource is not bandwidth, or compute.
It is latency." ... perhaps: "The most important performance metric where
systems fall short today is not bandwidth, or compute. It is latency."

neal

[Bloat] Re: The hell has frozen: Latency mentioned at APNIC 62, during a keynote!

[Richard Scheffenegger]

In other news, ultra ethernet is using credit based flow control (to push queues back into the sender at much higher impact on efficiency if fibrechannel is any guidance)

Best regards,
   Richard Scheffenegger

> Am 17.09.2026 um 21:57 schrieb Neal Cardwell via Bloat <bloat@lists.bufferbloat.net>:
> 
> On Thu, Sep 17, 2026 at 11:24 AM Stuart Cheshire via Bloat <
> bloat@lists.bufferbloat.net> wrote:
> 
>>> On Sep 10, 2026, at 10:37, Frantisek Borsik <frantisek.borsik@gmail.com>
>> wrote:
>>> 
>>> "The scarce resource is not bandwidth, or compute. It is latency."
>>> 
>>> 
>> https://conference.apnic.net/62/assets/presentation-files/93297823-389f-4ff6-ba5f-73cfe12a367b.pdf
>>> 
>>> Incredible. Thanks to Mohit for catching this gem.
>> 
>> Nice, but I would not express it that way.
>> 
>> Calling latency a “scarce resource” sends the wrong message. It reinforces
>> the incorrect idea that low-latency service is a rare commodity, in short
>> supply, that can only be provided to the small privileged minority that can
>> afford it. This is the wrong-headed thinking behind priorities, traffic
>> classes, DiffServ, etc. People assume latency, like bandwidth, is a
>> zero-sum game. (“Better latency for me means worse latency for you.”) The
>> great insight of L4S is that latency is not a zero-sum game. *All* traffic
>> can receive low latency, and that benefit is not counterbalanced by some
>> corresponding degradation elsewhere. L4S with short queues is just
>> universally better than tail-drop with long queues, and there is no hidden
>> caveat or disclaimer on that statement.
>> 
>> Instead of the word “scarce” I would use “important” or “valuable”.
>> 
>> It is true that milliseconds are precious -- once wasted you can’t get
>> them back, but there is no scarcity of them.
> 
> 
> Well said.
> 
> Likewise, I would not call latency a "resource". The link is the resource.
> Latency is a performance characteristic. Effective management of the
> resource (with L4S or other schemes) can yield both low latency and high
> throughput.
> 
> Calling latency a "resource" makes it sound like something that can be
> built or purchased. One cannot build or purchase low latency. You can
> purchase hardware that allows low latency, but you still have to deploy
> protocols that know how to use the signals to achieve low latency and high
> throughput.
> 
> So rather than saying: "The scarce resource is not bandwidth, or compute.
> It is latency." ... perhaps: "The most important performance metric where
> systems fall short today is not bandwidth, or compute.

[Bloat] Re: The hell has frozen: Latency mentioned at APNIC 62, during a keynote!

[Stuart Cheshire]

On Sep 17, 2026, at 12:56, Neal Cardwell <ncardwell@google.com> wrote:

> Likewise, I would not call latency a "resource". The link is the resource. Latency is a performance characteristic. Effective management of the resource (with L4S or other schemes) can yield both low latency and high throughput.
> 
> Calling latency a "resource" makes it sound like something that can be built or purchased. One cannot build or purchase low latency. You can purchase hardware that allows low latency, but you still have to deploy protocols that know how to use the signals to achieve low latency and high throughput.

Very good point. This is 100% right.

A “resource” is something that exists in finite quantity, so you need to decide where to allocate that limited resource. Almost by definition, I think calling something a “resource” is synonymous with saying that its allocation is a zero-sum game.

Stuart Cheshire

[Bloat] Re: The hell has frozen: Latency mentioned at APNIC 62, during a keynote!

[Rich Brown]

We came up with a more accurate, but wordy declaration:

> "The most important performance metric where
> systems fall short today is not bandwidth, or compute. It is latency."


To make a more punchy statement, s/scarce resource/bottleneck/ to get...

>  "The bottleneck is not bandwidth, or compute. It is latency." 

Thoughts?

[Bloat] Re: The hell has frozen: Latency mentioned at APNIC 62, during a keynote!

[bob.mcmahon]

Hi All,

Just a reminder that bufferbloat isn't the only source of latency or 
jitter. Here's an animation showing some of the other places delay can 
accumulate over the pipeline w/Wi-Fi as a component.

https://www.umbernetworks.com/mac_collapse_lights.php

I'm still working out a few bugs in the animations, but the ideas are 
there. It's from the view of an AP radio or a Fi-Wi radio head, and 
ramps up the traffic from 50 clients.

The animation pipeline includes:

o) Send-side buffering
o) Bytes in flight
o) The 802.11 forwarding plane
o) 802.11 arbitration
o) DMA transfers
o) Over-the-air (OTA) transmission
o) OTA acknowledgment

Bob

PS. Iperf 2 is on the play store.  https://iperf2.fi-wi.com/  Let me 
know if it helps or not.

> We came up with a more accurate, but wordy declaration:
> 
>> "The most important performance metric where
>> systems fall short today is not bandwidth, or compute. It is latency."
> 
> 
> To make a more punchy statement, s/scarce resource/bottleneck/ to 
> get...
> 
>>  "The bottleneck is not bandwidth, or compute. It is latency."
> 
> Thoughts?
> 
> _______________________________________________
> Bloat mailing list -- bloat@lists.bufferbloat.net
> To unsubscribe send an email to bloat-leave@lists.bufferbloat.net

[Bloat] Re: The hell has frozen: Latency mentioned at APNIC 62, during a keynote!

[Sebastian Moeller]

> On Sep 18, 2026, at 14:11, Rich Brown <richb.hanover@gmail.com> wrote:
> 
> We came up with a more accurate, but wordy declaration:
> 
>> "The most important performance metric where
>> systems fall short today is not bandwidth, or compute. It is latency."
> 
> 
> To make a more punchy statement, s/scarce resource/bottleneck/ to get...
> 
>> "The bottleneck is not bandwidth, or compute. It is latency."
> 
> Thoughts?

tempted to re-arrange this (for in-official use among friends only):

Bandwidth is NOT the bottleneck (nor is it compute): it's the latency, Stupid.

Tip o'the hat to Stuart for the end part... 




> 
> _______________________________________________
> Bloat mailing list -- bloat@lists.bufferbloat.net
> To unsubscribe send an email to bloat-leave@lists.bufferbloat.net