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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Bob,

On 18 October 2022 19:03:21 CEST, Bob McMahon via Rpm <rpm@lists.bufferbloat.net> wrote:
>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. 

[SM] How does that generalize to internet access links? My gut feeling is that an FQ scheduler comes close.


 The goal of virtual output queueing
><https://en.wikipedia.org/wiki/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.

[SM] I guess often things are obvious only retrospectively, but how could one design a switch differently?


>
>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.

[SM] Is this driven more by the need to aggregate packets to amortize some cost over a larger payload or to reduce the scheduling overhead or to regularize things (as in fixed size DTUs used in DSL with G.INP retransmissions)?

>
>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.

[SM] I am all for better hardware, but will this ever allow us the regress back to dumb upper layers? I have some doubts, but hey I would not be unhappy if my AQM would stay idle most of the time, because lower layers avoid triggering it.


>
>Bob
>
>On Mon, Oct 17, 2022 at 7:58 PM David Lang via Make-wifi-fast <
>make-wifi-fast@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 <cheshire@apple.com>
>> wrote:
>> >>
>> >> On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast <
>> make-wifi-fast@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-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.