<div dir="ltr">With full respect to open source projects like OpenWRT, I think from an energy, performance & going forward perspective the AP forwarding plane will be realized by "transistor engineers." This makes the awareness around bloat by network engineers needed even more because those design cycles take awhile. A <a href="https://anysilicon.com/tapeout/">tape out</a> is very different from a sw compile. The driving force for ASIC & CMOS radio features typically will come from IAPs or enterprise customers, mostly per revenues adds to their businesses. Customer complaints are years down the road from such design decisions so bloat mitigation or elimination needs to be designed in from the get-go.<br><br>Bob<br><br>PS. As a side note, data center switch architecture addressed latency & bloat with <a href="https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html">things like AFD & DPP</a> as described per a Cisco Nexus 9000. Notice their formula for queue size can be defined by a math calculation. A challenge with WiFi is that the phy rates are dynamic and have a large range so such tables aren't so straightforward and C cannot be so simply defined. In many ways the data center architects had an easier problem than we in the shared RF, battery powered, no waveguides, etc. have.<br><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><p class="gmail-pCMTBody" style="margin:1px 0em 0.5em;padding:0px;border:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:inherit;font-size:14px;line-height:1.25;font-family:CiscoSans,Arial,sans-serif;vertical-align:baseline;color:rgb(82,82,82);text-align:justify;overflow:visible;break-before:page"><span style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:9pt;line-height:inherit;font-family:Arial,"sans-serif";vertical-align:baseline;overflow:visible">The needed buffer size is the bandwidth delay product value divided by the square root of the number of flows:</span></p></div><div><p class="gmail-pBody" style="margin:5pt 0em 0.5em;padding:0px;border:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:inherit;font-size:14px;line-height:1.25;font-family:CiscoSans,Arial,sans-serif;vertical-align:baseline;color:rgb(82,82,82);overflow:visible"><a href="https://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.docx/_jcr_content/renditions/white-paper-c11-738488_16.jpg" class="gmail-show-image-alone" title="white-paper-c11-738488_16.jpg" style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline;color:rgb(0,80,115);overflow:visible;word-break:break-word"><img border="0" width="192" height="40" id="gmail-Picture 46" src="https://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.docx/_jcr_content/renditions/white-paper-c11-738488_16.jpg" alt="white-paper-c11-738488_16.jpg" style="margin: 0px; padding: 0px; border: 0px; font-style: inherit; font-variant: inherit; font-weight: inherit; font-stretch: inherit; line-height: inherit; vertical-align: baseline; overflow: visible; max-width: 98%;"></a></p></div><div><p class="gmail-pBody" style="margin:1px 0em 0.5em;padding:0px;border:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:inherit;font-size:14px;line-height:1.25;font-family:CiscoSans,Arial,sans-serif;vertical-align:baseline;color:rgb(82,82,82);overflow:visible">Here, C is the link bandwidth, RTT is round-trip time, and N is the number of long-lived flows (see reference 6 at the end of this document).</p></div><div><p class="gmail-pBody" style="margin:1px 0em 0.5em;padding:0px;border:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:inherit;font-size:14px;line-height:1.25;font-family:CiscoSans,Arial,sans-serif;vertical-align:baseline;color:rgb(82,82,82);overflow:visible">Using an average RTT of 100 microseconds in a data center network, Figure 11 shows the buffer size for different link speeds and various numbers of flows. Note that the buffer size decreases rapidly as the number of flows increases. For instance, on a 100-Gbps link with 2500 flows, only a 25-KB buffer is needed.</p><div class="gmail-pDefault" style="margin:12pt 0pt 6pt 0px;padding:1px 0px 0px;border:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:inherit;font-size:14px;line-height:inherit;font-family:CiscoSans,Arial,sans-serif;vertical-align:baseline;overflow:visible;color:rgb(82,82,82)"><span style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:700;font-stretch:inherit;line-height:inherit;vertical-align:baseline;overflow:visible">Figure 11.  <span style="margin:0px;padding:0px;border:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times New Roman";vertical-align:baseline;overflow:visible">  </span></span>Buffer Sizing for Different Link Speeds and Numbers of Flows</div><img src="cid:ii_l95wqjui1" alt="image.png" width="336" height="184"><p class="gmail-pBody" style="margin:1px 0em 0.5em;padding:0px;border:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:inherit;font-size:14px;line-height:1.25;font-family:CiscoSans,Arial,sans-serif;vertical-align:baseline;color:rgb(82,82,82);overflow:visible"><br></p></div></blockquote></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 11, 2022 at 3:24 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</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">Well, we've all been yammering for many years, and the message is<br>
getting through. Yes, at this point, changing the message to be more<br>
directed at engineers than users would help, and to this day, I don't<br>
know how to get to anyone in the<br>
C suite, except through the complaints of their kids. Jim got on this<br>
problem because of his kids. The guy that did dslreports, also. "my"<br>
kids are<br>
<br>
At the risk of burying the lede, our very own dave reed just did a<br>
podcast on different stuff:<br>
<a href="https://twit.tv/shows/floss-weekly/episodes/701?autostart=false" rel="noreferrer" target="_blank">https://twit.tv/shows/floss-weekly/episodes/701?autostart=false</a><br>
<br>
Sometimes my own (shared with most of you) motivations tend to leak<br>
through. I really encourage the independent growth of user created and<br>
owned software, running on their own routers, and I'm very pleased to<br>
see the level of activity on the openwrt forums showing how healthy<br>
that part of our culture is. It would be a very different world if<br>
we'd decided to settle for whatever an ISP was willing to give us, and<br>
for things as they were, and I'm probably difficult to employ because<br>
of my<br>
fervent beliefs in anti-patenting, free and open source, and the right<br>
to repair...<br>
<br>
... but I wouldn't have my world any other way. I might die broke, but<br>
I'll die free.<br>
<br>
On Tue, Oct 11, 2022 at 11:44 AM Rich Brown via Rpm<br>
<<a href="mailto:rpm@lists.bufferbloat.net" target="_blank">rpm@lists.bufferbloat.net</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Oct 11, 2022, at 1:05 PM, Bob McMahon <<a href="mailto:bob.mcmahon@broadcom.com" target="_blank">bob.mcmahon@broadcom.com</a>> wrote:<br>
><br>
> I agree that bufferbloat awareness is a good thing. The issue I have is the approach - ask consumers to "detect it" and replace a device with a new one, that may or may not, meet all the needs of the users.<br>
><br>
><br>
> Better is that network engineers "design bloat out" from the beginning starting by properly sizing queues to service jitter, and for WiFi, to also enable aggregation techniques that minimize TXOP consumption.<br>
><br>
><br>
> The Yes, but... part of my answer emphasizes awareness. How are the network engineers going to know it's worth the (minor) effort of creating properly-sized queues?<br>
><br>
> There are two fronts to attack:<br>
><br>
> - Manufacturers - This video is a start on getting their customers to use these responsiveness test tools and call the support lines.<br>
><br>
> - Hardware (especially router) reviewers - It kills me that there is radio silence whenever I ask a reviewer if they have ever measured latency/responsiveness.  (BTW: Has anyone heard from Ben Moskowitz from Consumer Reports? We had a very encouraging phone call about a year ago, and they were going to get back to us...)<br>
><br>
> Rich<br>
><br>
><br>
> Bob<br>
><br>
> On Tue, Oct 11, 2022 at 6:57 AM Rich Brown <<a href="mailto:richb.hanover@gmail.com" target="_blank">richb.hanover@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank">rpm@lists.bufferbloat.net</a>> wrote:<br>
>><br>
>> > I think conflating bufferbloat with latency misses the subtle point in that<br>
>> > bufferbloat is a measurement in memory units more than a measurement in<br>
>> > time units.<br>
>><br>
>><br>
>> Yes, but... I am going to praise this video, even as I encourage all the techies to be sure that they have the units correct.<br>
>><br>
>> I've been yammering about the evils of latency/excess queueing for 10 years on my blog, in forums, etc. I have not achieved anywhere near the notoriety of this video (almost a third of a million views).<br>
>><br>
>> I am delighted that there's an engaging, mass-market Youtube video that makes the case that bufferbloat even exists.<br>
>><br>
>> Rich<br>
><br>
><br>
> 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.<br>
><br>
><br>
> _______________________________________________<br>
> Rpm mailing list<br>
> <a href="mailto:Rpm@lists.bufferbloat.net" target="_blank">Rpm@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/rpm" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/rpm</a><br>
<br>
<br>
<br>
-- <br>
This song goes out to all the folk that thought Stadia would work:<br>
<a href="https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz" rel="noreferrer" target="_blank">https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz</a><br>
Dave Täht CEO, TekLibre, LLC<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>