[Starlink] bloat on wifi8 and 802.11 wg

[Starlink] bloat on wifi8 and 802.11 wg

[Dave Taht]

I wish I had gone to the 802.11wg  more regularly than I did. I only
gave one bloat related presentation in 2014, shipped the
make-wifi-fast code in 2016(?), and never went back. IETF ate all my
money and time. I just assumed they were all in the slipstream of
linux and openwrt. :/

I did have a great meetup a few weeks back with the former 802.11
chair (dorothy stanley, hi!!!) who is trying to recruit people to
participate in the wifi8 standard and perhaps some finishing touches
on wifi7. She gave a great update on the status of things at the
recent wifinow conference, but as there is a cost to that, perhaps she
can share her slides with us?

https://wifinowglobal.com/product/wi-fi-world-congress-usa-2024-sarasota-florida-presentations-pdf/?mc_cid=beb1b4a2ed&mc_eid=327a64ba92

On Wed, May 8, 2024 at 8:28 AM Livingood, Jason via Bloat
<bloat@lists.bufferbloat.net> wrote:
>
> Dropping Starlink as Bloat is the right list. The IEEE 802.11 domain is certainly different than IP, so typical IP CCs don’t apply. In our L4S/NQB trials, we put LL-marked packets into the AC_VI WMM queue in the Wi-Fi network. IMO there is more work in 802.11 to focus on latency – so much focus right now is on throughput over everything else.
>
>
>
> From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of Rich Brown via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: Rich Brown <richb.hanover@gmail.com>
> Date: Wednesday, May 8, 2024 at 07:33
> To: David Fernández <davidfdzp@gmail.com>
> Cc: starlink <starlink@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>
> Subject: Re: [Starlink] [Bloat] L4S
>
>
>
> Let's split this thread and use this message to continue the discussion of L4S. Thanks
>
>
>
> On May 8, 2024, at 5:31 AM, David Fernández via Starlink <starlink@lists.bufferbloat.net> wrote:
>
>
>
> I see that L4S is not really solving everything (I read about issues with Wi-Fi), although it seems to be a step in the right direction, to be improved, let's hope.
>
>
>
> At least, Nokia is implementing it in its network gear (for mobile operators), so the bufferbloat problem is somehow acknowledged by industry, at least initially or partially.
>
>
>
> I have seen two consecutive RFCs to 9330:
>
> https://www.rfc-editor.org/info/rfc9331
>
> https://www.rfc-editor.org/info/rfc9332
>
>
>
> I suspect that optimal results require the bufferbloat to be addressed not only at network layer (IP), but also with some pipelining or cross-layering at link level (Ethernet, Wi-Fi or any other link technology, such as 5G, SATCOM, VHF...)
>
>
>
> Regards,
>
>
>
> David F.
>
>
>
> Date: Tue, 7 May 2024 08:46:03 -0400
>
> From: Dave Collier-Brown <dave.collier-Brown@indexexchange.com>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> It has an RFC at https://datatracker.ietf.org/doc/rfc9330/
>
> I read it as a way to rapidly find the available bandwidth without the TCP "sawtooth". The paper cites fc_codel and research based on it.
>
> I suspect My Smarter Colleagues know more (;-))
>
> --dave
>
>
>
> On 2024-05-07 08:13, David Fernández via Starlink wrote:
> Is L4S a solution to bufferbloat? I have read that gamers are happy with it.
>
> Sorry, I read it here, in Spanish:
> https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone
>
> Regards,
>
> David F.
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
Dave Täht CSO, LibreQos

Re: [Starlink] bloat on wifi8 and 802.11 wg

[Dorothy Stanley]

[-- Attachment #1.1: Type: text/plain, Size: 4690 bytes --]

Thank you Dave, happy to share my presentation slides, attached.

Best,

Dorothy

----------------------
Dorothy Stanley
Hewlett Packard Enterprise
dorothy.stanley@hpe.com <dstanley@arubanetworks.com>
dstanley1389@gmail.com
dstanley@ieee.org
+1 630-363-1389 <630-363-1389>


On Wed, May 8, 2024 at 8:35 AM Dave Taht <dave.taht@gmail.com> wrote:

> I wish I had gone to the 802.11wg  more regularly than I did. I only
> gave one bloat related presentation in 2014, shipped the
> make-wifi-fast code in 2016(?), and never went back. IETF ate all my
> money and time. I just assumed they were all in the slipstream of
> linux and openwrt. :/
>
> I did have a great meetup a few weeks back with the former 802.11
> chair (dorothy stanley, hi!!!) who is trying to recruit people to
> participate in the wifi8 standard and perhaps some finishing touches
> on wifi7. She gave a great update on the status of things at the
> recent wifinow conference, but as there is a cost to that, perhaps she
> can share her slides with us?
>
>
> https://wifinowglobal.com/product/wi-fi-world-congress-usa-2024-sarasota-florida-presentations-pdf/?mc_cid=beb1b4a2ed&mc_eid=327a64ba92
>
> On Wed, May 8, 2024 at 8:28 AM Livingood, Jason via Bloat
> <bloat@lists.bufferbloat.net> wrote:
> >
> > Dropping Starlink as Bloat is the right list. The IEEE 802.11 domain is
> certainly different than IP, so typical IP CCs don’t apply. In our L4S/NQB
> trials, we put LL-marked packets into the AC_VI WMM queue in the Wi-Fi
> network. IMO there is more work in 802.11 to focus on latency – so much
> focus right now is on throughput over everything else.
> >
> >
> >
> > From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of
> Rich Brown via Starlink <starlink@lists.bufferbloat.net>
> > Reply-To: Rich Brown <richb.hanover@gmail.com>
> > Date: Wednesday, May 8, 2024 at 07:33
> > To: David Fernández <davidfdzp@gmail.com>
> > Cc: starlink <starlink@lists.bufferbloat.net>, bloat <
> bloat@lists.bufferbloat.net>
> > Subject: Re: [Starlink] [Bloat] L4S
> >
> >
> >
> > Let's split this thread and use this message to continue the discussion
> of L4S. Thanks
> >
> >
> >
> > On May 8, 2024, at 5:31 AM, David Fernández via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> >
> >
> >
> > I see that L4S is not really solving everything (I read about issues
> with Wi-Fi), although it seems to be a step in the right direction, to be
> improved, let's hope.
> >
> >
> >
> > At least, Nokia is implementing it in its network gear (for mobile
> operators), so the bufferbloat problem is somehow acknowledged by industry,
> at least initially or partially.
> >
> >
> >
> > I have seen two consecutive RFCs to 9330:
> >
> > https://www.rfc-editor.org/info/rfc9331
> >
> > https://www.rfc-editor.org/info/rfc9332
> >
> >
> >
> > I suspect that optimal results require the bufferbloat to be addressed
> not only at network layer (IP), but also with some pipelining or
> cross-layering at link level (Ethernet, Wi-Fi or any other link technology,
> such as 5G, SATCOM, VHF...)
> >
> >
> >
> > Regards,
> >
> >
> >
> > David F.
> >
> >
> >
> > Date: Tue, 7 May 2024 08:46:03 -0400
> >
> > From: Dave Collier-Brown <dave.collier-Brown@indexexchange.com>
> > To: starlink@lists.bufferbloat.net
> > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> > Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com>
> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
> >
> > It has an RFC at https://datatracker.ietf.org/doc/rfc9330/
> >
> > I read it as a way to rapidly find the available bandwidth without the
> TCP "sawtooth". The paper cites fc_codel and research based on it.
> >
> > I suspect My Smarter Colleagues know more (;-))
> >
> > --dave
> >
> >
> >
> > On 2024-05-07 08:13, David Fernández via Starlink wrote:
> > Is L4S a solution to bufferbloat? I have read that gamers are happy with
> it.
> >
> > Sorry, I read it here, in Spanish:
> >
> https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone
> >
> > Regards,
> >
> > David F.
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> >
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos
>

[-- Attachment #1.2: Type: text/html, Size: 9672 bytes --]

[-- Attachment #2: 2024-04-23-Wi-Fi Now presentation-802-11 Standards.pdf --]
[-- Type: application/pdf, Size: 2155092 bytes --]

Re: [Starlink] bloat on wifi8 and 802.11 wg

[Dorothy Stanley]

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

To view the submissions that have been made to the
802.11 Working Group on the topic of L4S, please see
https://mentor.ieee.org/802.11/documents?is_dcn=l4s

All freely and publicly available.

Dorothy

----------------------
Dorothy Stanley
Hewlett Packard Enterprise
dorothy.stanley@hpe.com <dstanley@arubanetworks.com>
dstanley1389@gmail.com
dstanley@ieee.org
+1 630-363-1389 <630-363-1389>


On Wed, May 8, 2024 at 8:35 AM Dave Taht <dave.taht@gmail.com> wrote:

> I wish I had gone to the 802.11wg  more regularly than I did. I only
> gave one bloat related presentation in 2014, shipped the
> make-wifi-fast code in 2016(?), and never went back. IETF ate all my
> money and time. I just assumed they were all in the slipstream of
> linux and openwrt. :/
>
> I did have a great meetup a few weeks back with the former 802.11
> chair (dorothy stanley, hi!!!) who is trying to recruit people to
> participate in the wifi8 standard and perhaps some finishing touches
> on wifi7. She gave a great update on the status of things at the
> recent wifinow conference, but as there is a cost to that, perhaps she
> can share her slides with us?
>
>
> https://wifinowglobal.com/product/wi-fi-world-congress-usa-2024-sarasota-florida-presentations-pdf/?mc_cid=beb1b4a2ed&mc_eid=327a64ba92
>
> On Wed, May 8, 2024 at 8:28 AM Livingood, Jason via Bloat
> <bloat@lists.bufferbloat.net> wrote:
> >
> > Dropping Starlink as Bloat is the right list. The IEEE 802.11 domain is
> certainly different than IP, so typical IP CCs don’t apply. In our L4S/NQB
> trials, we put LL-marked packets into the AC_VI WMM queue in the Wi-Fi
> network. IMO there is more work in 802.11 to focus on latency – so much
> focus right now is on throughput over everything else.
> >
> >
> >
> > From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of
> Rich Brown via Starlink <starlink@lists.bufferbloat.net>
> > Reply-To: Rich Brown <richb.hanover@gmail.com>
> > Date: Wednesday, May 8, 2024 at 07:33
> > To: David Fernández <davidfdzp@gmail.com>
> > Cc: starlink <starlink@lists.bufferbloat.net>, bloat <
> bloat@lists.bufferbloat.net>
> > Subject: Re: [Starlink] [Bloat] L4S
> >
> >
> >
> > Let's split this thread and use this message to continue the discussion
> of L4S. Thanks
> >
> >
> >
> > On May 8, 2024, at 5:31 AM, David Fernández via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> >
> >
> >
> > I see that L4S is not really solving everything (I read about issues
> with Wi-Fi), although it seems to be a step in the right direction, to be
> improved, let's hope.
> >
> >
> >
> > At least, Nokia is implementing it in its network gear (for mobile
> operators), so the bufferbloat problem is somehow acknowledged by industry,
> at least initially or partially.
> >
> >
> >
> > I have seen two consecutive RFCs to 9330:
> >
> > https://www.rfc-editor.org/info/rfc9331
> >
> > https://www.rfc-editor.org/info/rfc9332
> >
> >
> >
> > I suspect that optimal results require the bufferbloat to be addressed
> not only at network layer (IP), but also with some pipelining or
> cross-layering at link level (Ethernet, Wi-Fi or any other link technology,
> such as 5G, SATCOM, VHF...)
> >
> >
> >
> > Regards,
> >
> >
> >
> > David F.
> >
> >
> >
> > Date: Tue, 7 May 2024 08:46:03 -0400
> >
> > From: Dave Collier-Brown <dave.collier-Brown@indexexchange.com>
> > To: starlink@lists.bufferbloat.net
> > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> > Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com>
> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
> >
> > It has an RFC at https://datatracker.ietf.org/doc/rfc9330/
> >
> > I read it as a way to rapidly find the available bandwidth without the
> TCP "sawtooth". The paper cites fc_codel and research based on it.
> >
> > I suspect My Smarter Colleagues know more (;-))
> >
> > --dave
> >
> >
> >
> > On 2024-05-07 08:13, David Fernández via Starlink wrote:
> > Is L4S a solution to bufferbloat? I have read that gamers are happy with
> it.
> >
> > Sorry, I read it here, in Spanish:
> >
> https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone
> >
> > Regards,
> >
> > David F.
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> >
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos
>

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

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 5899 bytes --]

There is a lot of confusion on the 802.11 latency technology options. I
think waiting for Wi-Fi 8 to solve this is a non starter. Solutions have to
work for 20B devices already in the field.

The silo'ing hasn't helped here. Those that cross the silos are needed by
my judgment. It means deep dives into 802.11 which now is a 25 year old set
of standards. Those with 25 years of 802.11 standards expertise are as rare
as hen's teeth and are worth their weight in gold.

Bob

On Wed, May 8, 2024 at 8:35 AM Dave Taht via Make-wifi-fast <
make-wifi-fast@lists.bufferbloat.net> wrote:

> I wish I had gone to the 802.11wg  more regularly than I did. I only
> gave one bloat related presentation in 2014, shipped the
> make-wifi-fast code in 2016(?), and never went back. IETF ate all my
> money and time. I just assumed they were all in the slipstream of
> linux and openwrt. :/
>
> I did have a great meetup a few weeks back with the former 802.11
> chair (dorothy stanley, hi!!!) who is trying to recruit people to
> participate in the wifi8 standard and perhaps some finishing touches
> on wifi7. She gave a great update on the status of things at the
> recent wifinow conference, but as there is a cost to that, perhaps she
> can share her slides with us?
>
>
> https://wifinowglobal.com/product/wi-fi-world-congress-usa-2024-sarasota-florida-presentations-pdf/?mc_cid=beb1b4a2ed&mc_eid=327a64ba92
>
> On Wed, May 8, 2024 at 8:28 AM Livingood, Jason via Bloat
> <bloat@lists.bufferbloat.net> wrote:
> >
> > Dropping Starlink as Bloat is the right list. The IEEE 802.11 domain is
> certainly different than IP, so typical IP CCs don’t apply. In our L4S/NQB
> trials, we put LL-marked packets into the AC_VI WMM queue in the Wi-Fi
> network. IMO there is more work in 802.11 to focus on latency – so much
> focus right now is on throughput over everything else.
> >
> >
> >
> > From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of
> Rich Brown via Starlink <starlink@lists.bufferbloat.net>
> > Reply-To: Rich Brown <richb.hanover@gmail.com>
> > Date: Wednesday, May 8, 2024 at 07:33
> > To: David Fernández <davidfdzp@gmail.com>
> > Cc: starlink <starlink@lists.bufferbloat.net>, bloat <
> bloat@lists.bufferbloat.net>
> > Subject: Re: [Starlink] [Bloat] L4S
> >
> >
> >
> > Let's split this thread and use this message to continue the discussion
> of L4S. Thanks
> >
> >
> >
> > On May 8, 2024, at 5:31 AM, David Fernández via Starlink <
> starlink@lists.bufferbloat.net> wrote:
> >
> >
> >
> > I see that L4S is not really solving everything (I read about issues
> with Wi-Fi), although it seems to be a step in the right direction, to be
> improved, let's hope.
> >
> >
> >
> > At least, Nokia is implementing it in its network gear (for mobile
> operators), so the bufferbloat problem is somehow acknowledged by industry,
> at least initially or partially.
> >
> >
> >
> > I have seen two consecutive RFCs to 9330:
> >
> > https://www.rfc-editor.org/info/rfc9331
> >
> > https://www.rfc-editor.org/info/rfc9332
> >
> >
> >
> > I suspect that optimal results require the bufferbloat to be addressed
> not only at network layer (IP), but also with some pipelining or
> cross-layering at link level (Ethernet, Wi-Fi or any other link technology,
> such as 5G, SATCOM, VHF...)
> >
> >
> >
> > Regards,
> >
> >
> >
> > David F.
> >
> >
> >
> > Date: Tue, 7 May 2024 08:46:03 -0400
> >
> > From: Dave Collier-Brown <dave.collier-Brown@indexexchange.com>
> > To: starlink@lists.bufferbloat.net
> > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> > Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com>
> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
> >
> > It has an RFC at https://datatracker.ietf.org/doc/rfc9330/
> >
> > I read it as a way to rapidly find the available bandwidth without the
> TCP "sawtooth". The paper cites fc_codel and research based on it.
> >
> > I suspect My Smarter Colleagues know more (;-))
> >
> > --dave
> >
> >
> >
> > On 2024-05-07 08:13, David Fernández via Starlink wrote:
> > Is L4S a solution to bufferbloat? I have read that gamers are happy with
> it.
> >
> > Sorry, I read it here, in Spanish:
> >
> https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone
> >
> > Regards,
> >
> > David F.
> >
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> >
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

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

[-- Attachment #1.2: Type: text/html, Size: 8762 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[David Lang]

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

It really doesn't help that everyone in the industry is pushing for higher 
bandwidth for a single host. That's a nice benchmark number, but not really 
relevant int he real world.

Even mu-mimo is of limited use as most routers only handle a handful of clients.

But the biggest problem is just the push to use wider channels and gain 
efficiency in long-running bulk transfers by bundling lots of IP packets into a 
single transmission. This works well when you don't have congestion and have a 
small number of clients. But when you have lots of clients, spanning many 
generations of wifi technology, you need to go to narrower channels, but more 
separate routers to maximize the fairness of available airtime.

David Lang

  On Sun, 1 Sep 2024, Bob McMahon via Starlink wrote:

> Date: Sun, 1 Sep 2024 18:15:11 -0700
> From: Bob McMahon via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: Bob McMahon <bob.mcmahon@broadcom.com>
> To: Dave Taht <dave.taht@gmail.com>
> Cc: David Fernández <davidfdzp@gmail.com>,
>     Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
>     Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
>     bloat <bloat@lists.bufferbloat.net>,
>     Dorothy Stanley <dstanley1389@gmail.com>
> Subject: Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg
> 
> There is a lot of confusion on the 802.11 latency technology options. I
> think waiting for Wi-Fi 8 to solve this is a non starter. Solutions have to
> work for 20B devices already in the field.
>
> The silo'ing hasn't helped here. Those that cross the silos are needed by
> my judgment. It means deep dives into 802.11 which now is a 25 year old set
> of standards. Those with 25 years of 802.11 standards expertise are as rare
> as hen's teeth and are worth their weight in gold.
>
> Bob
>
> On Wed, May 8, 2024 at 8:35 AM Dave Taht via Make-wifi-fast <
> make-wifi-fast@lists.bufferbloat.net> wrote:
>
>> I wish I had gone to the 802.11wg  more regularly than I did. I only
>> gave one bloat related presentation in 2014, shipped the
>> make-wifi-fast code in 2016(?), and never went back. IETF ate all my
>> money and time. I just assumed they were all in the slipstream of
>> linux and openwrt. :/
>>
>> I did have a great meetup a few weeks back with the former 802.11
>> chair (dorothy stanley, hi!!!) who is trying to recruit people to
>> participate in the wifi8 standard and perhaps some finishing touches
>> on wifi7. She gave a great update on the status of things at the
>> recent wifinow conference, but as there is a cost to that, perhaps she
>> can share her slides with us?
>>
>>
>> https://wifinowglobal.com/product/wi-fi-world-congress-usa-2024-sarasota-florida-presentations-pdf/?mc_cid=beb1b4a2ed&mc_eid=327a64ba92
>>
>> On Wed, May 8, 2024 at 8:28 AM Livingood, Jason via Bloat
>> <bloat@lists.bufferbloat.net> wrote:
>>>
>>> Dropping Starlink as Bloat is the right list. The IEEE 802.11 domain is
>> certainly different than IP, so typical IP CCs don’t apply. In our L4S/NQB
>> trials, we put LL-marked packets into the AC_VI WMM queue in the Wi-Fi
>> network. IMO there is more work in 802.11 to focus on latency – so much
>> focus right now is on throughput over everything else.
>>>
>>>
>>>
>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of
>> Rich Brown via Starlink <starlink@lists.bufferbloat.net>
>>> Reply-To: Rich Brown <richb.hanover@gmail.com>
>>> Date: Wednesday, May 8, 2024 at 07:33
>>> To: David Fernández <davidfdzp@gmail.com>
>>> Cc: starlink <starlink@lists.bufferbloat.net>, bloat <
>> bloat@lists.bufferbloat.net>
>>> Subject: Re: [Starlink] [Bloat] L4S
>>>
>>>
>>>
>>> Let's split this thread and use this message to continue the discussion
>> of L4S. Thanks
>>>
>>>
>>>
>>> On May 8, 2024, at 5:31 AM, David Fernández via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>>
>>>
>>>
>>> I see that L4S is not really solving everything (I read about issues
>> with Wi-Fi), although it seems to be a step in the right direction, to be
>> improved, let's hope.
>>>
>>>
>>>
>>> At least, Nokia is implementing it in its network gear (for mobile
>> operators), so the bufferbloat problem is somehow acknowledged by industry,
>> at least initially or partially.
>>>
>>>
>>>
>>> I have seen two consecutive RFCs to 9330:
>>>
>>> https://www.rfc-editor.org/info/rfc9331
>>>
>>> https://www.rfc-editor.org/info/rfc9332
>>>
>>>
>>>
>>> I suspect that optimal results require the bufferbloat to be addressed
>> not only at network layer (IP), but also with some pipelining or
>> cross-layering at link level (Ethernet, Wi-Fi or any other link technology,
>> such as 5G, SATCOM, VHF...)
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> David F.
>>>
>>>
>>>
>>> Date: Tue, 7 May 2024 08:46:03 -0400
>>>
>>> From: Dave Collier-Brown <dave.collier-Brown@indexexchange.com>
>>> To: starlink@lists.bufferbloat.net
>>> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
>>> Message-ID: <3d6bdccf-e3d1-4f62-a029-25bfd1f458f5@indexexchange.com>
>>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>
>>> It has an RFC at https://datatracker.ietf.org/doc/rfc9330/
>>>
>>> I read it as a way to rapidly find the available bandwidth without the
>> TCP "sawtooth". The paper cites fc_codel and research based on it.
>>>
>>> I suspect My Smarter Colleagues know more (;-))
>>>
>>> --dave
>>>
>>>
>>>
>>> On 2024-05-07 08:13, David Fernández via Starlink wrote:
>>> Is L4S a solution to bufferbloat? I have read that gamers are happy with
>> it.
>>>
>>> Sorry, I read it here, in Spanish:
>>>
>> https://www.adslzone.net/noticias/operadores/retardo-videojuegos-nokia-vodafone
>>>
>>> Regards,
>>>
>>> David F.
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>>
>>>
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>
>>
>> --
>> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
>> Dave Täht CSO, LibreQos
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[Hal Murray]

David Lang said:
> It really doesn't help that everyone in the industry is pushing for
> higher  bandwidth for a single host. That's a nice benchmark number, but
> not really  relevant int he real world.

> Even mu-mimo is of limited use as most routers only handle a handful of
> clients.

> But the biggest problem is just the push to use wider channels and gain
> efficiency in long-running bulk transfers by bundling lots of IP packets
> into a  single transmission. This works well when you don't have
> congestion and have a  small number of clients. But when you have lots of
> clients, spanning many  generations of wifi technology, you need to go to
> narrower channels, but more  separate routers to maximize the fairness of
> available airtime. 

What does that say about the minimal collection of gear required in a test 
lab?

If you had a lab with plenty of gear, what tests would you run?

How many different tests would it take to give reasonable coverage?


-- 
These are my opinions.  I hate spam.

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[David Lang]

On Sun, 1 Sep 2024, Hal Murray via Make-wifi-fast wrote:

> David Lang said:
>> It really doesn't help that everyone in the industry is pushing for
>> higher  bandwidth for a single host. That's a nice benchmark number, but
>> not really  relevant int he real world.
>
>> Even mu-mimo is of limited use as most routers only handle a handful of
>> clients.
>
>> But the biggest problem is just the push to use wider channels and gain
>> efficiency in long-running bulk transfers by bundling lots of IP packets
>> into a  single transmission. This works well when you don't have
>> congestion and have a  small number of clients. But when you have lots of
>> clients, spanning many  generations of wifi technology, you need to go to
>> narrower channels, but more  separate routers to maximize the fairness of
>> available airtime. 
>
> What does that say about the minimal collection of gear required in a test 
> lab?
>
> If you had a lab with plenty of gear, what tests would you run?

I'll start off by saying that my experience is from practical in-the-field uses, 
deploying wifi to support thousands of users in a conference setting. It's 
possible that some people are doing the tests I describe below in their labs, 
but from the way routers and wifi standards are advertised and the guides to 
deploy them are written, it doesn't seem like they are.

My belief is that most of the tests are done in relatively clean RF environments 
where only the devices on the test network exist, and they can always hear 
everyone on the network. In such environments, everything about existing wifi 
standards and the push for higher bandwidth channels makes a lot of sense (there 
are still some latency problems)

But the world outside the lab is far more complex

you need to simulate a dispursed, congested RF environment. This includes hidden 
transmitters (stations A-B-C where B can hear A and C but A and C cannot hear 
each other), dealing with weak signals (already covered), interactions of 
independent networks on the same channels (a-b and c-d that cannot talk to each 
other), legacy equipment on the network (as slow as 802.11g at least, if not 
802.11b to simulate old IoT devices), and a mix of bulk-transfers 
(download/uploads), buffered streaming (constant traffic, but buffered so not 
super-sentitive to latency), unbuffered streaming (low bandwidth, but sensitive 
to latency), and short, latency sensitive traffic (things that block other 
traffic until they are answered, like DNS, http cache checks, http main pages 
that they pull lots of other URLs, etc)

test large number of people in a given area (start with an all wireless office, 
then move on to classroom density), test not just one room, but multiple rooms 
that partially hear each other (the amount of attenuation or reflection between 
the rooms needs to vary). The ultimate density test would be a stadium-type 
setting where you have rows of chairs, but not tables and everyone is trying to 
livestream (or view a livestream) at once.

Test not just the ultra-wide bandwidth with a single AP in the rooms, but 
narrower channels with multiple APs distributed around the rooms. Test APs 
positioned high, and set to high power to have large coverage areas against APs 
positioned low (signals get absorbed by people, so channels can be reused at 
shorter distances) and set to low power (microcell approach). Test APs overhead 
with directional antennas so they cover a small footprint.

Test with different types of walls around/between the rooms, metal studs and 
sheetrock of a modern office have very little affect on signals, stone/brick 
walls of old buildings (and concrete walls in some areas of new buildings) 
absorb the signal, the metal grid in movable air walls blocks and reflects 
signals

Remember that these are operating in 'unlicensed' spectrum, and so you can have 
other devices operating here as well causing periodic interference (which could 
show up as short segments of corruption or just an increased noise floor). 
Current wifi standards interpret any failed signals as a weak signal, so they 
drop down to a slower modulation or increasing power in the hope of getting the 
signal through. If the problem is actually interference from other devices 
(especially other APs that it can't decipher), the result is that all stations 
end up yelling slowly to try and get through and the result is very high levels 
of noise and no messages getting through. Somehow, the systems should detect 
that the noise floor is high and/or that there is other stuff happening on the 
network that they can hear, but not necessarily decipher and switch away from 
the 'weak signal' mode of operation (which is appropriate in sparse 
environments), and instead work to talk faster and at lower power to try and 
reduce the overall interference while still getting their signal through. 
(it does no good for one station to be transmitting at 3w while the station it's 
talking to is transmitting at 50mw). As far as I know, there is currently no way 
for stations to signal what power they are using (and the effective power would 
be modified by the antenna system, both transmitted and received), so this may 
be that something like 'I'm transmitting at 50% of my max and I hear you at 30% 
with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you at 80% 
woth noise at 30%' could cause the first station to cut down on it's power until 
the two are hearing each other at similar levels (pure speculation here, 
suggestion for research ideas)

> How many different tests would it take to give reasonable coverage?

That's hard for me to say, and not every device needs to go through every test. 
But when working on a new standard, it needs to go through a lot of these tests, 
the most important ones IMHO are how they work with a high density of users 
accessing multiple routers which are distributed so there is overlapping 
coverage and include a mix of network traffic.

David Lang

Re: [Starlink] Real-world testing: wifi8 and 802.11 wg

[Rich Brown]

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


How can this message be flagged as an important "stake in the ground" re: testing of Wi-Fi for common/useful situations? Thanks, David...

> On Sep 2, 2024, at 1:05 AM, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> 
> I'll start off by saying that my experience is from practical in-the-field uses, deploying wifi to support thousands of users in a conference setting. It's possible that some people are doing the tests I describe below in their labs, but from the way routers and wifi standards are advertised and the guides to deploy them are written, it doesn't seem like they are.
> 
> My belief is that most of the tests are done in relatively clean RF environments where only the devices on the test network exist, and they can always hear everyone on the network. In such environments, everything about existing wifi standards and the push for higher bandwidth channels makes a lot of sense (there are still some latency problems)
> 
> But the world outside the lab is far more complex
> 
> you need to simulate a dispursed, congested RF environment. This includes hidden transmitters (stations A-B-C where B can hear A and C but A and C cannot hear each other), dealing with weak signals (already covered), interactions of independent networks on the same channels (a-b and c-d that cannot talk to each other), legacy equipment on the network (as slow as 802.11g at least, if not 802.11b to simulate old IoT devices), and a mix of bulk-transfers (download/uploads), buffered streaming (constant traffic, but buffered so not super-sentitive to latency), unbuffered streaming (low bandwidth, but sensitive to latency), and short, latency sensitive traffic (things that block other traffic until they are answered, like DNS, http cache checks, http main pages that they pull lots of other URLs, etc)
> 
> test large number of people in a given area (start with an all wireless office, then move on to classroom density), test not just one room, but multiple rooms that partially hear each other (the amount of attenuation or reflection between the rooms needs to vary). The ultimate density test would be a stadium-type setting where you have rows of chairs, but not tables and everyone is trying to livestream (or view a livestream) at once.
> 
> Test not just the ultra-wide bandwidth with a single AP in the rooms, but narrower channels with multiple APs distributed around the rooms. Test APs positioned high, and set to high power to have large coverage areas against APs positioned low (signals get absorbed by people, so channels can be reused at shorter distances) and set to low power (microcell approach). Test APs overhead with directional antennas so they cover a small footprint.
> 
> Test with different types of walls around/between the rooms, metal studs and sheetrock of a modern office have very little affect on signals, stone/brick walls of old buildings (and concrete walls in some areas of new buildings) absorb the signal, the metal grid in movable air walls blocks and reflects signals
> 
> Remember that these are operating in 'unlicensed' spectrum, and so you can have other devices operating here as well causing periodic interference (which could show up as short segments of corruption or just an increased noise floor). Current wifi standards interpret any failed signals as a weak signal, so they drop down to a slower modulation or increasing power in the hope of getting the signal through. If the problem is actually interference from other devices (especially other APs that it can't decipher), the result is that all stations end up yelling slowly to try and get through and the result is very high levels of noise and no messages getting through. Somehow, the systems should detect that the noise floor is high and/or that there is other stuff happening on the network that they can hear, but not necessarily decipher and switch away from the 'weak signal' mode of operation (which is appropriate in sparse environments), and instead work to talk faster and at lower power to try and reduce the overall interference while still getting their signal through. (it does no good for one station to be transmitting at 3w while the station it's talking to is transmitting at 50mw). As far as I know, there is currently no way for stations to signal what power they are using (and the effective power would be modified by the antenna system, both transmitted and received), so this may be that something like 'I'm transmitting at 50% of my max and I hear you at 30% with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you at 80% woth noise at 30%' could cause the first station to cut down on it's power until the two are hearing each other at similar levels (pure speculation here, suggestion for research ideas)
> 
>> How many different tests would it take to give reasonable coverage?
> 
> That's hard for me to say, and not every device needs to go through every test. But when working on a new standard, it needs to go through a lot of these tests, the most important ones IMHO are how they work with a high density of users accessing multiple routers which are distributed so there is overlapping coverage and include a mix of network traffic.
> 
> David Lang
> _________________________________


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

Re: [Starlink] [Make-wifi-fast] Real-world testing: wifi8 and 802.11 wg

[Sebastian Moeller]

@David,

did you ever give a talk about this, and if so is that available somewhere? And if not, maybe you should ;) 


Regards
	Sebastian


> On 2. Sep 2024, at 17:04, Rich Brown via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
> 
> 
> How can this message be flagged as an important "stake in the ground" re: testing of Wi-Fi for common/useful situations? Thanks, David...
> 
>> On Sep 2, 2024, at 1:05 AM, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
>> 
>> 
>> I'll start off by saying that my experience is from practical in-the-field uses, deploying wifi to support thousands of users in a conference setting. It's possible that some people are doing the tests I describe below in their labs, but from the way routers and wifi standards are advertised and the guides to deploy them are written, it doesn't seem like they are.
>> 
>> My belief is that most of the tests are done in relatively clean RF environments where only the devices on the test network exist, and they can always hear everyone on the network. In such environments, everything about existing wifi standards and the push for higher bandwidth channels makes a lot of sense (there are still some latency problems)
>> 
>> But the world outside the lab is far more complex
>> 
>> you need to simulate a dispursed, congested RF environment. This includes hidden transmitters (stations A-B-C where B can hear A and C but A and C cannot hear each other), dealing with weak signals (already covered), interactions of independent networks on the same channels (a-b and c-d that cannot talk to each other), legacy equipment on the network (as slow as 802.11g at least, if not 802.11b to simulate old IoT devices), and a mix of bulk-transfers (download/uploads), buffered streaming (constant traffic, but buffered so not super-sentitive to latency), unbuffered streaming (low bandwidth, but sensitive to latency), and short, latency sensitive traffic (things that block other traffic until they are answered, like DNS, http cache checks, http main pages that they pull lots of other URLs, etc)
>> 
>> test large number of people in a given area (start with an all wireless office, then move on to classroom density), test not just one room, but multiple rooms that partially hear each other (the amount of attenuation or reflection between the rooms needs to vary). The ultimate density test would be a stadium-type setting where you have rows of chairs, but not tables and everyone is trying to livestream (or view a livestream) at once.
>> 
>> Test not just the ultra-wide bandwidth with a single AP in the rooms, but narrower channels with multiple APs distributed around the rooms. Test APs positioned high, and set to high power to have large coverage areas against APs positioned low (signals get absorbed by people, so channels can be reused at shorter distances) and set to low power (microcell approach). Test APs overhead with directional antennas so they cover a small footprint.
>> 
>> Test with different types of walls around/between the rooms, metal studs and sheetrock of a modern office have very little affect on signals, stone/brick walls of old buildings (and concrete walls in some areas of new buildings) absorb the signal, the metal grid in movable air walls blocks and reflects signals
>> 
>> Remember that these are operating in 'unlicensed' spectrum, and so you can have other devices operating here as well causing periodic interference (which could show up as short segments of corruption or just an increased noise floor). Current wifi standards interpret any failed signals as a weak signal, so they drop down to a slower modulation or increasing power in the hope of getting the signal through. If the problem is actually interference from other devices (especially other APs that it can't decipher), the result is that all stations end up yelling slowly to try and get through and the result is very high levels of noise and no messages getting through. Somehow, the systems should detect that the noise floor is high and/or that there is other stuff happening on the network that they can hear, but not necessarily decipher and switch away from the 'weak signal' mode of operation (which is appropriate in sparse environments), and instead work to talk faster and at lower power to try and reduce the overall interference while still getting their signal through. (it does no good for one station to be transmitting at 3w while the station it's talking to is transmitting at 50mw). As far as I know, there is currently no way for stations to signal what power they are using (and the effective power would be modified by the antenna system, both transmitted and received), so this may be that something like 'I'm transmitting at 50% of my max and I hear you at 30% with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you at 80% woth noise at 30%' could cause the first station to cut down on it's power until the two are hearing each other at similar levels (pure speculation here, suggestion for research ideas)
>> 
>>> How many different tests would it take to give reasonable coverage?
>> 
>> That's hard for me to say, and not every device needs to go through every test. But when working on a new standard, it needs to go through a lot of these tests, the most important ones IMHO are how they work with a high density of users accessing multiple routers which are distributed so there is overlapping coverage and include a mix of network traffic.
>> 
>> David Lang
>> _________________________________
> 
> 
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

Re: [Starlink] [Make-wifi-fast] Real-world testing: wifi8 and 802.11 wg

[David Lang]

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

I have given a couple (not this comprehensive because it was before the extra 
wide channels were available)

https://www.usenix.org/publications/login/april-2013-volume-38-number-2/wireless-means-radio
https://www.usenix.org/conference/lisa12/technical-sessions/presentation/lang_david_wireless
http://lang.hm/talks/events/Cascadia_2012/Wireless/ (I never did get around to 
combining the video, audio and screen recording into one file, sorry)

Once I find a new job (security archiect/engineer) I'd be happy to give it more. 
Any suggestions on where?

David Lang


On Mon, 2 Sep 2024, Sebastian Moeller wrote:

> Date: Mon, 2 Sep 2024 17:09:09 +0200
> From: Sebastian Moeller <moeller0@gmx.de>
> To: Rich Brown <richb.hanover@gmail.com>
> Cc: David Lang <david@lang.hm>, Starlink <starlink@lists.bufferbloat.net>,
>     bloat <bloat@lists.bufferbloat.net>,
>     Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
> Subject: Re: [Make-wifi-fast] Real-world testing: wifi8 and 802.11 wg
> 
> @David,
>
> did you ever give a talk about this, and if so is that available somewhere? And if not, maybe you should ;)
>
>
> Regards
> 	Sebastian
>
>
>> On 2. Sep 2024, at 17:04, Rich Brown via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net> wrote:
>>
>>
>> How can this message be flagged as an important "stake in the ground" re: testing of Wi-Fi for common/useful situations? Thanks, David...
>>
>>> On Sep 2, 2024, at 1:05 AM, David Lang via Starlink <starlink@lists.bufferbloat.net> wrote:
>>>
>>>
>>> I'll start off by saying that my experience is from practical in-the-field uses, deploying wifi to support thousands of users in a conference setting. It's possible that some people are doing the tests I describe below in their labs, but from the way routers and wifi standards are advertised and the guides to deploy them are written, it doesn't seem like they are.
>>>
>>> My belief is that most of the tests are done in relatively clean RF environments where only the devices on the test network exist, and they can always hear everyone on the network. In such environments, everything about existing wifi standards and the push for higher bandwidth channels makes a lot of sense (there are still some latency problems)
>>>
>>> But the world outside the lab is far more complex
>>>
>>> you need to simulate a dispursed, congested RF environment. This includes hidden transmitters (stations A-B-C where B can hear A and C but A and C cannot hear each other), dealing with weak signals (already covered), interactions of independent networks on the same channels (a-b and c-d that cannot talk to each other), legacy equipment on the network (as slow as 802.11g at least, if not 802.11b to simulate old IoT devices), and a mix of bulk-transfers (download/uploads), buffered streaming (constant traffic, but buffered so not super-sentitive to latency), unbuffered streaming (low bandwidth, but sensitive to latency), and short, latency sensitive traffic (things that block other traffic until they are answered, like DNS, http cache checks, http main pages that they pull lots of other URLs, etc)
>>>
>>> test large number of people in a given area (start with an all wireless office, then move on to classroom density), test not just one room, but multiple rooms that partially hear each other (the amount of attenuation or reflection between the rooms needs to vary). The ultimate density test would be a stadium-type setting where you have rows of chairs, but not tables and everyone is trying to livestream (or view a livestream) at once.
>>>
>>> Test not just the ultra-wide bandwidth with a single AP in the rooms, but narrower channels with multiple APs distributed around the rooms. Test APs positioned high, and set to high power to have large coverage areas against APs positioned low (signals get absorbed by people, so channels can be reused at shorter distances) and set to low power (microcell approach). Test APs overhead with directional antennas so they cover a small footprint.
>>>
>>> Test with different types of walls around/between the rooms, metal studs and sheetrock of a modern office have very little affect on signals, stone/brick walls of old buildings (and concrete walls in some areas of new buildings) absorb the signal, the metal grid in movable air walls blocks and reflects signals
>>>
>>> Remember that these are operating in 'unlicensed' spectrum, and so you can have other devices operating here as well causing periodic interference (which could show up as short segments of corruption or just an increased noise floor). Current wifi standards interpret any failed signals as a weak signal, so they drop down to a slower modulation or increasing power in the hope of getting the signal through. If the problem is actually interference from other devices (especially other APs that it can't decipher), the result is that all stations end up yelling slowly to try and get through and the result is very high levels of noise and no messages getting through. Somehow, the systems should detect that the noise floor is high and/or that there is other stuff happening on the network that they can hear, but not necessarily decipher and switch away from the 'weak signal' mode of operation (which is appropriate in sparse environments), and instead work to talk faster and at lower power
  to try and reduce the overall interference while still getting their signal through. (it does no good for one station to be transmitting at 3w while the station it's talking to is transmitting at 50mw). As far as I know, there is currently no way for stations to signal what power they are using (and the effective power would be modified by the antenna system, both transmitted and received), so this may be that something like 'I'm transmitting at 50% of my max and I hear you at 30% with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you at 80% woth noise at 30%' could cause the first station to cut down on it's power until the two are hearing each other at similar levels (pure speculation here, suggestion for research ideas)
>>>
>>>> How many different tests would it take to give reasonable coverage?
>>>
>>> That's hard for me to say, and not every device needs to go through every test. But when working on a new standard, it needs to go through a lot of these tests, the most important ones IMHO are how they work with a high density of users accessing multiple routers which are distributed so there is overlapping coverage and include a mix of network traffic.
>>>
>>> David Lang
>>> _________________________________
>>
>>
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
>

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 8180 bytes --]

This is David's experience. It doesn't extrapolate to the industry. Our
testing as a component supplier is quite extensive. The level of math
required likely equals ML. The table stakes for a 2 BSS system with hidden
nodes, etc is $80K. That's just equipment. Then test engineers with deep
expertise of 802.11 have to be hired. And they have to continuously learn
as 802.11 is a living standard. And now they need to learn CCAs and network
marking planes. Then this all has to be paid for typically through
component sells as there are no software SKUs.

The cadences for new ASICs is 24 months. The cadences for OSP upgrades is
10 to 20 years.

Of course testing is under funded. No stock b.s. to pay the bills. It has
to come from discounted cash flows.

Everyone wants the experts to work for free. Iperf2 is that already. I
don't see any more freebies on the horizon.

Bob

On Sun, Sep 1, 2024, 10:05 PM David Lang via Make-wifi-fast <
make-wifi-fast@lists.bufferbloat.net> wrote:

> On Sun, 1 Sep 2024, Hal Murray via Make-wifi-fast wrote:
>
> > David Lang said:
> >> It really doesn't help that everyone in the industry is pushing for
> >> higher  bandwidth for a single host. That's a nice benchmark number, but
> >> not really  relevant int he real world.
> >
> >> Even mu-mimo is of limited use as most routers only handle a handful of
> >> clients.
> >
> >> But the biggest problem is just the push to use wider channels and gain
> >> efficiency in long-running bulk transfers by bundling lots of IP packets
> >> into a  single transmission. This works well when you don't have
> >> congestion and have a  small number of clients. But when you have lots
> of
> >> clients, spanning many  generations of wifi technology, you need to go
> to
> >> narrower channels, but more  separate routers to maximize the fairness
> of
> >> available airtime.
> >
> > What does that say about the minimal collection of gear required in a
> test
> > lab?
> >
> > If you had a lab with plenty of gear, what tests would you run?
>
> I'll start off by saying that my experience is from practical in-the-field
> uses,
> deploying wifi to support thousands of users in a conference setting. It's
> possible that some people are doing the tests I describe below in their
> labs,
> but from the way routers and wifi standards are advertised and the guides
> to
> deploy them are written, it doesn't seem like they are.
>
> My belief is that most of the tests are done in relatively clean RF
> environments
> where only the devices on the test network exist, and they can always hear
> everyone on the network. In such environments, everything about existing
> wifi
> standards and the push for higher bandwidth channels makes a lot of sense
> (there
> are still some latency problems)
>
> But the world outside the lab is far more complex
>
> you need to simulate a dispursed, congested RF environment. This includes
> hidden
> transmitters (stations A-B-C where B can hear A and C but A and C cannot
> hear
> each other), dealing with weak signals (already covered), interactions of
> independent networks on the same channels (a-b and c-d that cannot talk to
> each
> other), legacy equipment on the network (as slow as 802.11g at least, if
> not
> 802.11b to simulate old IoT devices), and a mix of bulk-transfers
> (download/uploads), buffered streaming (constant traffic, but buffered so
> not
> super-sentitive to latency), unbuffered streaming (low bandwidth, but
> sensitive
> to latency), and short, latency sensitive traffic (things that block other
> traffic until they are answered, like DNS, http cache checks, http main
> pages
> that they pull lots of other URLs, etc)
>
> test large number of people in a given area (start with an all wireless
> office,
> then move on to classroom density), test not just one room, but multiple
> rooms
> that partially hear each other (the amount of attenuation or reflection
> between
> the rooms needs to vary). The ultimate density test would be a
> stadium-type
> setting where you have rows of chairs, but not tables and everyone is
> trying to
> livestream (or view a livestream) at once.
>
> Test not just the ultra-wide bandwidth with a single AP in the rooms, but
> narrower channels with multiple APs distributed around the rooms. Test APs
> positioned high, and set to high power to have large coverage areas
> against APs
> positioned low (signals get absorbed by people, so channels can be reused
> at
> shorter distances) and set to low power (microcell approach). Test APs
> overhead
> with directional antennas so they cover a small footprint.
>
> Test with different types of walls around/between the rooms, metal studs
> and
> sheetrock of a modern office have very little affect on signals,
> stone/brick
> walls of old buildings (and concrete walls in some areas of new buildings)
> absorb the signal, the metal grid in movable air walls blocks and reflects
> signals
>
> Remember that these are operating in 'unlicensed' spectrum, and so you can
> have
> other devices operating here as well causing periodic interference (which
> could
> show up as short segments of corruption or just an increased noise floor).
> Current wifi standards interpret any failed signals as a weak signal, so
> they
> drop down to a slower modulation or increasing power in the hope of
> getting the
> signal through. If the problem is actually interference from other devices
> (especially other APs that it can't decipher), the result is that all
> stations
> end up yelling slowly to try and get through and the result is very high
> levels
> of noise and no messages getting through. Somehow, the systems should
> detect
> that the noise floor is high and/or that there is other stuff happening on
> the
> network that they can hear, but not necessarily decipher and switch away
> from
> the 'weak signal' mode of operation (which is appropriate in sparse
> environments), and instead work to talk faster and at lower power to try
> and
> reduce the overall interference while still getting their signal through.
> (it does no good for one station to be transmitting at 3w while the
> station it's
> talking to is transmitting at 50mw). As far as I know, there is currently
> no way
> for stations to signal what power they are using (and the effective power
> would
> be modified by the antenna system, both transmitted and received), so this
> may
> be that something like 'I'm transmitting at 50% of my max and I hear you
> at 30%
> with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you
> at 80%
> woth noise at 30%' could cause the first station to cut down on it's power
> until
> the two are hearing each other at similar levels (pure speculation here,
> suggestion for research ideas)
>
> > How many different tests would it take to give reasonable coverage?
>
> That's hard for me to say, and not every device needs to go through every
> test.
> But when working on a new standard, it needs to go through a lot of these
> tests,
> the most important ones IMHO are how they work with a high density of
> users
> accessing multiple routers which are distributed so there is overlapping
> coverage and include a mix of network traffic.
>
> David Lang
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

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

[-- Attachment #1.2: Type: text/html, Size: 9436 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

Re: [Starlink] [Bloat] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[Frantisek Borsik]

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

Jim Salter at Ars Technica, back in the days, used to do some good tests:
https://arstechnica.com/gadgets/2016/09/the-router-rumble-ars-diy-build-faces-better-tests-tougher-competition/

And Plume used to have a real test house back then, as well:
https://arstechnica.com/gadgets/2017/02/going-hands-on-and-behind-the-scenes-at-the-plume-wi-fi-hq/2/


All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Mon, Sep 2, 2024 at 7:29 PM Bob McMahon via Bloat <
bloat@lists.bufferbloat.net> wrote:

> This is David's experience. It doesn't extrapolate to the industry. Our
> testing as a component supplier is quite extensive. The level of math
> required likely equals ML. The table stakes for a 2 BSS system with hidden
> nodes, etc is $80K. That's just equipment. Then test engineers with deep
> expertise of 802.11 have to be hired. And they have to continuously learn
> as 802.11 is a living standard. And now they need to learn CCAs and network
> marking planes. Then this all has to be paid for typically through
> component sells as there are no software SKUs.
>
> The cadences for new ASICs is 24 months. The cadences for OSP upgrades is
> 10 to 20 years.
>
> Of course testing is under funded. No stock b.s. to pay the bills. It has
> to come from discounted cash flows.
>
> Everyone wants the experts to work for free. Iperf2 is that already. I
> don't see any more freebies on the horizon.
>
> Bob
>
> On Sun, Sep 1, 2024, 10:05 PM David Lang via Make-wifi-fast <
> make-wifi-fast@lists.bufferbloat.net> wrote:
>
>> On Sun, 1 Sep 2024, Hal Murray via Make-wifi-fast wrote:
>>
>> > David Lang said:
>> >> It really doesn't help that everyone in the industry is pushing for
>> >> higher  bandwidth for a single host. That's a nice benchmark number,
>> but
>> >> not really  relevant int he real world.
>> >
>> >> Even mu-mimo is of limited use as most routers only handle a handful of
>> >> clients.
>> >
>> >> But the biggest problem is just the push to use wider channels and gain
>> >> efficiency in long-running bulk transfers by bundling lots of IP
>> packets
>> >> into a  single transmission. This works well when you don't have
>> >> congestion and have a  small number of clients. But when you have lots
>> of
>> >> clients, spanning many  generations of wifi technology, you need to go
>> to
>> >> narrower channels, but more  separate routers to maximize the fairness
>> of
>> >> available airtime.
>> >
>> > What does that say about the minimal collection of gear required in a
>> test
>> > lab?
>> >
>> > If you had a lab with plenty of gear, what tests would you run?
>>
>> I'll start off by saying that my experience is from practical
>> in-the-field uses,
>> deploying wifi to support thousands of users in a conference setting.
>> It's
>> possible that some people are doing the tests I describe below in their
>> labs,
>> but from the way routers and wifi standards are advertised and the guides
>> to
>> deploy them are written, it doesn't seem like they are.
>>
>> My belief is that most of the tests are done in relatively clean RF
>> environments
>> where only the devices on the test network exist, and they can always
>> hear
>> everyone on the network. In such environments, everything about existing
>> wifi
>> standards and the push for higher bandwidth channels makes a lot of sense
>> (there
>> are still some latency problems)
>>
>> But the world outside the lab is far more complex
>>
>> you need to simulate a dispursed, congested RF environment. This includes
>> hidden
>> transmitters (stations A-B-C where B can hear A and C but A and C cannot
>> hear
>> each other), dealing with weak signals (already covered), interactions of
>> independent networks on the same channels (a-b and c-d that cannot talk
>> to each
>> other), legacy equipment on the network (as slow as 802.11g at least, if
>> not
>> 802.11b to simulate old IoT devices), and a mix of bulk-transfers
>> (download/uploads), buffered streaming (constant traffic, but buffered so
>> not
>> super-sentitive to latency), unbuffered streaming (low bandwidth, but
>> sensitive
>> to latency), and short, latency sensitive traffic (things that block
>> other
>> traffic until they are answered, like DNS, http cache checks, http main
>> pages
>> that they pull lots of other URLs, etc)
>>
>> test large number of people in a given area (start with an all wireless
>> office,
>> then move on to classroom density), test not just one room, but multiple
>> rooms
>> that partially hear each other (the amount of attenuation or reflection
>> between
>> the rooms needs to vary). The ultimate density test would be a
>> stadium-type
>> setting where you have rows of chairs, but not tables and everyone is
>> trying to
>> livestream (or view a livestream) at once.
>>
>> Test not just the ultra-wide bandwidth with a single AP in the rooms, but
>> narrower channels with multiple APs distributed around the rooms. Test
>> APs
>> positioned high, and set to high power to have large coverage areas
>> against APs
>> positioned low (signals get absorbed by people, so channels can be reused
>> at
>> shorter distances) and set to low power (microcell approach). Test APs
>> overhead
>> with directional antennas so they cover a small footprint.
>>
>> Test with different types of walls around/between the rooms, metal studs
>> and
>> sheetrock of a modern office have very little affect on signals,
>> stone/brick
>> walls of old buildings (and concrete walls in some areas of new
>> buildings)
>> absorb the signal, the metal grid in movable air walls blocks and
>> reflects
>> signals
>>
>> Remember that these are operating in 'unlicensed' spectrum, and so you
>> can have
>> other devices operating here as well causing periodic interference (which
>> could
>> show up as short segments of corruption or just an increased noise
>> floor).
>> Current wifi standards interpret any failed signals as a weak signal, so
>> they
>> drop down to a slower modulation or increasing power in the hope of
>> getting the
>> signal through. If the problem is actually interference from other
>> devices
>> (especially other APs that it can't decipher), the result is that all
>> stations
>> end up yelling slowly to try and get through and the result is very high
>> levels
>> of noise and no messages getting through. Somehow, the systems should
>> detect
>> that the noise floor is high and/or that there is other stuff happening
>> on the
>> network that they can hear, but not necessarily decipher and switch away
>> from
>> the 'weak signal' mode of operation (which is appropriate in sparse
>> environments), and instead work to talk faster and at lower power to try
>> and
>> reduce the overall interference while still getting their signal through.
>> (it does no good for one station to be transmitting at 3w while the
>> station it's
>> talking to is transmitting at 50mw). As far as I know, there is currently
>> no way
>> for stations to signal what power they are using (and the effective power
>> would
>> be modified by the antenna system, both transmitted and received), so
>> this may
>> be that something like 'I'm transmitting at 50% of my max and I hear you
>> at 30%
>> with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you
>> at 80%
>> woth noise at 30%' could cause the first station to cut down on it's
>> power until
>> the two are hearing each other at similar levels (pure speculation here,
>> suggestion for research ideas)
>>
>> > How many different tests would it take to give reasonable coverage?
>>
>> That's hard for me to say, and not every device needs to go through every
>> test.
>> But when working on a new standard, it needs to go through a lot of these
>> tests,
>> the most important ones IMHO are how they work with a high density of
>> users
>> accessing multiple routers which are distributed so there is overlapping
>> coverage and include a mix of network traffic.
>>
>> David Lang
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
> 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
>

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

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[Bob McMahon]

[-- Attachment #1.1.1: Type: text/plain, Size: 9067 bytes --]

Here's a deck on RF topologies. This is not enough. Folks need to
understand multivariate analysis and multivariate statistics, covariance
matrices, eigenvalues & eigenvectors, etc. Know how to program in python.
Have expertise in every OS. And the list goes on.

Wi-Fi is at 20B devices on the way to 100B and more. It's a huge
undertaking and is expensive.

Bob

On Mon, Sep 2, 2024 at 10:28 AM Bob McMahon <bob.mcmahon@broadcom.com>
wrote:

> This is David's experience. It doesn't extrapolate to the industry. Our
> testing as a component supplier is quite extensive. The level of math
> required likely equals ML. The table stakes for a 2 BSS system with hidden
> nodes, etc is $80K. That's just equipment. Then test engineers with deep
> expertise of 802.11 have to be hired. And they have to continuously learn
> as 802.11 is a living standard. And now they need to learn CCAs and network
> marking planes. Then this all has to be paid for typically through
> component sells as there are no software SKUs.
>
> The cadences for new ASICs is 24 months. The cadences for OSP upgrades is
> 10 to 20 years.
>
> Of course testing is under funded. No stock b.s. to pay the bills. It has
> to come from discounted cash flows.
>
> Everyone wants the experts to work for free. Iperf2 is that already. I
> don't see any more freebies on the horizon.
>
> Bob
>
> On Sun, Sep 1, 2024, 10:05 PM David Lang via Make-wifi-fast <
> make-wifi-fast@lists.bufferbloat.net> wrote:
>
>> On Sun, 1 Sep 2024, Hal Murray via Make-wifi-fast wrote:
>>
>> > David Lang said:
>> >> It really doesn't help that everyone in the industry is pushing for
>> >> higher  bandwidth for a single host. That's a nice benchmark number,
>> but
>> >> not really  relevant int he real world.
>> >
>> >> Even mu-mimo is of limited use as most routers only handle a handful of
>> >> clients.
>> >
>> >> But the biggest problem is just the push to use wider channels and gain
>> >> efficiency in long-running bulk transfers by bundling lots of IP
>> packets
>> >> into a  single transmission. This works well when you don't have
>> >> congestion and have a  small number of clients. But when you have lots
>> of
>> >> clients, spanning many  generations of wifi technology, you need to go
>> to
>> >> narrower channels, but more  separate routers to maximize the fairness
>> of
>> >> available airtime.
>> >
>> > What does that say about the minimal collection of gear required in a
>> test
>> > lab?
>> >
>> > If you had a lab with plenty of gear, what tests would you run?
>>
>> I'll start off by saying that my experience is from practical
>> in-the-field uses,
>> deploying wifi to support thousands of users in a conference setting.
>> It's
>> possible that some people are doing the tests I describe below in their
>> labs,
>> but from the way routers and wifi standards are advertised and the guides
>> to
>> deploy them are written, it doesn't seem like they are.
>>
>> My belief is that most of the tests are done in relatively clean RF
>> environments
>> where only the devices on the test network exist, and they can always
>> hear
>> everyone on the network. In such environments, everything about existing
>> wifi
>> standards and the push for higher bandwidth channels makes a lot of sense
>> (there
>> are still some latency problems)
>>
>> But the world outside the lab is far more complex
>>
>> you need to simulate a dispursed, congested RF environment. This includes
>> hidden
>> transmitters (stations A-B-C where B can hear A and C but A and C cannot
>> hear
>> each other), dealing with weak signals (already covered), interactions of
>> independent networks on the same channels (a-b and c-d that cannot talk
>> to each
>> other), legacy equipment on the network (as slow as 802.11g at least, if
>> not
>> 802.11b to simulate old IoT devices), and a mix of bulk-transfers
>> (download/uploads), buffered streaming (constant traffic, but buffered so
>> not
>> super-sentitive to latency), unbuffered streaming (low bandwidth, but
>> sensitive
>> to latency), and short, latency sensitive traffic (things that block
>> other
>> traffic until they are answered, like DNS, http cache checks, http main
>> pages
>> that they pull lots of other URLs, etc)
>>
>> test large number of people in a given area (start with an all wireless
>> office,
>> then move on to classroom density), test not just one room, but multiple
>> rooms
>> that partially hear each other (the amount of attenuation or reflection
>> between
>> the rooms needs to vary). The ultimate density test would be a
>> stadium-type
>> setting where you have rows of chairs, but not tables and everyone is
>> trying to
>> livestream (or view a livestream) at once.
>>
>> Test not just the ultra-wide bandwidth with a single AP in the rooms, but
>> narrower channels with multiple APs distributed around the rooms. Test
>> APs
>> positioned high, and set to high power to have large coverage areas
>> against APs
>> positioned low (signals get absorbed by people, so channels can be reused
>> at
>> shorter distances) and set to low power (microcell approach). Test APs
>> overhead
>> with directional antennas so they cover a small footprint.
>>
>> Test with different types of walls around/between the rooms, metal studs
>> and
>> sheetrock of a modern office have very little affect on signals,
>> stone/brick
>> walls of old buildings (and concrete walls in some areas of new
>> buildings)
>> absorb the signal, the metal grid in movable air walls blocks and
>> reflects
>> signals
>>
>> Remember that these are operating in 'unlicensed' spectrum, and so you
>> can have
>> other devices operating here as well causing periodic interference (which
>> could
>> show up as short segments of corruption or just an increased noise
>> floor).
>> Current wifi standards interpret any failed signals as a weak signal, so
>> they
>> drop down to a slower modulation or increasing power in the hope of
>> getting the
>> signal through. If the problem is actually interference from other
>> devices
>> (especially other APs that it can't decipher), the result is that all
>> stations
>> end up yelling slowly to try and get through and the result is very high
>> levels
>> of noise and no messages getting through. Somehow, the systems should
>> detect
>> that the noise floor is high and/or that there is other stuff happening
>> on the
>> network that they can hear, but not necessarily decipher and switch away
>> from
>> the 'weak signal' mode of operation (which is appropriate in sparse
>> environments), and instead work to talk faster and at lower power to try
>> and
>> reduce the overall interference while still getting their signal through.
>> (it does no good for one station to be transmitting at 3w while the
>> station it's
>> talking to is transmitting at 50mw). As far as I know, there is currently
>> no way
>> for stations to signal what power they are using (and the effective power
>> would
>> be modified by the antenna system, both transmitted and received), so
>> this may
>> be that something like 'I'm transmitting at 50% of my max and I hear you
>> at 30%
>> with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you
>> at 80%
>> woth noise at 30%' could cause the first station to cut down on it's
>> power until
>> the two are hearing each other at similar levels (pure speculation here,
>> suggestion for research ideas)
>>
>> > How many different tests would it take to give reasonable coverage?
>>
>> That's hard for me to say, and not every device needs to go through every
>> test.
>> But when working on a new standard, it needs to go through a lot of these
>> tests,
>> the most important ones IMHO are how they work with a high density of
>> users
>> accessing multiple routers which are distributed so there is overlapping
>> coverage and include a mix of network traffic.
>>
>> David Lang
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>

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

[-- Attachment #1.1.2: Type: text/html, Size: 10227 bytes --]

[-- Attachment #1.2: RF-Topologies.pdf --]
[-- Type: application/pdf, Size: 1657597 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[David Lang]

Bob McMahon wrote:

> This is David's experience. It doesn't extrapolate to the industry.

If I didn't make it clear, I have no inside information on the industry, I am 
operating from the point of view of a consumer useing the products and looking 
at how they are advertised and how they work in practice.

My frustration is less with the product manufacturers than it is with the 
standards people. I don't expect a product manufacturer to test beyond 'does it 
meet the standard' (with some interoperability to see if everyone is 
interpreting the standard the same way)

But the people drafting the standards (which may include some of the 
manufacturers), do need to be doing the more expensive and extensive testing for 
real-world conditions, not just the easier to test lab conditions. And that's 
where I don't see much progress over the years.

If you live on a house with a 1 acre lot or larger, the current standards will 
work well for you. In a school or apartment building, there seems to be a lack 
of progress at the standards level (and therefor at the product level) from the 
time that the OLPC first attempted to do serious work in high density 
environments.

David Lang

> Our
> testing as a component supplier is quite extensive. The level of math
> required likely equals ML. The table stakes for a 2 BSS system with hidden
> nodes, etc is $80K. That's just equipment. Then test engineers with deep
> expertise of 802.11 have to be hired. And they have to continuously learn
> as 802.11 is a living standard. And now they need to learn CCAs and network
> marking planes. Then this all has to be paid for typically through
> component sells as there are no software SKUs.
>
> The cadences for new ASICs is 24 months. The cadences for OSP upgrades is
> 10 to 20 years.
>
> Of course testing is under funded. No stock b.s. to pay the bills. It has
> to come from discounted cash flows.
>
> Everyone wants the experts to work for free. Iperf2 is that already. I
> don't see any more freebies on the horizon.
>
> Bob
>
> On Sun, Sep 1, 2024, 10:05 PM David Lang via Make-wifi-fast <
> make-wifi-fast@lists.bufferbloat.net> wrote:
>
>> On Sun, 1 Sep 2024, Hal Murray via Make-wifi-fast wrote:
>>
>>> David Lang said:
>>>> It really doesn't help that everyone in the industry is pushing for
>>>> higher  bandwidth for a single host. That's a nice benchmark number, but
>>>> not really  relevant int he real world.
>>>
>>>> Even mu-mimo is of limited use as most routers only handle a handful of
>>>> clients.
>>>
>>>> But the biggest problem is just the push to use wider channels and gain
>>>> efficiency in long-running bulk transfers by bundling lots of IP packets
>>>> into a  single transmission. This works well when you don't have
>>>> congestion and have a  small number of clients. But when you have lots
>> of
>>>> clients, spanning many  generations of wifi technology, you need to go
>> to
>>>> narrower channels, but more  separate routers to maximize the fairness
>> of
>>>> available airtime.
>>>
>>> What does that say about the minimal collection of gear required in a
>> test
>>> lab?
>>>
>>> If you had a lab with plenty of gear, what tests would you run?
>>
>> I'll start off by saying that my experience is from practical in-the-field
>> uses,
>> deploying wifi to support thousands of users in a conference setting. It's
>> possible that some people are doing the tests I describe below in their
>> labs,
>> but from the way routers and wifi standards are advertised and the guides
>> to
>> deploy them are written, it doesn't seem like they are.
>>
>> My belief is that most of the tests are done in relatively clean RF
>> environments
>> where only the devices on the test network exist, and they can always hear
>> everyone on the network. In such environments, everything about existing
>> wifi
>> standards and the push for higher bandwidth channels makes a lot of sense
>> (there
>> are still some latency problems)
>>
>> But the world outside the lab is far more complex
>>
>> you need to simulate a dispursed, congested RF environment. This includes
>> hidden
>> transmitters (stations A-B-C where B can hear A and C but A and C cannot
>> hear
>> each other), dealing with weak signals (already covered), interactions of
>> independent networks on the same channels (a-b and c-d that cannot talk to
>> each
>> other), legacy equipment on the network (as slow as 802.11g at least, if
>> not
>> 802.11b to simulate old IoT devices), and a mix of bulk-transfers
>> (download/uploads), buffered streaming (constant traffic, but buffered so
>> not
>> super-sentitive to latency), unbuffered streaming (low bandwidth, but
>> sensitive
>> to latency), and short, latency sensitive traffic (things that block other
>> traffic until they are answered, like DNS, http cache checks, http main
>> pages
>> that they pull lots of other URLs, etc)
>>
>> test large number of people in a given area (start with an all wireless
>> office,
>> then move on to classroom density), test not just one room, but multiple
>> rooms
>> that partially hear each other (the amount of attenuation or reflection
>> between
>> the rooms needs to vary). The ultimate density test would be a
>> stadium-type
>> setting where you have rows of chairs, but not tables and everyone is
>> trying to
>> livestream (or view a livestream) at once.
>>
>> Test not just the ultra-wide bandwidth with a single AP in the rooms, but
>> narrower channels with multiple APs distributed around the rooms. Test APs
>> positioned high, and set to high power to have large coverage areas
>> against APs
>> positioned low (signals get absorbed by people, so channels can be reused
>> at
>> shorter distances) and set to low power (microcell approach). Test APs
>> overhead
>> with directional antennas so they cover a small footprint.
>>
>> Test with different types of walls around/between the rooms, metal studs
>> and
>> sheetrock of a modern office have very little affect on signals,
>> stone/brick
>> walls of old buildings (and concrete walls in some areas of new buildings)
>> absorb the signal, the metal grid in movable air walls blocks and reflects
>> signals
>>
>> Remember that these are operating in 'unlicensed' spectrum, and so you can
>> have
>> other devices operating here as well causing periodic interference (which
>> could
>> show up as short segments of corruption or just an increased noise floor).
>> Current wifi standards interpret any failed signals as a weak signal, so
>> they
>> drop down to a slower modulation or increasing power in the hope of
>> getting the
>> signal through. If the problem is actually interference from other devices
>> (especially other APs that it can't decipher), the result is that all
>> stations
>> end up yelling slowly to try and get through and the result is very high
>> levels
>> of noise and no messages getting through. Somehow, the systems should
>> detect
>> that the noise floor is high and/or that there is other stuff happening on
>> the
>> network that they can hear, but not necessarily decipher and switch away
>> from
>> the 'weak signal' mode of operation (which is appropriate in sparse
>> environments), and instead work to talk faster and at lower power to try
>> and
>> reduce the overall interference while still getting their signal through.
>> (it does no good for one station to be transmitting at 3w while the
>> station it's
>> talking to is transmitting at 50mw). As far as I know, there is currently
>> no way
>> for stations to signal what power they are using (and the effective power
>> would
>> be modified by the antenna system, both transmitted and received), so this
>> may
>> be that something like 'I'm transmitting at 50% of my max and I hear you
>> at 30%
>> with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear you
>> at 80%
>> woth noise at 30%' could cause the first station to cut down on it's power
>> until
>> the two are hearing each other at similar levels (pure speculation here,
>> suggestion for research ideas)
>>
>>> How many different tests would it take to give reasonable coverage?
>>
>> That's hard for me to say, and not every device needs to go through every
>> test.
>> But when working on a new standard, it needs to go through a lot of these
>> tests,
>> the most important ones IMHO are how they work with a high density of
>> users
>> accessing multiple routers which are distributed so there is overlapping
>> coverage and include a mix of network traffic.
>>
>> David Lang
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[Bob McMahon]

[-- Attachment #1.1: Type: text/plain, Size: 10982 bytes --]

Wi-Fi Alliance does certifications. I think that's the group that would
need to take on new certification & test scenarios.

The 802.11 standards folks don't do testing, nor do they even make sure
the current state of engineering can realize the standard which is in the
form of a document. And to your point, per the MCS index table, a PHY rate
selection engineer has microseconds to find the one entry that is the local
optimum for the transmit at hand.. https://mcsindex.com/  The standards
group created the table of options with little to no regard of the PHY rate
selection engineer's task. It's kinda like a composer who writes symphonies
that no orchestra can play.

Bob

On Mon, Sep 2, 2024 at 8:20 PM David Lang <david@lang.hm> wrote:

> Bob McMahon wrote:
>
> > This is David's experience. It doesn't extrapolate to the industry.
>
> If I didn't make it clear, I have no inside information on the industry, I
> am
> operating from the point of view of a consumer useing the products and
> looking
> at how they are advertised and how they work in practice.
>
> My frustration is less with the product manufacturers than it is with the
> standards people. I don't expect a product manufacturer to test beyond
> 'does it
> meet the standard' (with some interoperability to see if everyone is
> interpreting the standard the same way)
>
> But the people drafting the standards (which may include some of the
> manufacturers), do need to be doing the more expensive and extensive
> testing for
> real-world conditions, not just the easier to test lab conditions. And
> that's
> where I don't see much progress over the years.
>
> If you live on a house with a 1 acre lot or larger, the current standards
> will
> work well for you. In a school or apartment building, there seems to be a
> lack
> of progress at the standards level (and therefor at the product level)
> from the
> time that the OLPC first attempted to do serious work in high density
> environments.
>
> David Lang
>
> > Our
> > testing as a component supplier is quite extensive. The level of math
> > required likely equals ML. The table stakes for a 2 BSS system with
> hidden
> > nodes, etc is $80K. That's just equipment. Then test engineers with deep
> > expertise of 802.11 have to be hired. And they have to continuously learn
> > as 802.11 is a living standard. And now they need to learn CCAs and
> network
> > marking planes. Then this all has to be paid for typically through
> > component sells as there are no software SKUs.
> >
> > The cadences for new ASICs is 24 months. The cadences for OSP upgrades is
> > 10 to 20 years.
> >
> > Of course testing is under funded. No stock b.s. to pay the bills. It has
> > to come from discounted cash flows.
> >
> > Everyone wants the experts to work for free. Iperf2 is that already. I
> > don't see any more freebies on the horizon.
> >
> > Bob
> >
> > On Sun, Sep 1, 2024, 10:05 PM David Lang via Make-wifi-fast <
> > make-wifi-fast@lists.bufferbloat.net> wrote:
> >
> >> On Sun, 1 Sep 2024, Hal Murray via Make-wifi-fast wrote:
> >>
> >>> David Lang said:
> >>>> It really doesn't help that everyone in the industry is pushing for
> >>>> higher  bandwidth for a single host. That's a nice benchmark number,
> but
> >>>> not really  relevant int he real world.
> >>>
> >>>> Even mu-mimo is of limited use as most routers only handle a handful
> of
> >>>> clients.
> >>>
> >>>> But the biggest problem is just the push to use wider channels and
> gain
> >>>> efficiency in long-running bulk transfers by bundling lots of IP
> packets
> >>>> into a  single transmission. This works well when you don't have
> >>>> congestion and have a  small number of clients. But when you have lots
> >> of
> >>>> clients, spanning many  generations of wifi technology, you need to go
> >> to
> >>>> narrower channels, but more  separate routers to maximize the fairness
> >> of
> >>>> available airtime.
> >>>
> >>> What does that say about the minimal collection of gear required in a
> >> test
> >>> lab?
> >>>
> >>> If you had a lab with plenty of gear, what tests would you run?
> >>
> >> I'll start off by saying that my experience is from practical
> in-the-field
> >> uses,
> >> deploying wifi to support thousands of users in a conference setting.
> It's
> >> possible that some people are doing the tests I describe below in their
> >> labs,
> >> but from the way routers and wifi standards are advertised and the
> guides
> >> to
> >> deploy them are written, it doesn't seem like they are.
> >>
> >> My belief is that most of the tests are done in relatively clean RF
> >> environments
> >> where only the devices on the test network exist, and they can always
> hear
> >> everyone on the network. In such environments, everything about existing
> >> wifi
> >> standards and the push for higher bandwidth channels makes a lot of
> sense
> >> (there
> >> are still some latency problems)
> >>
> >> But the world outside the lab is far more complex
> >>
> >> you need to simulate a dispursed, congested RF environment. This
> includes
> >> hidden
> >> transmitters (stations A-B-C where B can hear A and C but A and C cannot
> >> hear
> >> each other), dealing with weak signals (already covered), interactions
> of
> >> independent networks on the same channels (a-b and c-d that cannot talk
> to
> >> each
> >> other), legacy equipment on the network (as slow as 802.11g at least, if
> >> not
> >> 802.11b to simulate old IoT devices), and a mix of bulk-transfers
> >> (download/uploads), buffered streaming (constant traffic, but buffered
> so
> >> not
> >> super-sentitive to latency), unbuffered streaming (low bandwidth, but
> >> sensitive
> >> to latency), and short, latency sensitive traffic (things that block
> other
> >> traffic until they are answered, like DNS, http cache checks, http main
> >> pages
> >> that they pull lots of other URLs, etc)
> >>
> >> test large number of people in a given area (start with an all wireless
> >> office,
> >> then move on to classroom density), test not just one room, but multiple
> >> rooms
> >> that partially hear each other (the amount of attenuation or reflection
> >> between
> >> the rooms needs to vary). The ultimate density test would be a
> >> stadium-type
> >> setting where you have rows of chairs, but not tables and everyone is
> >> trying to
> >> livestream (or view a livestream) at once.
> >>
> >> Test not just the ultra-wide bandwidth with a single AP in the rooms,
> but
> >> narrower channels with multiple APs distributed around the rooms. Test
> APs
> >> positioned high, and set to high power to have large coverage areas
> >> against APs
> >> positioned low (signals get absorbed by people, so channels can be
> reused
> >> at
> >> shorter distances) and set to low power (microcell approach). Test APs
> >> overhead
> >> with directional antennas so they cover a small footprint.
> >>
> >> Test with different types of walls around/between the rooms, metal studs
> >> and
> >> sheetrock of a modern office have very little affect on signals,
> >> stone/brick
> >> walls of old buildings (and concrete walls in some areas of new
> buildings)
> >> absorb the signal, the metal grid in movable air walls blocks and
> reflects
> >> signals
> >>
> >> Remember that these are operating in 'unlicensed' spectrum, and so you
> can
> >> have
> >> other devices operating here as well causing periodic interference
> (which
> >> could
> >> show up as short segments of corruption or just an increased noise
> floor).
> >> Current wifi standards interpret any failed signals as a weak signal, so
> >> they
> >> drop down to a slower modulation or increasing power in the hope of
> >> getting the
> >> signal through. If the problem is actually interference from other
> devices
> >> (especially other APs that it can't decipher), the result is that all
> >> stations
> >> end up yelling slowly to try and get through and the result is very high
> >> levels
> >> of noise and no messages getting through. Somehow, the systems should
> >> detect
> >> that the noise floor is high and/or that there is other stuff happening
> on
> >> the
> >> network that they can hear, but not necessarily decipher and switch away
> >> from
> >> the 'weak signal' mode of operation (which is appropriate in sparse
> >> environments), and instead work to talk faster and at lower power to try
> >> and
> >> reduce the overall interference while still getting their signal
> through.
> >> (it does no good for one station to be transmitting at 3w while the
> >> station it's
> >> talking to is transmitting at 50mw). As far as I know, there is
> currently
> >> no way
> >> for stations to signal what power they are using (and the effective
> power
> >> would
> >> be modified by the antenna system, both transmitted and received), so
> this
> >> may
> >> be that something like 'I'm transmitting at 50% of my max and I hear you
> >> at 30%
> >> with noise at 10%' <-> 'I'm transmitting at 100% of my max and I hear
> you
> >> at 80%
> >> woth noise at 30%' could cause the first station to cut down on it's
> power
> >> until
> >> the two are hearing each other at similar levels (pure speculation here,
> >> suggestion for research ideas)
> >>
> >>> How many different tests would it take to give reasonable coverage?
> >>
> >> That's hard for me to say, and not every device needs to go through
> every
> >> test.
> >> But when working on a new standard, it needs to go through a lot of
> these
> >> tests,
> >> the most important ones IMHO are how they work with a high density of
> >> users
> >> accessing multiple routers which are distributed so there is overlapping
> >> coverage and include a mix of network traffic.
> >>
> >> David Lang
> >> _______________________________________________
> >> Make-wifi-fast mailing list
> >> Make-wifi-fast@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >
> >
>

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

[-- Attachment #1.2: Type: text/html, Size: 13184 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

Re: [Starlink] [Bloat] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[Michael Richardson]

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


David Lang via Bloat <bloat@lists.bufferbloat.net> wrote:
    > have a small number of clients. But when you have lots of clients, spanning
    > many generations of wifi technology, you need to go to narrower
    > channels, but

Like every single coffee shop and conference and hotel.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: [Starlink] [Make-wifi-fast] bloat on wifi8 and 802.11 wg

[Brandon Butterworth]

On 02/09/2024 03:59:43, "David Lang via Starlink" 
<starlink@lists.bufferbloat.net> wrote:
>It really doesn't help that everyone in the industry is pushing for higher bandwidth for a single host. That's a nice benchmark number, but not really relevant int he real world.

There may be some specific uses but it does seem to be mostly used
for selling bigger faster devices, they are also getting a lot more
expensive.

It is good that wifi gets faster and we got some more channels but
in typical congested areas it has been wasted on making wider channels
so each station can destroy more spectrum in one go and we are
back where we started - devices shouting over each other.

We run a WISP, 5GHz is a mess (more so with devices like Sky Q
making their own mesh clashing with existing wifi).

brandon