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

David Lang david at lang.hm
Wed Oct 19 17:33:28 EDT 2022


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

> On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire <cheshire at apple.com> 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


More information about the Bloat mailing list