Hi Stuart,
On 18 October 2022 02:02:01 CEST, Stuart Cheshire via Bloat
<bl...@lists.bufferbloat.net> 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”.
>
>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
>bl...@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
