Hi Bob, On 18 October 2022 19:03:21 CEST, Bob McMahon via Rpm <r...@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-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 <chesh...@apple.com> >> 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 > -- 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