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

Wed Oct 12 13:39:32 EDT 2022

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 tape out <https://anysilicon.com/tapeout/> 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.

Bob

PS. As a side note, data center switch architecture addressed latency &
bloat with things like AFD & DPP
<https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-738488.html>
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.

The needed buffer size is the bandwidth delay product value divided by the
square root of the number of flows:

[image: white-paper-c11-738488_16.jpg]
<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>

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

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.
Figure 11.    Buffer Sizing for Different Link Speeds and Numbers of Flows
[image: image.png]

On Tue, Oct 11, 2022 at 3:24 PM Dave Taht <dave.taht at gmail.com> wrote:

> Well, we've all been yammering for many years, and the message is
> getting through. Yes, at this point, changing the message to be more
> directed at engineers than users would help, and to this day, I don't
> know how to get to anyone in the
> C suite, except through the complaints of their kids. Jim got on this
> problem because of his kids. The guy that did dslreports, also. "my"
> kids are
>
> At the risk of burying the lede, our very own dave reed just did a
> podcast on different stuff:
> https://twit.tv/shows/floss-weekly/episodes/701?autostart=false
>
> Sometimes my own (shared with most of you) motivations tend to leak
> through. I really encourage the independent growth of user created and
> owned software, running on their own routers, and I'm very pleased to
> see the level of activity on the openwrt forums showing how healthy
> that part of our culture is. It would be a very different world if
> we'd decided to settle for whatever an ISP was willing to give us, and
> for things as they were, and I'm probably difficult to employ because
> of my
> fervent beliefs in anti-patenting, free and open source, and the right
> to repair...
>
> ... but I wouldn't have my world any other way. I might die broke, but
> I'll die free.
>
> On Tue, Oct 11, 2022 at 11:44 AM Rich Brown via Rpm
> <rpm at lists.bufferbloat.net> wrote:
> >
> >
> >
> >
> > On Oct 11, 2022, at 1:05 PM, Bob McMahon <bob.mcmahon at broadcom.com>
> wrote:
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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?
> >
> > There are two fronts to attack:
> >
> > - Manufacturers - This video is a start on getting their customers to
> use these responsiveness test tools and call the support lines.
> >
> > - 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...)
> >
> > Rich
> >
> >
> > Bob
> >
> > On Tue, Oct 11, 2022 at 6:57 AM Rich Brown <richb.hanover at gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm <
> rpm at lists.bufferbloat.net> wrote:
> >>
> >> > I think conflating bufferbloat with latency misses the subtle point
> in that
> >> > bufferbloat is a measurement in memory units more than a measurement
> in
> >> > time units.
> >>
> >>
> >> 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.
> >>
> >> 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).
> >>
> >> I am delighted that there's an engaging, mass-market Youtube video that
> makes the case that bufferbloat even exists.
> >>
> >> Rich
> >
> >
> > 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.
> >
> >
> > _______________________________________________
> > Rpm mailing list
> > Rpm at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/rpm
>
>
>
> --
> This song goes out to all the folk that thought Stadia would work:
>
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> Dave Täht CEO, TekLibre, LLC
>

-- 
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/cake/attachments/20221012/4e173f3a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 68900 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20221012/4e173f3a/attachment-0001.png>