[NNagain] I keep hoping that we will turn this corner

[NNagain] I keep hoping that we will turn this corner

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 184 bytes --]

https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/


-- 
https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 618 bytes --]

Re: [NNagain] I keep hoping that we will turn this corner

[Dave Crocker]

On 6/1/2024 7:48 AM, Dave Taht via Nnagain wrote:
> https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/
>
A curse of being bright is failing to recognize when we aren't. If only 
there were a term for that...

Some decades back, I heard Kleinrock give a summary of queuing theory 
research where he reduced it to a graph.  Throughput vs. latency.  The 
curve was almost flat, rising only slightly, until the knee of the 
curve, which was quite sharp, going to almost vertical.  He noted that 
the math for this was complicated but the summary description was not:  
"Things are very, very good, until they are very very bad. When they are 
good, you don't need queuing.  When they are bad, queuing won't help; 
you need more capacity.  Queuing is for the brief and occasional period 
within the knee of the curve."

If it ain't transient then queuing isn't the answer.  If it is 
transient, you don't need lots of buffering.

Systems thinking is not natural for most of us, and bufferbloat is an 
example of local optimization without attention to systems effects.  For 
the list of push-backs your article cites, that lack of attention is due 
to excessive faith in entirely misguided intuitions.

Systems thinking requires quite a bit of skepticism about intuitions.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

Re: [NNagain] I keep hoping that we will turn this corner

[Robert McMahon]

[-- Attachment #1: Type: text/plain, Size: 2841 bytes --]

Queueing theory that I've read doesn't cover modern wireless networks such
as 802.11 where the fields and interactions in freespace are very different
than fields over a conducted copper wires or waveguides. And where the
receiving antennas can change orientation quite easily creating step
functions in so-called "network power" (throughput/latency) and where the
traffic loads are non linear and likely chaotic. And where the media access
is distributed in a way that A doesn't know what B, C, D, ... are doing to
the receiver(s). And where network designers assume a packet is a property
of nature vs a man made artifact. And where power per bit can no longer be
met by AC plugs & leashes but needs a mobile energy source and store.

The idea that there is a single optimum or single holy grail queue
algorithm for the parameter space seems misguided.

My view is the queue depth should be defined by the waveguide which is very
hard because end to end is not a single uniform waveguide, rather a lashing
together of disparate ones.

Networking is hard and we still haven't deployed fronthaul or Fi-Wi
networks which is going to take awhile.

Bob

On Sat, Jun 1, 2024, 8:24 AM Dave Crocker via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> On 6/1/2024 7:48 AM, Dave Taht via Nnagain wrote:
> >
> https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/
> >
> A curse of being bright is failing to recognize when we aren't. If only
> there were a term for that...
>
> Some decades back, I heard Kleinrock give a summary of queuing theory
> research where he reduced it to a graph.  Throughput vs. latency.  The
> curve was almost flat, rising only slightly, until the knee of the
> curve, which was quite sharp, going to almost vertical.  He noted that
> the math for this was complicated but the summary description was not:
> "Things are very, very good, until they are very very bad. When they are
> good, you don't need queuing.  When they are bad, queuing won't help;
> you need more capacity.  Queuing is for the brief and occasional period
> within the knee of the curve."
>
> If it ain't transient then queuing isn't the answer.  If it is
> transient, you don't need lots of buffering.
>
> Systems thinking is not natural for most of us, and bufferbloat is an
> example of local optimization without attention to systems effects.  For
> the list of push-backs your article cites, that lack of attention is due
> to excessive faith in entirely misguided intuitions.
>
> Systems thinking requires quite a bit of skepticism about intuitions.
>
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker@mastodon.social
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #2: Type: text/html, Size: 3992 bytes --]

Re: [NNagain] I keep hoping that we will turn this corner

[Dave Crocker]

On 6/1/2024 10:39 AM, Robert McMahon wrote:
> The idea that there is a single optimum or single holy grail queue 
> algorithm for the parameter space seems misguided.


Robert,

Welcome to the world of end-to-end analysis and design.  If your scope 
is only local, then local optimization probably makes sense.  If your 
scope is the Internet, it doesn't.

In any event, I believe the construct of bufferbloat does not dictate a 
single number, but a concern for 'too many'.

Determining what 'too many' is is fine as a separate exercise, as long 
as the answer isn't 'lots'...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social