Re: [NNagain] A quick report from the WISPA conference

Re: [NNagain] A quick report from the WISPA conference

[Dave Taht]

Dear Sina:

I cannot help but wonder if t-mobile had got on top of the waveform
test issues you were identifying for them back in oct 18th, 2022 yet?

On Tue, Oct 18, 2022 at 1:17 PM Sina Khanifar <sina@waveform.com> wrote:
>
> I can't help but wonder tho... are you collecting any statistics, over time, as to how much better the problem is getting?
>
>
> We are collecting anonymized data, but we haven't analyzed it yet. If we get a bit of time we'll look at that hopefully.
>
> And any chance they could do something similar explaining wifi?
>
>
> I'm actually not exactly sure what mitigations exist for WiFi at the moment - is there something I can read?
>
> On this note: when we were building our test one of the things we really wished existed was a standardized way to test latency and throughput to routers. It would be super helpful if there was a standard in consumer routers that allowed users to both ping and fetch 0kB fils from their routers, and also run download/upload tests.
>
> I think one more wispa conference will be a clean sweep of everyone in the fixed wireless market to not only adopt these algorithms for plan enforcement, but even more directly on the radios and more CPE.
>
>
> T-Mobile has signed up 1m+ people to their new Home Internet over 5G, and all of them have really meaningful bufferbloat issues. I've been pointing folks who reach out to this thread about cake-autorate and sqm-autorate, but ideally it would be fixed at a network level, just not sure how to apply pressure (I'm in contact with the T-Mobile Home Internet team, but I think this is above their heads).
>
>
> On Mon, Oct 17, 2022 at 8:15 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Mon, Oct 17, 2022 at 7:51 PM Sina Khanifar <sina@waveform.com> wrote:
>>
>> Positive or negative, I can claim a bit of credit for this video :). We've been working with LTT on a few projects and we pitched them on doing something around bufferbloat. We've seen more traffic to our Waveforn test than ever before, which has been fun!
>>
>> Thank you. Great job with that video! And waveform has become the goto site for many now.
>>
>> I can't help but wonder tho... are you collecting any statistics, over time, as to how much better the problem is getting?
>>
>> And any chance they could do something similar explaining wifi?
>>
>> ...
>>
>> I was just at WISPA conference week before last. Preseem's booth
>> (fq_codel) was always packed. Vilo living had put cake in their wifi 6 product. A
>> keynote speaker had deployed it and talked about it with waveform results on the big screen (2k people there). A large wireless vendor demo'd privately to me their flent results before/after cake on their next-gen radios... and people dissed tarana without me prompting for their bad bufferbloat... and the best thing of all that happened to me was... besides getting a hug from a young lady (megan) who'd salvaged her schooling in alaska using sqm - I walked up to the paraqum booth
>> (another large QoE middlebox maker centered more in india) and asked.
>>
>> "So... do y'all have fq_codel yet?"
>>
>> And they smiled and said: "No, we have something better... we've got cake."
>>
>> "Cake? What's that?" - I said, innocently.
>>
>> They then stepped me through their 200Gbps (!!) product, which uses a bunch of offloads, and can track rtt down to a ms with the intel ethernet card they were using. They'd modifed cake to provide 16 (?) levels of service, and were running under dpdk (I am not sure if cake was). It was a great, convincing pitch...
>>
>> ... then I told 'em who I was. There's a video of the in-both concert after.
>>
>> ...
>>
>> The downside to me (and the subject of my talk) was that in nearly every person I talked to, fq_codel was viewed as a means to better subscriber bandwidth plan enforcement (which is admittedly the market that preseem pioneered) and it was not understood that I'd got involved in this whole thing because I'd wanted an algorithm to deal with "rain fade", running directly on the radios. People wanted to use the statistics on the radios to drive the plan enforcement better
>> (which is an ok approach, I guess), and for 10+ I'd been whinging about the... physics.
>>
>> So I ranted about rfc7567 a lot and begged people now putting routerOS
>> 7.2 and later out there (mikrotik is huge in this market), to kill their fifos and sfqs at the native rates of the interfaces... and watch their network improve that way also.
>>
>> I think one more wispa conference will be a clean sweep of everyone in the fixed wireless market to not only adopt these algorithms for plan enforcement, but even more directly on the radios and more CPE.
>>
>> I also picked up enough consulting business to keep me busy the rest of this year, and possibly more than I can handle (anybody looking?)
>>
>> I wonder what will happen at a fiber conference?
>>
>> On Mon, Oct 17, 2022 at 7:45 PM Dave Taht via Bloat <bloat@lists.bufferbloat.net> wrote:
>>
>> On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire <cheshire@apple.com> wrote:
>>
>> On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast <make-wifi-fast@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.
>>
>> Some quotes from the video:
>>
>> it would be so much more efficient for them to let you skip the line and just check out, especially since you’re in a hurry, but they’re rudely refusing
>>
>> I think the person with the cheetos pulling out a gun and shooting everyone in front of him (AQM) would not go down well.
>>
>> to go back to our grocery store analogy this would be like if a worker saw you standing at the back ... and either let you skip to the front of the line or opens up an express lane just for you
>>
>> Actually that analogy is fairly close to fair queuing. The multiple checker analogy is one of the most common analogies in queue theory itself.
>>
>> The video describes the problem of bufferbloat, and then describes the same failed solution that hasn’t worked for the last three decades.
>>
>> Hmm? It establishes the scenario, explains the problem *quickly*, disses gamer routers for not getting it right.. *points to an accurate test*, and then to the ideas and products that *actually work* with "smart queueing", with a screenshot of the most common
>> (eero's optimize for gaming and videoconferencing), and fq_codel and cake *by name*, and points folk at the best known solution available, openwrt.
>>
>> Bing, baddabang, boom. Also the comments were revealing. A goodly percentage already knew the problem, more than a few were inspired to take the test,
>> there was a whole bunch of "Aha!" success stories and 360k views, which is more people than we've ever been able to reach in for example, a nanog conference.
>>
>> I loved that folk taking the test actually had quite a few A results, without having had to do anything. At least some ISPs are getting it more right now!
>>
>> At this point I think gamers in particular know what "brands" we've tried to establish - "Smart queues", "SQM", "OpenWrt", fq_codel and now "cake" are "good" things to have, and are stimulating demand by asking for them, It's certainly working out better and better for evenroute, firewalla, ubnt and others, and I saw an uptick in questions about this on various user forums.
>>
>> I even like that there's a backlash now of people saying "fixing bufferbloat doesn't solve everything" -
>>
>> Describing the obvious simple-minded (wrong) solution that any normal person would think of based on their personal human experience waiting in grocery stores and airports, is not describing the solution to bufferbloat. The solution to bufferbloat is not that if you are privileged then you get to “skip to the front of the line”. The solution to bufferbloat is that there is no line!
>>
>> I like the idea of a guru floating above a grocery cart with a better string of explanations, explaining
>>
>> - "no, grasshopper, the solution to bufferbloat is no line... at all".
>>
>> With grocery stores and airports people’s arrivals are independent and not controlled. There is no way for a grocery store or airport to generate backpressure to tell people to wait at home when a queue begins to form. The key to solving bufferbloat is generating timely backpressure to prevent the queue forming in the first place, not accepting a huge queue and then deciding who deserves special treatment to get better service than all the other peons who still have to wait in a long queue, just like before.
>>
>> I am not huge on the word "backpressure" here. Needs to signal the other side to slow down, is more accurate. So might say timely signalling rather than timely backpressure?
>>
>> Other feedback I got was that the video was too smarmy (I agree), different audiences than gamers need different forms of outreach...
>>
>> but to me, winning the gamers has always been one of the most important things, as they make a lot of buying decisions, and they benefit the most for
>> fq and packet prioritization as we do today in gamer routers and in cake + qosify.
>>
>> maybe that gets in the way of more serious markets. Certainly I would like another video explaining what goes wrong with videoconferencing.
>>
>> Stuart Cheshire
>>
>> --
>> 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
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>> --
>> 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
>
>


-- 
:( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos

Re: [NNagain] A quick report from the WISPA conference

[Jack Haverty]

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]

On 11/17/23 11:27, Dave Taht via Nnagain wrote:
> one of the things we really wished existed was a standardized way to
> test latency and throughput to routers. It would be super helpful if
> there was a standard in consumer routers that allowed users to both ping
>   and fetch 0kB fils from their routers, and also run download/upload
> tests.

Back when I was involved in operating a network, we tried to track 
latency and throughput by standard ping and related tests.  We 
discovered that, in addition to the network conditions, the results were 
often dependent on the particular equipment and software involved at the 
time.   Some companies treated ping traffic (e.g., anything directed to 
the "echo" port) as low priority since it was obviously (to them) less 
important than any other traffic.   Others treated such traffic as high 
priority - it made their results in review articles look better.

In another case we discovered one brand of desktop computer was achieved 
much higher throughputs over the net than similar products from other 
manufacturers.  It took some serious technical investigation but we 
eventually discovered that the high throughput was achieved by violating 
the Ethernet specification.   The offending vendor didn't follow the 
rules about timing.  But their test results looked much better than the 
competition.

IMHO the root of the problem is that you can not assume much about what 
any software and hardware are doing.  There are lots of specs, 
standards, and mandates in RFCs or even governmental rules and 
regulations.  But lacking any kind of testing or certification, it's 
difficult to tell if those "standards" are actually being followed. If 
someone, technical organization or government regulator, declares or 
legislates some protocol, algorithm, or behavior to be a required 
"standard", it should be accompanied by mechanisms and processes for 
testing to verify that the standard is implemented correctly and is 
actually used, and certification so that purchasers are informed.

Jack Haverty

[-- Attachment #2: Type: text/html, Size: 2490 bytes --]

Re: [NNagain] A quick report from the WISPA conference

[Dick Roy]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

...

> 

> T-Mobile has signed up 1m+ people to their new Home Internet over 5G, and
all of them have really meaningful bufferbloat issues. I've been pointing
folks who reach out to this thread about cake-autorate and sqm-autorate, but
ideally it would be fixed at a network level, just not sure how to apply
pressure (I'm in contact with the T-Mobile Home Internet team, but I think
this is above their heads).

[RR] While there may indeed be a bufferbloat issue, it is also very possibly
a capacity problem.  T-mobile’s home internet offering is at 600MHz where
the maximum downlink speeds are around 17Mbps (aggregate) assuming that the
entire 35MHz of available spectrum is used and its about 10Mbps per user on
the uplink. It’s a little complicated because … . (This assumes QPSK
encoding and a coding rate around 0.7. You can double those capacity numbers
roughly for 16-QAM however the range will drop dramatically.) The point is
that when there are N users in a “sector” (beamforming can be used though I
am not sure whether T-mobile does or not), each user gets on average 17/N
Mbps downlink, and can compete for access to 10/N Mbps uplink.  If N is on
the order of 100, you can see that transmission rates are severely limited.
I have first hand experience of this.  When my download speeds come to a
screeching halt on my iPhome, e.g. when I am downloading an app from that
app store, all I have to do is look at the top of my screen, and EVERY TIME
it says … drum roll please … “Lucky you! You are now on our latest and
greatest 5G network!”  OK, it just indicates “5G”, but either way, I want to
throw this iPhone through some t_Mobile store window! :-):-)  

 

 


[-- Attachment #2: Type: text/html, Size: 3980 bytes --]

Re: [NNagain] A quick report from the WISPA conference

[rjmcmahon]

The WiFi Alliance does certification for WiFi products.

https://www.wi-fi.org/

They've adopted iperf 2 for latency tests.

Bob
> On 11/17/23 11:27, Dave Taht via Nnagain wrote:
> 
>> one of the things we really wished existed was a standardized way to
>> 
>> test latency and throughput to routers. It would be super helpful if
>> 
>> there was a standard in consumer routers that allowed users to both
>> ping
>> and fetch 0kB fils from their routers, and also run download/upload
>> 
>> tests.
> 
> Back when I was involved in operating a network, we tried to track
> latency and throughput by standard ping and related tests.  We
> discovered that, in addition to the network conditions, the results
> were often dependent on the particular equipment and software involved
> at the time.   Some companies treated ping traffic (e.g., anything
> directed to the "echo" port) as low priority since it was obviously
> (to them) less important than any other traffic.   Others treated such
> traffic as high priority - it made their results in review articles
> look better.
> 
> In another case we discovered one brand of desktop computer was
> achieved much higher throughputs over the net than similar products
> from other manufacturers.  It took some serious technical
> investigation but we eventually discovered that the high throughput
> was achieved by violating the Ethernet specification.   The offending
> vendor didn't follow the rules about timing.  But their test results
> looked much better than the competition.
> 
> IMHO the root of the problem is that you can not assume much about
> what any software and hardware are doing.  There are lots of specs,
> standards, and mandates in RFCs or even governmental rules and
> regulations.  But lacking any kind of testing or certification, it's
> difficult to tell if those "standards" are actually being followed.
> If someone, technical organization or government regulator, declares
> or legislates some protocol, algorithm, or behavior to be a required
> "standard", it should be accompanied by mechanisms and processes for
> testing to verify that the standard is implemented correctly and is
> actually used, and certification so that purchasers are informed.
> 
> Jack Haverty
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] A quick report from the WISPA conference

[Sina Khanifar]

[-- Attachment #1: Type: text/plain, Size: 14611 bytes --]

Not as far as Im aware, sadly.

*Sina Khanifar |* ** Waveform.com ( https://www.waveform.com/ ) | (949) 878 8202 | LinkedIn ( http://www.linkedin.com/in/sinakhanifar )

On Fri, Nov 17 2023 at 11:27 AM, Dave Taht < dave.taht@gmail.com > wrote:

> 
> 
> 
> Dear Sina:
> 
> 
> 
> I cannot help but wonder if t-mobile had got on top of the waveform test
> issues you were identifying for them back in oct 18th, 2022 yet?
> 
> 
> 
> On Tue, Oct 18, 2022 at 1:17 PM Sina Khanifar <sina@waveform.com> wrote:
> >
> 
> 
>> 
>> 
>> I can't help but wonder tho... are you collecting any statistics, over
>> time, as to how much better the problem is getting?
>> 
>> 
> 
> 
> 
> >
> >
> 
> 
>> 
>> 
>> We are collecting anonymized data, but we haven't analyzed it yet. If we
>> get a bit of time we'll look at that hopefully.
>> 
>> 
> 
> 
> 
> >
> 
> 
>> 
>> 
>> And any chance they could do something similar explaining wifi?
>> 
>> 
> 
> 
> 
> >
> >
> 
> 
>> 
>> 
>> I'm actually not exactly sure what mitigations exist for WiFi at the
>> moment - is there something I can read?
>> 
>> 
> 
> 
> 
> >
> 
> 
>> 
>> 
>> On this note: when we were building our test one of the things we really
>> wished existed was a standardized way to test latency and throughput to
>> routers. It would be super helpful if there was a standard in consumer
>> routers that allowed users to both ping and fetch 0kB fils from their
>> routers, and also run download/upload tests.
>> 
>> 
> 
> 
> 
> >
> 
> 
>> 
>> 
>> I think one more wispa conference will be a clean sweep of everyone in the
>> fixed wireless market to not only adopt these algorithms for plan
>> enforcement, but even more directly on the radios and more CPE.
>> 
>> 
> 
> 
> 
> >
> >
> 
> 
>> 
>> 
>> T-Mobile has signed up 1m+ people to their new Home Internet over 5G, and
>> all of them have really meaningful bufferbloat issues. I've been pointing
>> folks who reach out to this thread about cake-autorate and sqm-autorate,
>> but ideally it would be fixed at a network level, just not sure how to
>> apply pressure (I'm in contact with the T-Mobile Home Internet team, but I
>> think this is above their heads).
>> 
>> 
> 
> 
> 
> >
> >
> 
> 
>> 
>> 
>> On Mon, Oct 17, 2022 at 8:15 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> On Mon, Oct 17, 2022 at 7:51 PM Sina Khanifar <sina@waveform.com> wrote:
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Positive or negative, I can claim a bit of credit for this video :). We've
>>> been working with LTT on a few projects and we pitched them on doing
>>> something around bufferbloat. We've seen more traffic to our Waveforn test
>>> than ever before, which has been fun!
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Thank you. Great job with that video! And waveform has become the goto
>>> site for many now.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I can't help but wonder tho... are you collecting any statistics, over
>>> time, as to how much better the problem is getting?
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> And any chance they could do something similar explaining wifi?
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> ...
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I was just at WISPA conference week before last. Preseem's booth
>>> (fq_codel) was always packed. Vilo living had put cake in their wifi 6
>>> product. A keynote speaker had deployed it and talked about it with
>>> waveform results on the big screen (2k people there). A large wireless
>>> vendor demo'd privately to me their flent results before/after cake on
>>> their next-gen radios... and people dissed tarana without me prompting for
>>> their bad bufferbloat... and the best thing of all that happened to me
>>> was... besides getting a hug from a young lady (megan) who'd salvaged her
>>> schooling in alaska using sqm - I walked up to the paraqum booth
>>> (another large QoE middlebox maker centered more in india) and asked.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> "So... do y'all have fq_codel yet?"
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> And they smiled and said: "No, we have something better... we've got
>>> cake."
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> "Cake? What's that?" - I said, innocently.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> They then stepped me through their 200Gbps (!!) product, which uses a
>>> bunch of offloads, and can track rtt down to a ms with the intel ethernet
>>> card they were using. They'd modifed cake to provide 16 (?) levels of
>>> service, and were running under dpdk (I am not sure if cake was). It was a
>>> great, convincing pitch...
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> ... then I told 'em who I was. There's a video of the in-both concert
>>> after.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> ...
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> The downside to me (and the subject of my talk) was that in nearly every
>>> person I talked to, fq_codel was viewed as a means to better subscriber
>>> bandwidth plan enforcement (which is admittedly the market that preseem
>>> pioneered) and it was not understood that I'd got involved in this whole
>>> thing because I'd wanted an algorithm to deal with "rain fade", running
>>> directly on the radios. People wanted to use the statistics on the radios
>>> to drive the plan enforcement better
>>> (which is an ok approach, I guess), and for 10+ I'd been whinging about
>>> the... physics.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> So I ranted about rfc7567 a lot and begged people now putting routerOS
>>> 7.2 and later out there (mikrotik is huge in this market), to kill their
>>> fifos and sfqs at the native rates of the interfaces... and watch their
>>> network improve that way also.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I think one more wispa conference will be a clean sweep of everyone in the
>>> fixed wireless market to not only adopt these algorithms for plan
>>> enforcement, but even more directly on the radios and more CPE.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I also picked up enough consulting business to keep me busy the rest of
>>> this year, and possibly more than I can handle (anybody looking?)
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I wonder what will happen at a fiber conference?
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> On Mon, Oct 17, 2022 at 7:45 PM Dave Taht via Bloat
>>> <bloat@lists.bufferbloat.net> wrote:
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire <cheshire@apple.com>
>>> wrote:
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast
>>> <make-wifi-fast@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.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Some quotes from the video:
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> it would be so much more efficient for them to let you skip the line and
>>> just check out, especially since you’re in a hurry, but they’re rudely
>>> refusing
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I think the person with the cheetos pulling out a gun and shooting
>>> everyone in front of him (AQM) would not go down well.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> to go back to our grocery store analogy this would be like if a worker saw
>>> you standing at the back ... and either let you skip to the front of the
>>> line or opens up an express lane just for you
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Actually that analogy is fairly close to fair queuing. The multiple
>>> checker analogy is one of the most common analogies in queue theory
>>> itself.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> The video describes the problem of bufferbloat, and then describes the
>>> same failed solution that hasn’t worked for the last three decades.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Hmm? It establishes the scenario, explains the problem *quickly*, disses
>>> gamer routers for not getting it right.. *points to an accurate test*, and
>>> then to the ideas and products that *actually work* with "smart queueing",
>>> with a screenshot of the most common
>>> (eero's optimize for gaming and videoconferencing), and fq_codel and cake
>>> *by name*, and points folk at the best known solution available, openwrt.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Bing, baddabang, boom. Also the comments were revealing. A goodly
>>> percentage already knew the problem, more than a few were inspired to take
>>> the test, there was a whole bunch of "Aha!" success stories and 360k
>>> views, which is more people than we've ever been able to reach in for
>>> example, a nanog conference.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I loved that folk taking the test actually had quite a few A results,
>>> without having had to do anything. At least some ISPs are getting it more
>>> right now!
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> At this point I think gamers in particular know what "brands" we've tried
>>> to establish - "Smart queues", "SQM", "OpenWrt", fq_codel and now "cake"
>>> are "good" things to have, and are stimulating demand by asking for them,
>>> It's certainly working out better and better for evenroute, firewalla,
>>> ubnt and others, and I saw an uptick in questions about this on various
>>> user forums.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I even like that there's a backlash now of people saying "fixing
>>> bufferbloat doesn't solve everything" -
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Describing the obvious simple-minded (wrong) solution that any normal
>>> person would think of based on their personal human experience waiting in
>>> grocery stores and airports, is not describing the solution to
>>> bufferbloat. The solution to bufferbloat is not that if you are privileged
>>> then you get to “skip to the front of the line”. The solution to
>>> bufferbloat is that there is no line!
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I like the idea of a guru floating above a grocery cart with a better
>>> string of explanations, explaining
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> - "no, grasshopper, the solution to bufferbloat is no line... at all".
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> With grocery stores and airports people’s arrivals are independent and not
>>> controlled. There is no way for a grocery store or airport to generate
>>> backpressure to tell people to wait at home when a queue begins to form.
>>> The key to solving bufferbloat is generating timely backpressure to
>>> prevent the queue forming in the first place, not accepting a huge queue
>>> and then deciding who deserves special treatment to get better service
>>> than all the other peons who still have to wait in a long queue, just like
>>> before.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> I am not huge on the word "backpressure" here. Needs to signal the other
>>> side to slow down, is more accurate. So might say timely signalling rather
>>> than timely backpressure?
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Other feedback I got was that the video was too smarmy (I agree),
>>> different audiences than gamers need different forms of outreach...
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> but to me, winning the gamers has always been one of the most important
>>> things, as they make a lot of buying decisions, and they benefit the most
>>> for fq and packet prioritization as we do today in gamer routers and in
>>> cake + qosify.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> maybe that gets in the way of more serious markets. Certainly I would like
>>> another video explaining what goes wrong with videoconferencing.
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> Stuart Cheshire
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> --
>>> 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
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >>
> 
> 
>> 
>>> 
>>> 
>>> --
>>> 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
>>> 
>>> 
>> 
>> 
> 
> 
> 
> >
> >
> 
> 
> 
> --
> :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht
> CSO, LibreQos
> 
> 
>

[-- Attachment #2: Type: text/html, Size: 19253 bytes --]

Re: [NNagain] A quick report from the WISPA conference

[le berger des photons]

[-- Attachment #1: Type: text/plain, Size: 2511 bytes --]

but you can see if it's doing what you want it to and you can compare it to
other products in the same space.

On Fri, Nov 17, 2023 at 9:31 PM Jack Haverty via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> On 11/17/23 11:27, Dave Taht via Nnagain wrote:
>
> one of the things we really wished existed was a standardized way to
> test latency and throughput to routers. It would be super helpful if
> there was a standard in consumer routers that allowed users to both ping
>  and fetch 0kB fils from their routers, and also run download/upload
> tests.
>
>
> Back when I was involved in operating a network, we tried to track latency
> and throughput by standard ping and related tests.  We discovered that, in
> addition to the network conditions, the results were often dependent on the
> particular equipment and software involved at the time.   Some companies
> treated ping traffic (e.g., anything directed to the "echo" port) as low
> priority since it was obviously (to them) less important than any other
> traffic.   Others treated such traffic as high priority - it made their
> results in review articles look better.
>
> In another case we discovered one brand of desktop computer was achieved
> much higher throughputs over the net than similar products from other
> manufacturers.  It took some serious technical investigation but we
> eventually discovered that the high throughput was achieved by violating
> the Ethernet specification.   The offending vendor didn't follow the rules
> about timing.  But their test results looked much better than the
> competition.
>
> IMHO the root of the problem is that you can not assume much about what
> any software and hardware are doing.  There are lots of specs, standards,
> and mandates in RFCs or even governmental rules and regulations.  But
> lacking any kind of testing or certification, it's difficult to tell if
> those "standards" are actually being followed.  If someone, technical
> organization or government regulator, declares or legislates some protocol,
> algorithm, or behavior to be a required "standard", it should be
> accompanied by mechanisms and processes for testing to verify that the
> standard is implemented correctly and is actually used, and certification
> so that purchasers are informed.
>
> Jack Haverty
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #2: Type: text/html, Size: 3225 bytes --]

Re: [NNagain] A quick report from the WISPA conference

[Robert McMahon]

[-- Attachment #1: Type: text/plain, Size: 3456 bytes --]

A TCP 3WHS may be a better test. It's supported in iperf 2.

⁣A much faster tcp connect() is also a differentiator between wired OSP vs FWA. The TCP_FAST_OPEN (TFO) and the setup aspects of QUIC show that fast early state exchanges are being engineered in, what I consider, non ideal manners. These setup optimizations remind of the PSTN and circuit setups. It seems best the make them low cost and high speed.

Not testing tcp connect() in a robust manner seems a fundamental industry escape.

Bob

On Nov 19, 2023, 3:04 AM, at 3:04 AM, le berger des photons via Nnagain <nnagain@lists.bufferbloat.net> wrote:
>but you can see if it's doing what you want it to and you can compare
>it to
>other products in the same space.
>
>On Fri, Nov 17, 2023 at 9:31 PM Jack Haverty via Nnagain <
>nnagain@lists.bufferbloat.net> wrote:
>
>> On 11/17/23 11:27, Dave Taht via Nnagain wrote:
>>
>> one of the things we really wished existed was a standardized way to
>> test latency and throughput to routers. It would be super helpful if
>> there was a standard in consumer routers that allowed users to both
>ping
>>  and fetch 0kB fils from their routers, and also run download/upload
>> tests.
>>
>>
>> Back when I was involved in operating a network, we tried to track
>latency
>> and throughput by standard ping and related tests.  We discovered
>that, in
>> addition to the network conditions, the results were often dependent
>on the
>> particular equipment and software involved at the time.   Some
>companies
>> treated ping traffic (e.g., anything directed to the "echo" port) as
>low
>> priority since it was obviously (to them) less important than any
>other
>> traffic.   Others treated such traffic as high priority - it made
>their
>> results in review articles look better.
>>
>> In another case we discovered one brand of desktop computer was
>achieved
>> much higher throughputs over the net than similar products from other
>> manufacturers.  It took some serious technical investigation but we
>> eventually discovered that the high throughput was achieved by
>violating
>> the Ethernet specification.   The offending vendor didn't follow the
>rules
>> about timing.  But their test results looked much better than the
>> competition.
>>
>> IMHO the root of the problem is that you can not assume much about
>what
>> any software and hardware are doing.  There are lots of specs,
>standards,
>> and mandates in RFCs or even governmental rules and regulations.  But
>> lacking any kind of testing or certification, it's difficult to tell
>if
>> those "standards" are actually being followed.  If someone, technical
>> organization or government regulator, declares or legislates some
>protocol,
>> algorithm, or behavior to be a required "standard", it should be
>> accompanied by mechanisms and processes for testing to verify that
>the
>> standard is implemented correctly and is actually used, and
>certification
>> so that purchasers are informed.
>>
>> Jack Haverty
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Nnagain mailing list
>Nnagain@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/nnagain

[-- Attachment #2: Type: text/html, Size: 4513 bytes --]