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

[Bob McMahon]

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

Probably not possible. Current fiber SFP 100Gs optics are the most
economic per the SERDES/Laser interface. Any other SFP is
suboptimal, probably for the next decade. Then there are still DSL internet
lines, satellite links, etc. And then WiFi which isn't really
internet access but first/last hop to the IAP last mile link. It seems way
too complicated to generalize a single solution. It's also a bit of an
engineering race and deployment race so the targets driven mostly by market
conditions and engineering project priorities are not fixed.

I do think we can define generalized tests - though that's a digression
(and I'm biased too being a test & measurement engineer.)

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

A suggestion is to look at merchant silicon used by the major integrators
that sell into data centers. But keep in mind the IAP forwarding plane is a
moving target so having some form of hardware programmability in field is
probably needed too. The COGs and volumes are very different too. I think
the market and time will provide the final answer (if there is one) and
then it will change again ;)

*[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)?*

TXOPs scarcity is driven by listen before talk (LBT.) This is needed for
collision avoidance. Unfortunately, WiFi networks w/o waveguides that share
the same carrier have to be separated in time in a distributed manner to
optimize the overall system. )Adding a scheduling carrier done by things
like mobile networks doesn't work well with small WiFi cells - though
802.11ax is a similar scheduling support mechanism)

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

Doubtful to me to achieve the ideal. Transports enhancements like BBRv2
seem worthwhile. And, yes, the "AQM hammer" to mitigate standing queue(s')
bloat is likely going to be needed as real engineering can't typically
achieve an ideal as some resources are shared and finite as you stated
elsewhere.

Many of the new responsiveness tests under loads are being designed to
create this potentially "artificial" condition, though many times it's real
too, so these tests are a good thing for awareness for sure. What these
tests don't do is monitor actual traffic conditions over time and space to
see how many times AQM had to be activated as well as measure how well
disaggregating the congested shared queue is working.

My opinion is that devices that support OpenWRT could be instrumented to
support network telemetry to provide actuals, at least for the WiFi hop.
There are multiple ways to do this. Some require new engineering efforts.
Others require distributed clock sync so tend to be in test labs only.

Bob

On Tue, Oct 18, 2022 at 11:20 AM Sebastian Moeller <moeller0 at gmx.de> wrote:

> Hi Bob,
>
> On 18 October 2022 19:03:21 CEST, Bob McMahon via Rpm <
> rpm at 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 at 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 at apple.com>
> >> wrote:
> >> >>
> >> >> On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast <
> >> make-wifi-fast at 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 at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20221018/cb277ef5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20221018/cb277ef5/attachment-0001.bin>