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

[Livingood, Jason via Bloat]

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

Maybe – like ‘security by design’ and ‘privacy by design’ – we need ‘low 
latency by design’ for network engineers! ;-)

JL

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon via Bloat]

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

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]


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  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
>  wrote:
> >
> >
> >
> >
> > On Oct 11, 2022, at 1:05 PM, Bob McMahon 
> 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 
> wrote:
> >>
> >>
> >>
> >> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm <
> r...@lists.bufferbloat.net> wrote:
> >>
> >> > I think 

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

[Dave Taht via Bloat]

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
 wrote:
>
>
>
>
> On Oct 11, 2022, at 1:05 PM, Bob McMahon  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  wrote:
>>
>>
>>
>> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm 
>>  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
> r...@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-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Rich Brown via Bloat]

> On Oct 11, 2022, at 1:05 PM, Bob McMahon  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  > wrote:
> 
> 
>> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm > > 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.

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Bob McMahon via Bloat]

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.

Bob

On Tue, Oct 11, 2022 at 6:57 AM Rich Brown  wrote:

>
>
> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm <
> r...@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.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Dave Taht via Bloat]

On Tue, Oct 11, 2022 at 9:58 AM Bob McMahon via Rpm
 wrote:
>
> > Saturate a link in both directions simultaneously with multiple greedy 
> > flows while measuring load-dependent latency changes for small isochronous 
> > probe flows.
>
> This functionality is released in iperf 2.1.8 per the bounceback feature but, 
> unfortunately, OpenWRT doesn't maintain iperf 2 as a package anymore and uses 
> 2.0.13

iperf 2.1.8 was pushed into the openwrt mainline and may appear as of
22.03.1. I'll check.

>
> CLIENT SPECIFIC OPTIONS
>
> --bounceback[=n]run a TCP bounceback or rps test with optional number writes 
> in a burst per value of n. The default is ten writes every period and the 
> default period is one second (Note: set size with -l or --len which defaults 
> to 100 bytes)--bounceback-congest[=up|down|bidir][,n]request a concurrent 
> working load or TCP stream(s), defaults to full duplex (or bidir) unless the 
> up or down option is provided. The number of TCP streams defaults to 1 and 
> can be changed via the n value, e.g. --bounceback-congest=down,4 will use 
> four TCP streams from server to the client as the working load. The IP ToS 
> will be BE (0x0) for working load traffic.--bounceback-hold nrequest the 
> server to insert a delay of n milliseconds between its read and write 
> (default is no delay)--bounceback-period[=n]request the client schedule its 
> send(s) every n seconds (default is one second, use zero value for immediate 
> or continuous back to back)--bounceback-no-quickackrequest the server not set 
> the TCP_QUICKACK socket option (disabling TCP ACK delays) during a bounceback 
> test (see NOTES)--bounceback-txdelay nrequest the client to delay n seconds 
> between the start of the working load and the bounceback traffic (default is 
> no delay)
>
> On Tue, Oct 11, 2022 at 12:15 AM Sebastian Moeller  wrote:
>>
>> Hi Bob,
>>
>> On 11 October 2022 02:05:40 CEST, Bob McMahon  
>> wrote:
>> >It's too big because it's oversized so it's in the size domain. It's
>> >basically Little's law's value for the number of items in a queue.
>> >
>> >*Number of items in the system = (the rate items enter and leave the
>> >system) x (the average amount of time items spend in the system)*
>> >
>> >
>> >Which gets driven to the standing queue size when the arrival rate
>> >exceeds the service rate - so the driving factor isn't the service and
>> >arrival rates, but *the queue size *when *any service rate is less than an
>> >arrival rate.*
>>
>> [SM] You could also argue it is the ratio of arrival to service rates, with 
>> the queue size being a measure correlating with how long the system will 
>> tolerate ratios larger than one...
>>
>>
>> >
>> >In other words, one can find and measure bloat regardless of the
>> >enter/leave rates (as long as the leave rate is too slow) and the value of
>> >memory units found will always be the same.
>> >
>> >Things like prioritizations to jump the line are somewhat of hacks at
>> >reducing the service time for a specialized class of packets but nobody
>> >really knows which packets should jump.
>>
>> [SM] Au contraire most everybody 'knows' it is their packets that should 
>> jump ahead of the rest ;) For intermediate hop queues however that endpoint 
>> perception is not really actionable due to lack of robust and reliable 
>> importance identifiers on packets. In side a 'domain' dscps might work if 
>> treated to strict admission control, but that typically will not help 
>> end2end traffic over the internet. This is BTW why I think FQ is a great 
>> concept, as it mostly results in the desirable outcome of not picking 
>> winners and losers (like arbitrarily starving a flow), but I digress.
>>
>> >Also, nobody can define what
>> >working conditions are so that's another problem with this class of tests.
>>
>> [SM] While real working conditions will be different for each link and 
>> probably vary over time, it seems achievable to come up with a set of 
>> pessimistic assumptions how to model a challenging work condition against 
>> which to test potential remedies, assuming that such remedies will also work 
>> well under less challenging conditions, no?
>>
>>
>> >
>> >Better maybe just to shrink the queue and eliminate all unneeded queueing
>> >delays.
>>
>> [SM] The 'unneeded' does a lot of work in that sentence ;). I like Van's? 
>> Description of queues as shock absorbers so queue size will have a lower 
>> acceptable limit assuming users want to achieve 'acceptable' throughput even 
>> with existing bursty senders. (Not all applications are suited for pacing so 
>> some level of burstiness seems unavoidable).
>>
>>
>> > Also, measure the performance per "user conditions" which is going
>> >to be different for almost every environment (and is correlated to time and
>> >space.) So any engineering solution is fundamentally suboptimal.
>>
>> [SM] A matter of definition, if the requirement is to cover many user 
>> conditions the optimality measure simply needs to

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

[Rich Brown via Bloat]

> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm  
> 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___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat