Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Bob McMahon via Bloat]

Stuart's analogy seems better to me as it allows people to do something
else while waiting for an under-provisioned resource. And they may decide
that the wait isn't worth it at all. If the constraint moves to "entering
into the store" or "arrival rate to the grocery store doors" then the queue
just builds up in the parking lot vs the cashiers' lines. No real
difference.

Bob

On Tue, Dec 6, 2022 at 10:45 AM Michael Richardson via Make-wifi-fast <
make-wifi-f...@lists.bufferbloat.net> wrote:

>
> Stuart Cheshire via Bloat  wrote:
> >> I think the person with the cheetos pulling out a gun and shooting
> >> everyone in front of him (AQM) would not go down well.
>
> > Which is why starting with a bad analogy (people waiting in a grocery
> > store) inevitably leads to bad conclusions.
>
> > If we want to struggle to make the grocery store analogy work,
> perhaps
> > we show people checking some grocery store app on their smartphone
> > before they leave home, and if they see that a long line is beginning
> > to form they wait until later, when the line is shorter. The
> challenge
> > is not how to deal with a long queue when it’s there, it is how to
> > avoid a long queue in the first place.
>
> Maybe if we regard the entire grocery store as the "pipe", then we would
> realize that the trick to reducing checkout lines is to move the constraint
> from exiting, to entering the store :-)
>
> Then the different times you are in the store because you have different
> amounts of shopping to do, etc. and you get txt messages from spouse to
> remember to pick up X, and that somehow is an analogy to the various
> "PowerBoost" cable and LTE/5G systems that provide for inconsistent
> bandwidth.
>
> (There are various pushes to actually do this, as the experience from COVID
> was that having fewer people in the store pleased many people.)
>
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Matt Taggart via Bloat]

On 10/22/22 12:47, Sebastian Moeller wrote:


[SM] None of the real life models are all that well fitting for the problem, information 
simply is different from tangible objects in that dropping and resending on failure are 
less problematic. But that means that all "intuitive" analogies are out and 
trying to explain internet congestion and remedies with telegrams or even letters does 
not really help all that much (and in both cases dropping was rare and considered a 
failure not part of normal operations as far as I can see).


Hmm yes. I am trying to think of real world analogies where if a 
delivery is not on time it gets dropped.


What about practicing tennis with a robotic ball launcher? If it 
launches at too fast a rate the player won't be able to hit them all.


Also what about the Guitar Hero style games, where if you don't play the 
proper note falling down the screen, the music gets compoundingly worse. 
Maybe a good example for the bufferbloat worst-case thundering herd 
failure. I vaguely remember other games where failing to do something on 
time made it harder to do the next thing on time and it got worse quickly.


Here's another classic I just thought of, "I Love Lucy" in the chocolate 
factory :)


https://www.youtube.com/watch?v=AnHiAWlrYQc

That might make a good example in a talk.

--
Matt Taggart
m...@lackof.org
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Sebastian Moeller via Bloat]

Hi Dave,


> On Oct 22, 2022, at 20:58, Dave Taht via Bloat  
> wrote:
> 
> I did finally come up with a better analogy.
> 
> Imagine, instead, 1024 checkers all waiting, all the time, just for you!

Assuming the flow hash works well enough and the number of flows is 
small enough compared to the number of hash bins, this might be easier 
described as having an individual cashier per customer.
However this has a certain Kafka ring to it, see 
https://homepage.univie.ac.at/st.mueller/kafka_english.html

> (this is similar to how frys electronics used to work)

I only remember the fancy store design they had, each location 
different; I confess I actually stopped on trips to "visit" different novel 
Fry's locations.

> It's a computer! None of them have to get paid! It only costs 8k of
> memory to have them there!

But that still leaves the problem that the buildings egress capacity is 
limited and it might not be able to allow one customer per cashier to leave at 
the very same time.

> 
> I'd actually like to do a followup video with that guru floating above
> the cart, and maybe talk to wifi.

Are we sure what the guru is supposed to say yet? (Also didn't AmigaOS 
call some of its errors Guru Meditation? Apparently it did, see 
https://en.wikipedia.org/wiki/Guru_Meditation).


Regards
Sebastian


> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Sebastian Moeller via Bloat]

Hi Matt,


> On Oct 22, 2022, at 20:37, Matt Taggart via Bloat 
>  wrote:
> 
> On 10/17/22 19:58, David Lang via Bloat wrote:
> 
>> actually, fair queueing is more like the '15 items or less' lanes to speed 
>> through the people doing simple things rather than having them wait behind 
>> the mother of 7 doing their monthly shopping.
> 
> Sort of, but CoS/QoS could be described that way too? But at least it's based 
> on the quantity of items, CoS/QoS would be more like "moms with kids go in 
> this line, business execs go in this line, everybody else in this other line" 
> and "we have 4 checkers available for the business exec line, 2 for the 
> mom&kid line, and the remaining for everyone else".
> 
> Maybe the best is: I'm standing in long line with a huge cart of groceries 
> and there is a person behind me with only 3 things, so I tell them to go 
> ahead of me so their wait time isn't even worse. But usually this happens 
> because the people in line make it happen, the checkers default to FIFO out 
> of "fairness" (for some value of fair).
> 
> Maybe car-pool lanes are a good analogy, but some of them are HOV and some of 
> them allow you to pay to use...

[SM] None of the real life models are all that well fitting for the problem, 
information simply is different from tangible objects in that dropping and 
resending on failure are less problematic. But that means that all "intuitive" 
analogies are out and trying to explain internet congestion and remedies with 
telegrams or even letters does not really help all that much (and in both cases 
dropping was rare and considered a failure not part of normal operations as far 
as I can see).
Different queueing strategies have analogies (think a road/bridge pay terminal 
which might be single queue fifo or might offer multiple parallel booths) but 
AQM really is hard to get an analogy for... probably because most analogies put 
us into the mindset of an individual packet, while AQMs operate on the 
assumption of packet trains that will respond to signaling. To conjure 
something up this is a bit like going to the sports-ball game every Sunday with 
a special ticket that allows unlimited +1s if the stadion is not yet capacity 
and them telling you the time you (this is ECN) come with 10 friends to try 
with fewer friends next time... or simply only letting say 5 in (dropping the 
rest) so next time you try only with 5... that is all but intuitive.


Regards
Sebastian



> 
> Also couldn't resist :)
> 
> https://www.youtube.com/watch?v=RGWiTvYZR_w
> 
> -- 
> Matt Taggart
> m...@lackof.org
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Dave Taht via Bloat]

I did finally come up with a better analogy.

Imagine, instead, 1024 checkers all waiting, all the time, just for you!

(this is similar to how frys electronics used to work)

It's a computer! None of them have to get paid! It only costs 8k of
memory to have them there!

I'd actually like to do a followup video with that guru floating above
the cart, and maybe talk to wifi.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Matt Taggart via Bloat]

On 10/17/22 19:58, David Lang via Bloat wrote:

actually, fair queueing is more like the '15 items or less' lanes to 
speed through the people doing simple things rather than having them 
wait behind the mother of 7 doing their monthly shopping.


Sort of, but CoS/QoS could be described that way too? But at least it's 
based on the quantity of items, CoS/QoS would be more like "moms with 
kids go in this line, business execs go in this line, everybody else in 
this other line" and "we have 4 checkers available for the business exec 
line, 2 for the mom&kid line, and the remaining for everyone else".


Maybe the best is: I'm standing in long line with a huge cart of 
groceries and there is a person behind me with only 3 things, so I tell 
them to go ahead of me so their wait time isn't even worse. But usually 
this happens because the people in line make it happen, the checkers 
default to FIFO out of "fairness" (for some value of fair).


Maybe car-pool lanes are a good analogy, but some of them are HOV and 
some of them allow you to pay to use...


Also couldn't resist :)

https://www.youtube.com/watch?v=RGWiTvYZR_w

--
Matt Taggart
m...@lackof.org
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Stephen Hemminger via Bloat]

On Wed, 19 Oct 2022 14:33:28 -0700 (PDT)
David Lang via Bloat  wrote:

> On Wed, 19 Oct 2022, Stuart Cheshire via Bloat wrote:
> 
> > On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire  wrote:
> >  
> >> Accuracy be damned. The analogy to common experience resonates more.  
> >
> > I feel it is not an especially profound insight to observe that, “people 
> > don’t like waiting in line.” The conclusion, “therefore privileged people 
> > should get to go to the front,” describes an airport first class checkin 
> > counter, Disney Fastpass, and countless other analogies from everyday life, 
> > all of which are the wrong solution for packets in a network.  
> 
> the 'privileged go first' is traditional QoS, and it can work to some extent, 
> but is a nightmare to maintain and gets the wrong result most of the time.

A lot of times when this is proposed it has some business/political motivation.
It is like "priority boarding" for Global Services customers.
Not solving a latency problem, instead making stakeholders happy.

> AQM (fw_codel and cake) are more the 'cash only line' and '15 items or less' 
> line, they speed up the things that can be fast a LOT, while not 
> significantly 
> slowing down the people with a full baskets (but in the process, it shortens 
> the 
> lines for those people with full baskets)
> 
> >> I think the person with the cheetos pulling out a gun and shooting 
> >> everyone in front of him (AQM) would not go down well.  
> >
> > Which is why starting with a bad analogy (people waiting in a grocery 
> > store) inevitably leads to bad conclusions.
> >
> > If we want to struggle to make the grocery store analogy work, perhaps we 
> > show 
> > people checking some grocery store app on their smartphone before they 
> > leave 
> > home, and if they see that a long line is beginning to form they wait until 
> > later, when the line is shorter. The challenge is not how to deal with a 
> > long 
> > queue when it’s there, it is how to avoid a long queue in the first place.  
> 
> only somewhat, you aren't going to have people deciding not to click on a 
> link 
> because the network is busy, and if you did try to go that direction, I would 
> fight you. the prioritization is happening at a much lower level, which is 
> hard 
> to put into an analogy
> 
> even with the 'slowing' of bulk traffic, no traffic is prevented, it's just 
> that 
> they aren't allowed to monopolize the links.
> 
> This is where the grocery store analogy is weak, the reality would be more 
> like 
> 'the cashier will only process 30 items before you have to step aside and let 
> someone else in', but since no store operates that way, it would be a bad 
> analogy.

Grocery store analogies also breakdown because packets are not "precious"
it is okay to drop packets. A lot of AQM works by doing "drop early and often"
instead of "drop late and collapse".

> 
> >> Actually that analogy is fairly close to fair queuing. The multiple 
> >> checker analogy is one of the most common analogies in queue theory 
> >> itself.  
> >
> > I disagree. You are describing the “FQ” part of FQ_CoDel. It’s the “CoDel” 
> > part of FQ_CoDel that solves bufferbloat. FQ has been around for a long 
> > time, 
> > and at best it partially masked the effects of bufferbloat. Having more 
> > queues 
> > does not solve bufferbloat. Managing the queue(s) better solves bufferbloat.
> >  
> >> I like the idea of a guru floating above a grocery cart with a better 
> >> string of explanations, explaining
> >>
> >>   - "no, grasshopper, the solution to bufferbloat is no line... at all".  
> >
> > That is the kind of thing I had in mind. Or a similar quote from The 
> > Matrix. 
> > While everyone is debating ways to live with long queues, the guru asks, 
> > “What 
> > if there were no queues?” That is the “mind blown” realization.  
> 
> In a world where there is no universal scheduler (and no universal knowlege 
> to 
> base any scheduling decisions on), and where you are going to have malicious 
> actors trying to get more than their fair share, you can't rely on voluntary 
> actions to eliminate the lines.
> 
> There are data transportation apps that work by starting up a large number of 
> connections in parallel for the highest transfer speeds (shortening slow 
> start, 
> reducing the impact of lost packets as they only affect one connection, etc). 
> This isn't even malicious actors, but places like Hollywood studios sending 
> the raw movie footage around over dedicated leased lines and wanting to get 
> every bps of bandwidth that they are paying for used.
> 
> David Lang

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Michael Richardson via Bloat]

Stuart Cheshire via Bloat  wrote:
>> I think the person with the cheetos pulling out a gun and shooting
>> everyone in front of him (AQM) would not go down well.

> Which is why starting with a bad analogy (people waiting in a grocery
> store) inevitably leads to bad conclusions.

> If we want to struggle to make the grocery store analogy work, perhaps
> we show people checking some grocery store app on their smartphone
> before they leave home, and if they see that a long line is beginning
> to form they wait until later, when the line is shorter. The challenge
> is not how to deal with a long queue when it’s there, it is how to
> avoid a long queue in the first place.

Maybe if we regard the entire grocery store as the "pipe", then we would
realize that the trick to reducing checkout lines is to move the constraint
from exiting, to entering the store :-)

Then the different times you are in the store because you have different
amounts of shopping to do, etc. and you get txt messages from spouse to
remember to pick up X, and that somehow is an analogy to the various
"PowerBoost" cable and LTE/5G systems that provide for inconsistent
bandwidth.

(There are various pushes to actually do this, as the experience from COVID
was that having fewer people in the store pleased many people.)


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[David Lang via Bloat]

On Wed, 19 Oct 2022, Stuart Cheshire via Bloat wrote:


On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire  wrote:


Accuracy be damned. The analogy to common experience resonates more.


I feel it is not an especially profound insight to observe that, “people don’t 
like waiting in line.” The conclusion, “therefore privileged people should get 
to go to the front,” describes an airport first class checkin counter, Disney 
Fastpass, and countless other analogies from everyday life, all of which are 
the wrong solution for packets in a network.


the 'privileged go first' is traditional QoS, and it can work to some extent, 
but is a nightmare to maintain and gets the wrong result most of the time.


AQM (fw_codel and cake) are more the 'cash only line' and '15 items or less' 
line, they speed up the things that can be fast a LOT, while not significantly 
slowing down the people with a full baskets (but in the process, it shortens the 
lines for those people with full baskets)



I think the person with the cheetos pulling out a gun and shooting everyone in 
front of him (AQM) would not go down well.


Which is why starting with a bad analogy (people waiting in a grocery store) 
inevitably leads to bad conclusions.

If we want to struggle to make the grocery store analogy work, perhaps we show 
people checking some grocery store app on their smartphone before they leave 
home, and if they see that a long line is beginning to form they wait until 
later, when the line is shorter. The challenge is not how to deal with a long 
queue when it’s there, it is how to avoid a long queue in the first place.


only somewhat, you aren't going to have people deciding not to click on a link 
because the network is busy, and if you did try to go that direction, I would 
fight you. the prioritization is happening at a much lower level, which is hard 
to put into an analogy


even with the 'slowing' of bulk traffic, no traffic is prevented, it's just that 
they aren't allowed to monopolize the links.


This is where the grocery store analogy is weak, the reality would be more like 
'the cashier will only process 30 items before you have to step aside and let 
someone else in', but since no store operates that way, it would be a bad 
analogy.



Actually that analogy is fairly close to fair queuing. The multiple checker 
analogy is one of the most common analogies in queue theory itself.


I disagree. You are describing the “FQ” part of FQ_CoDel. It’s the “CoDel” 
part of FQ_CoDel that solves bufferbloat. FQ has been around for a long time, 
and at best it partially masked the effects of bufferbloat. Having more queues 
does not solve bufferbloat. Managing the queue(s) better solves bufferbloat.



I like the idea of a guru floating above a grocery cart with a better string of 
explanations, explaining

  - "no, grasshopper, the solution to bufferbloat is no line... at all".


That is the kind of thing I had in mind. Or a similar quote from The Matrix. 
While everyone is debating ways to live with long queues, the guru asks, “What 
if there were no queues?” That is the “mind blown” realization.


In a world where there is no universal scheduler (and no universal knowlege to 
base any scheduling decisions on), and where you are going to have malicious 
actors trying to get more than their fair share, you can't rely on voluntary 
actions to eliminate the lines.


There are data transportation apps that work by starting up a large number of 
connections in parallel for the highest transfer speeds (shortening slow start, 
reducing the impact of lost packets as they only affect one connection, etc). 
This isn't even malicious actors, but places like Hollywood studios sending 
the raw movie footage around over dedicated leased lines and wanting to get 
every bps of bandwidth that they are paying for used.


David Lang___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Stuart Cheshire via Bloat]

On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire  wrote:

> Accuracy be damned. The analogy to common experience resonates more.

I feel it is not an especially profound insight to observe that, “people don’t 
like waiting in line.” The conclusion, “therefore privileged people should get 
to go to the front,” describes an airport first class checkin counter, Disney 
Fastpass, and countless other analogies from everyday life, all of which are 
the wrong solution for packets in a network.

> I think the person with the cheetos pulling out a gun and shooting everyone 
> in front of him (AQM) would not go down well.

Which is why starting with a bad analogy (people waiting in a grocery store) 
inevitably leads to bad conclusions.

If we want to struggle to make the grocery store analogy work, perhaps we show 
people checking some grocery store app on their smartphone before they leave 
home, and if they see that a long line is beginning to form they wait until 
later, when the line is shorter. The challenge is not how to deal with a long 
queue when it’s there, it is how to avoid a long queue in the first place.

> Actually that analogy is fairly close to fair queuing. The multiple checker 
> analogy is one of the most common analogies in queue theory itself.

I disagree. You are describing the “FQ” part of FQ_CoDel. It’s the “CoDel” part 
of FQ_CoDel that solves bufferbloat. FQ has been around for a long time, and at 
best it partially masked the effects of bufferbloat. Having more queues does 
not solve bufferbloat. Managing the queue(s) better solves bufferbloat.

> I like the idea of a guru floating above a grocery cart with a better string 
> of explanations, explaining
> 
>   - "no, grasshopper, the solution to bufferbloat is no line... at all".

That is the kind of thing I had in mind. Or a similar quote from The Matrix. 
While everyone is debating ways to live with long queues, the guru asks, “What 
if there were no queues?” That is the “mind blown” realization.

Stuart Cheshire

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Sebastian Moeller via Bloat]

Hi Stuart,

On 18 October 2022 02:02:01 CEST, Stuart Cheshire via Bloat 
 wrote:
>On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast 
> wrote:
>
>> This was so massively well done, I cried. Does anyone know how to get in 
>> touch with the ifxit folk?
>> 
>> https://www.youtube.com/watch?v=UICh3ScfNWI
>
>I’m surprised that you liked this video. It seems to me that it repeats all 
>the standard misinformation. The analogy they use is the standard terrible 
>example of waiting in a long line at a grocery store, and the “solution” is 
>letting certain traffic “jump the line, angering everyone behind them”.
>
>Some quotes from the video:
>
>> it would be so much more efficient for them to let you skip the line and 
>> just check out, especially since you’re in a hurry, but they’re rudely 
>> refusing
>
>> to go back to our grocery store analogy this would be like if a worker saw 
>> you standing at the back ... and either let you skip to the front of the 
>> line or opens up an express lane just for you
>
>The video describes the problem of bufferbloat, and then describes the same 
>failed solution that hasn’t worked for the last three decades. Describing the 
>obvious simple-minded (wrong) solution that any normal person would think of 
>based on their personal human experience waiting in grocery stores and 
>airports, is not describing the solution to bufferbloat. The solution to 
>bufferbloat is not that if you are privileged then you get to “skip to the 
>front of the line”. The solution to bufferbloat is that there is no line!


[SM] Short of an oracle at all endpoints that seems as worthy a goal as 
impossible to achieve. IMHO the engineering should focus more on the 'fastest 
possible without any congestion' to acceptable performance (throughput and 
latency) in full and near saturation conditions. That is assume that, in spite 
of best efforts to avoid a line building, you need robust and reliable means to 
deal with lines that will sooner or later appear. 

>
>With grocery stores and airports people’s arrivals are independent and not 
>controlled. There is no way for a grocery store or airport to generate 
>backpressure to tell people to wait at home when a queue begins to form. The 
>key to solving bufferbloat is generating timely backpressure to prevent the 
>queue forming in the first place, 

[SM] Seems somewhat hard for my router on the bottleneck to transmit 
backpressure to the sending applications in less than 1/2 RTT at best, during 
that time sending rate and acceptable capacity share will not be matched 
L4S type signalling will only really help if the bottleneck's rate fluctuation 
is on a slower timeframe than the signaling delay. In short aiming for no/low 
queue is fine, but better carry a big stick as well for when the queue builds 
up.


not accepting a huge queue and then deciding who deserves special treatment to 
get better service than all the other peons who still have to wait in a long 
queue, just like before.

[SM] This is where a flow scheduler in practise helps a ton... as it
a) avoids starving individual flows as well as possible with minimal information
b) it tends to restrict the fall-out of under-responsive flows to those flows 
themselves (or to their hash bins).

In a sense this is the opposite of special treatment as all flows are treated 
with the same goal in mind

I am not really jousting for the video here, but I want to highlight that any 
short summary of a complex problem will have to gloss over some complexity (I 
expect you fully understood the points I make above, but omitted discussing 
them for brevity).

Regards
  Sebastian


>
>Stuart Cheshire
>
>___
>Bloat mailing list
>Bloat@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Bob McMahon via Bloat]

I agree with Stuart that there is no reason for shared lines in the first
place. It seems like a design flaw to have a common queue that congests in
a way that impacts the one transmit unit as the atomic forwarding plane
unit.  The goal of virtual output queueing
 is to eliminate
head of line blocking, every egress transmit unit gets its own cashier with
no competition.  The VOQ queue depths should support one transmit unit and
any jitter through the switching subsystem - jitter for the case of
non-bloat and where a faster VOQ service rate can drain the VOQ.  If the
VOQ can't be drained per a faster service rate, then it's just one
transmit unit as the queue is now just a standing queue w/delay and no
benefit.

Many network engineers typically, though incorrectly, perceive a transmit
unit as one ethernet packet. With WiFi it's one Mu transmission or one Su
transmission, with aggregation(s), which is a lot more than one ethernet
packet but it depends on things like MCS, spatial stream powers, Mu peers,
etc. and is variable. Some data center designs have optimized the
forwarding plane for flow completion times so their equivalent transmit
unit is a mouse flow.

I perceive applying AQM to shared queue congestion as a mitigation
technique to a poorly designed forwarding plane. The hope is that
transistor engineers don't do this and "design out the lines" from the
beginning. Better switching engineering vs queue management applied
afterwards as a mitigation technique.

Bob

On Mon, Oct 17, 2022 at 7:58 PM David Lang via Make-wifi-fast <
make-wifi-f...@lists.bufferbloat.net> wrote:

> On Mon, 17 Oct 2022, Dave Taht via Bloat wrote:
>
> > On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire 
> wrote:
> >>
> >> On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast <
> make-wifi-f...@lists.bufferbloat.net> wrote:
> >>
> >> > This was so massively well done, I cried. Does anyone know how to get
> in touch with the ifxit folk?
> >> >
> >> > https://www.youtube.com/watch?v=UICh3ScfNWI
> >>
> >> I’m surprised that you liked this video. It seems to me that it repeats
> all the standard misinformation. The analogy they use is the standard
> terrible example of waiting in a long line at a grocery store, and the
> “solution” is letting certain traffic “jump the line, angering everyone
> behind them”.
> >
> > Accuracy be damned. The analogy to common experience resonates more.
>
> actually, fair queueing is more like the '15 items or less' lanes to speed
> through the people doing simple things rather than having them wait behind
> the
> mother of 7 doing their monthly shopping.
>
> David Lang___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[David Lang via Bloat]

On Mon, 17 Oct 2022, Dave Taht via Bloat wrote:


On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire  wrote:


On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast 
 wrote:

> This was so massively well done, I cried. Does anyone know how to get in 
touch with the ifxit folk?
>
> https://www.youtube.com/watch?v=UICh3ScfNWI

I’m surprised that you liked this video. It seems to me that it repeats all the 
standard misinformation. The analogy they use is the standard terrible example 
of waiting in a long line at a grocery store, and the “solution” is letting 
certain traffic “jump the line, angering everyone behind them”.


Accuracy be damned. The analogy to common experience resonates more.


actually, fair queueing is more like the '15 items or less' lanes to speed 
through the people doing simple things rather than having them wait behind the 
mother of 7 doing their monthly shopping.


David Lang___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Sina Khanifar via Bloat]

Positive or negative, I can claim a bit of credit for this video :). We've
been working with LTT on a few projects and we pitched them on doing
something around bufferbloat. We've seen more traffic to our Waveforn test
than ever before, which has been fun!

On Mon, Oct 17, 2022 at 7:45 PM Dave Taht via Bloat <
bloat@lists.bufferbloat.net> wrote:

> On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire 
> wrote:
> >
> > On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast <
> make-wifi-f...@lists.bufferbloat.net> wrote:
> >
> > > This was so massively well done, I cried. Does anyone know how to get
> in touch with the ifxit folk?
> > >
> > > https://www.youtube.com/watch?v=UICh3ScfNWI
> >
> > I’m surprised that you liked this video. It seems to me that it repeats
> all the standard misinformation. The analogy they use is the standard
> terrible example of waiting in a long line at a grocery store, and the
> “solution” is letting certain traffic “jump the line, angering everyone
> behind them”.
>
> Accuracy be damned. The analogy to common experience resonates more.
>
> >
> > Some quotes from the video:
> >
> > > it would be so much more efficient for them to let you skip the line
> and just check out, especially since you’re in a hurry, but they’re rudely
> refusing
>
> I think the person with the cheetos pulling out a gun and shooting
> everyone in front of him (AQM) would not go down well.
>
> > > to go back to our grocery store analogy this would be like if a worker
> saw you standing at the back ... and either let you skip to the front of
> the line or opens up an express lane just for you
>
> Actually that analogy is fairly close to fair queuing. The multiple
> checker analogy is one of the most common analogies in queue theory
> itself.
>
> >
> > The video describes the problem of bufferbloat, and then describes the
> same failed solution that hasn’t worked for the last three decades.
>
> Hmm? It establishes the scenario, explains the problem *quickly*,
> disses gamer routers for not getting it right..  *points to an
> accurate test*, and then to the ideas and products that *actually
> work* with "smart queueing", with a screenshot of the most common
> (eero's optimize for gaming and videoconferencing), and fq_codel and
> cake *by name*, and points folk at the best known solution available,
> openwrt.
>
> Bing, baddabang, boom. Also the comments were revealing. A goodly
> percentage already knew the problem, more than a few were inspired to
> take the test,
> there was a whole bunch of "Aha!" success stories and 360k views,
> which is more people than we've ever been able to reach in for
> example, a nanog conference.
>
> I loved that folk taking the test actually had quite a few A results,
> without having had to do anything. At least some ISPs are getting it
> more right now!
>
> At this point I think gamers in particular know what "brands" we've
> tried to establish - "Smart queues", "SQM", "OpenWrt", fq_codel and
> now "cake" are "good" things to have, and are stimulating demand by
> asking for them,   It's certainly working out better and better for
> evenroute, firewalla, ubnt and others, and I saw an uptick in
> questions about this on various user forums.
>
> I even like that there's a backlash now of people saying "fixing
> bufferbloat doesn't solve everything" -
>
> >  Describing the obvious simple-minded (wrong) solution that any normal
> person would think of based on their personal human experience waiting in
> grocery stores and airports, is not describing the solution to bufferbloat.
> The solution to bufferbloat is not that if you are privileged then you get
> to “skip to the front of the line”. The solution to bufferbloat is that
> there is no line!
>
> I like the idea of a guru floating above a grocery cart with a better
> string of explanations, explaining
>
>- "no, grasshopper, the solution to bufferbloat is no line... at all".
>
> >
> > With grocery stores and airports people’s arrivals are independent and
> not controlled. There is no way for a grocery store or airport to generate
> backpressure to tell people to wait at home when a queue begins to form.
> The key to solving bufferbloat is generating timely backpressure to prevent
> the queue forming in the first place, not accepting a huge queue and then
> deciding who deserves special treatment to get better service than all the
> other peons who still have to wait in a long queue, just like before.
>
> I am not huge on the word "backpressure" here. Needs to signal the
> other side to slow down, is more accurate. So might say timely
> signalling rather than timely backpressure?
>
> Other feedback I got  was that the video was too smarmy (I agree),
> different audiences than gamers need different forms of outreach...
>
> but to me, winning the gamers has always been one of the most
> important things, as they make a lot of buying decisions, and they
> benefit the most for
> fq and packet prioritization as we do today in gamer rou

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Dave Taht via Bloat]

On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire  wrote:
>
> On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast 
>  wrote:
>
> > This was so massively well done, I cried. Does anyone know how to get in 
> > touch with the ifxit folk?
> >
> > https://www.youtube.com/watch?v=UICh3ScfNWI
>
> I’m surprised that you liked this video. It seems to me that it repeats all 
> the standard misinformation. The analogy they use is the standard terrible 
> example of waiting in a long line at a grocery store, and the “solution” is 
> letting certain traffic “jump the line, angering everyone behind them”.

Accuracy be damned. The analogy to common experience resonates more.

>
> Some quotes from the video:
>
> > it would be so much more efficient for them to let you skip the line and 
> > just check out, especially since you’re in a hurry, but they’re rudely 
> > refusing

I think the person with the cheetos pulling out a gun and shooting
everyone in front of him (AQM) would not go down well.

> > to go back to our grocery store analogy this would be like if a worker saw 
> > you standing at the back ... and either let you skip to the front of the 
> > line or opens up an express lane just for you

Actually that analogy is fairly close to fair queuing. The multiple
checker analogy is one of the most common analogies in queue theory
itself.

>
> The video describes the problem of bufferbloat, and then describes the same 
> failed solution that hasn’t worked for the last three decades.

Hmm? It establishes the scenario, explains the problem *quickly*,
disses gamer routers for not getting it right..  *points to an
accurate test*, and then to the ideas and products that *actually
work* with "smart queueing", with a screenshot of the most common
(eero's optimize for gaming and videoconferencing), and fq_codel and
cake *by name*, and points folk at the best known solution available,
openwrt.

Bing, baddabang, boom. Also the comments were revealing. A goodly
percentage already knew the problem, more than a few were inspired to
take the test,
there was a whole bunch of "Aha!" success stories and 360k views,
which is more people than we've ever been able to reach in for
example, a nanog conference.

I loved that folk taking the test actually had quite a few A results,
without having had to do anything. At least some ISPs are getting it
more right now!

At this point I think gamers in particular know what "brands" we've
tried to establish - "Smart queues", "SQM", "OpenWrt", fq_codel and
now "cake" are "good" things to have, and are stimulating demand by
asking for them,   It's certainly working out better and better for
evenroute, firewalla, ubnt and others, and I saw an uptick in
questions about this on various user forums.

I even like that there's a backlash now of people saying "fixing
bufferbloat doesn't solve everything" -

>  Describing the obvious simple-minded (wrong) solution that any normal person 
> would think of based on their personal human experience waiting in grocery 
> stores and airports, is not describing the solution to bufferbloat. The 
> solution to bufferbloat is not that if you are privileged then you get to 
> “skip to the front of the line”. The solution to bufferbloat is that there is 
> no line!

I like the idea of a guru floating above a grocery cart with a better
string of explanations, explaining

   - "no, grasshopper, the solution to bufferbloat is no line... at all".

>
> With grocery stores and airports people’s arrivals are independent and not 
> controlled. There is no way for a grocery store or airport to generate 
> backpressure to tell people to wait at home when a queue begins to form. The 
> key to solving bufferbloat is generating timely backpressure to prevent the 
> queue forming in the first place, not accepting a huge queue and then 
> deciding who deserves special treatment to get better service than all the 
> other peons who still have to wait in a long queue, just like before.

I am not huge on the word "backpressure" here. Needs to signal the
other side to slow down, is more accurate. So might say timely
signalling rather than timely backpressure?

Other feedback I got  was that the video was too smarmy (I agree),
different audiences than gamers need different forms of outreach...

but to me, winning the gamers has always been one of the most
important things, as they make a lot of buying decisions, and they
benefit the most for
fq and packet prioritization as we do today in gamer routers and in
cake + qosify.

maybe that gets in the way of more serious markets. Certainly I would
like another video explaining what goes wrong with videoconferencing.






>
> Stuart Cheshire
>


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.buffe

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Stuart Cheshire via Bloat]

On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast 
 wrote:

> This was so massively well done, I cried. Does anyone know how to get in 
> touch with the ifxit folk?
> 
> https://www.youtube.com/watch?v=UICh3ScfNWI

I’m surprised that you liked this video. It seems to me that it repeats all the 
standard misinformation. The analogy they use is the standard terrible example 
of waiting in a long line at a grocery store, and the “solution” is letting 
certain traffic “jump the line, angering everyone behind them”.

Some quotes from the video:

> it would be so much more efficient for them to let you skip the line and just 
> check out, especially since you’re in a hurry, but they’re rudely refusing

> to go back to our grocery store analogy this would be like if a worker saw 
> you standing at the back ... and either let you skip to the front of the line 
> or opens up an express lane just for you

The video describes the problem of bufferbloat, and then describes the same 
failed solution that hasn’t worked for the last three decades. Describing the 
obvious simple-minded (wrong) solution that any normal person would think of 
based on their personal human experience waiting in grocery stores and 
airports, is not describing the solution to bufferbloat. The solution to 
bufferbloat is not that if you are privileged then you get to “skip to the 
front of the line”. The solution to bufferbloat is that there is no line!

With grocery stores and airports people’s arrivals are independent and not 
controlled. There is no way for a grocery store or airport to generate 
backpressure to tell people to wait at home when a queue begins to form. The 
key to solving bufferbloat is generating timely backpressure to prevent the 
queue forming in the first place, not accepting a huge queue and then deciding 
who deserves special treatment to get better service than all the other peons 
who still have to wait in a long queue, just like before.

Stuart Cheshire

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat