<div dir="ltr"><i>[SM] How does that generalize to internet access links? My gut feeling is that an FQ scheduler comes close.</i><br><div><br></div><div>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.<br><br>I do think we can define generalized tests - though that's a digression (and I'm biased too being a test & measurement engineer.)<br><br><i>[SM] I guess often things are obvious only retrospectively, but how could one design a switch differently?</i><br><br>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 ;)<br><br><i>[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><br><br>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)<br><br><i>[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.</i><br><br>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.<br><br>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. <br><br>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.<br><br>Bob<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 18, 2022 at 11:20 AM Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Bob,<br>
<br>
On 18 October 2022 19:03:21 CEST, Bob McMahon via Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank">rpm@lists.bufferbloat.net</a>> wrote:<br>
>I agree with Stuart that there is no reason for shared lines in the first<br>
>place. It seems like a design flaw to have a common queue that congests in<br>
>a way that impacts the one transmit unit as the atomic forwarding plane<br>
>unit. <br>
<br>
[SM] How does that generalize to internet access links? My gut feeling is that an FQ scheduler comes close.<br>
<br>
<br>
 The goal of virtual output queueing<br>
><<a href="https://en.wikipedia.org/wiki/Virtual_output_queueing" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Virtual_output_queueing</a>> is to eliminate<br>
>head of line blocking, every egress transmit unit gets its own cashier with<br>
>no competition.  The VOQ queue depths should support one transmit unit and<br>
>any jitter through the switching subsystem - jitter for the case of<br>
>non-bloat and where a faster VOQ service rate can drain the VOQ.  If the<br>
>VOQ can't be drained per a faster service rate, then it's just one<br>
>transmit unit as the queue is now just a standing queue w/delay and no<br>
>benefit.<br>
<br>
[SM] I guess often things are obvious only retrospectively, but how could one design a switch differently?<br>
<br>
<br>
><br>
>Many network engineers typically, though incorrectly, perceive a transmit<br>
>unit as one ethernet packet. With WiFi it's one Mu transmission or one Su<br>
>transmission, with aggregation(s), which is a lot more than one ethernet<br>
>packet but it depends on things like MCS, spatial stream powers, Mu peers,<br>
>etc. and is variable. Some data center designs have optimized the<br>
>forwarding plane for flow completion times so their equivalent transmit<br>
>unit is a mouse flow.<br>
<br>
[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)?<br>
<br>
><br>
>I perceive applying AQM to shared queue congestion as a mitigation<br>
>technique to a poorly designed forwarding plane. The hope is that<br>
>transistor engineers don't do this and "design out the lines" from the<br>
>beginning. Better switching engineering vs queue management applied<br>
>afterwards as a mitigation technique.<br>
<br>
[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.<br>
<br>
<br>
><br>
>Bob<br>
><br>
>On Mon, Oct 17, 2022 at 7:58 PM David Lang via Make-wifi-fast <<br>
><a href="mailto:make-wifi-fast@lists.bufferbloat.net" target="_blank">make-wifi-fast@lists.bufferbloat.net</a>> wrote:<br>
><br>
>> On Mon, 17 Oct 2022, Dave Taht via Bloat wrote:<br>
>><br>
>> > On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire <<a href="mailto:cheshire@apple.com" target="_blank">cheshire@apple.com</a>><br>
>> wrote:<br>
>> >><br>
>> >> On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast <<br>
>> <a href="mailto:make-wifi-fast@lists.bufferbloat.net" target="_blank">make-wifi-fast@lists.bufferbloat.net</a>> wrote:<br>
>> >><br>
>> >> > This was so massively well done, I cried. Does anyone know how to get<br>
>> in touch with the ifxit folk?<br>
>> >> ><br>
>> >> > <a href="https://www.youtube.com/watch?v=UICh3ScfNWI" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=UICh3ScfNWI</a><br>
>> >><br>
>> >> I’m surprised that you liked this video. It seems to me that it repeats<br>
>> all the standard misinformation. The analogy they use is the standard<br>
>> terrible example of waiting in a long line at a grocery store, and the<br>
>> “solution” is letting certain traffic “jump the line, angering everyone<br>
>> behind them”.<br>
>> ><br>
>> > Accuracy be damned. The analogy to common experience resonates more.<br>
>><br>
>> actually, fair queueing is more like the '15 items or less' lanes to speed<br>
>> through the people doing simple things rather than having them wait behind<br>
>> the<br>
>> mother of 7 doing their monthly shopping.<br>
>><br>
>> David Lang_______________________________________________<br>
>> Make-wifi-fast mailing list<br>
>> <a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">Make-wifi-fast@lists.bufferbloat.net</a><br>
>> <a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
><br>
<br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.<br>
</blockquote></div>

<br>
<span style="background-color:rgb(255,255,255)"><font size="2">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.</font></span>