From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 839753B29E; Mon, 2 Sep 2024 13:31:58 -0400 (EDT) Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6bf90d52e79so23865856d6.3; Mon, 02 Sep 2024 10:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725298318; x=1725903118; darn=lists.bufferbloat.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=7acoitfagCRjr6GwOH3Z9WjndU1D9Lleoa7A04SWZzs=; b=VC0kxvNTiDPAeh9zw3W3CqkjJRb+8rNz3R8pha78ADOxpa3cP24K7IB0YKG/u34kRH MOAk4XJqmSwy89jeLVYKY0IOoiQ9j6MxLDmXdZKIWZKju4RQpDTTSubuvaiG11QqGELt 9VX8xgdyavoGilzAkLXz8b6v6ADk6IO75hvaYgs5Gc4ZUX4VvZgvf1sdYwuNFaVLxjVz Inz8XR54nwGSqN9z1wGKj6TxeZdVABp3b/+DPZ2bAKlVDQPRBJbPxg2KiRqZQ5AZ/TNv Jx/xax6J0UqmHYI3H3PRvu2DJ7/Akx/jtUfvEftmiubx1GmGQsFcF9aBo3qxo3q5yD9H 9wIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725298318; x=1725903118; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7acoitfagCRjr6GwOH3Z9WjndU1D9Lleoa7A04SWZzs=; b=UWvppFidcyS+bxShYG7fn2kVt8XY+bj06iFZu7Dllm21qc7OtFJ4s2AcLG5sAbZ1Ee Qz+Cv1OS4BINnCLbCExxgD5EXQUoy2VqZcj7BTmONf41Y2YS9FPDDVJmxITSfUR8jroo ttIDGWS5UAz8tshG9dER27hFEyK/dB839iYXaew/+dvi4gnwD5QrV00mywK2Tt/MdcET 6ebWE5MUgBqF6s+6CRg7WhxQeSpo9X2Q4DlRzkUsC3ch7tNGv/8O0WAqNXXbK47p23Qk KTjA9KFbqMmHNe18pCKyYHHszsiwsJPuML+JDYH/S++0x62T/0GIEyYNut6eWrUWjyEU +97Q== X-Forwarded-Encrypted: i=1; AJvYcCVIz7KVkT5r+udW1W7o5Ift6q0PXNvbqkupcT1OV5u2Fk5p0sb4Rmop+e5XBKhHVnqzwrvodr4SnBkxRK5JrLQ=@lists.bufferbloat.net, AJvYcCXmX7YrlaoQ/4mHLRAOzW4nuktd95WKUFN+W7cOXcSAJmKTPpkx8RGIVYbJxyoBtD5N6CCFIw==@lists.bufferbloat.net X-Gm-Message-State: AOJu0YxTAdYJMeALaaqfA/oxE91fYht7BGiG72Crs+loHAZdJiFia5k7 DyC1rVrFImJXKjFGGK/x4M0MteUY4wu2A+6QVOPL6IRsIuyy2PZO1746lLZQlF3SfeglP+sLI8V Ai3ncKyQ+s1hTD462+NtI9y9cG36DXG38 X-Google-Smtp-Source: AGHT+IHegQOQOoUddzBatrUuvqI7FNt2NtpRVjTNVQzjg3mYGZ+WBlaiuDnYWqGWNMGz8VMYDV0urND0TFosT/NLF2Y= X-Received: by 2002:a0c:f411:0:b0:6b5:e60c:76dc with SMTP id 6a1803df08f44-6c3c619ec32mr7063046d6.19.1725298317699; Mon, 02 Sep 2024 10:31:57 -0700 (PDT) MIME-Version: 1.0 References: <20240902042024.8A7E3620054@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <13so850r-s23q-r0sp-0nqp-ss9q2q522542@ynat.uz> In-Reply-To: From: Frantisek Borsik Date: Mon, 2 Sep 2024 19:31:21 +0200 Message-ID: To: Starlink , Make-Wifi-fast , bloat Content-Type: multipart/alternative; boundary="0000000000005bb64b0621265198" Subject: Re: [Bloat] [Make-wifi-fast] [Starlink] bloat on wifi8 and 802.11 wg X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2024 17:31:58 -0000 --0000000000005bb64b0621265198 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-fac= es-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-scene= s-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=E2=80=AFPM 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 hidde= n > 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 netwo= rk > 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 ga= in >> >> 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 lot= s >> of >> >> clients, spanning many generations of wifi technology, you need to g= o >> to >> >> narrower channels, but more separate routers to maximize the fairnes= s >> 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 guide= s >> 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 sens= e >> (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 include= s >> 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 o= f >> 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 s= o >> 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, bu= t >> 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 reuse= d >> 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 (whic= h >> 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 currentl= y >> no way >> for stations to signal what power they are using (and the effective powe= r >> 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 yo= u >> 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 ever= y >> test. >> But when working on a new standard, it needs to go through a lot of thes= e >> 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 an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > 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 > --0000000000005bb64b0621265198 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
All the best,

Frank<= /p>

<= p class=3D"MsoNormal" style=3D"color:rgb(34,34,34)">Frantisek (Frank) Borsi= k

= =C2=A0

<= a href=3D"https://www.linkedin.com/in/frantisekborsik" style=3D"color:rgb(1= 7,85,204)" target=3D"_blank">https://www.linkedin.com/in/frantisekborsik

Sig= nal, Telegram, WhatsApp: +421919416714=C2=A0

iMessage, mobile: +420775230885<= /u>

Skype: c= asioa5302ca

frantisek.borsik@gmail.com


<= br>
On Mon,= Sep 2, 2024 at 7:29=E2=80=AFPM Bob McMahon via Bloat <bloat@lists.bufferbloat.net> wrote:
This is David's experience. I= t doesn't extrapolate to the industry. Our testing as a component suppl= ier is quite extensive. The level of math required likely equals ML. The ta= ble stakes for a 2 BSS system with hidden nodes, etc is $80K. That's ju= st 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 h= as to be paid for typically through component sells as there are no softwar= e SKUs.=C2=A0

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

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

Everyone wan= ts the experts to work for free. Iperf2 is that already. I don't see an= y more freebies on the horizon.
Bob

On Sun, Sep 1, 2024, 10:05 P= M David Lang via Make-wifi-fast <make-wifi-fast@lists.bufferbloat.net= > wrote:
On Sun, 1 Sep 2024, Hal Murray via Ma= ke-wifi-fast wrote:

> David Lang said:
>> It really doesn't help that everyone in the industry is pushin= g for
>> higher=C2=A0 bandwidth for a single host. That's a nice benchm= ark number, but
>> not really=C2=A0 relevant int he real world.
>
>> Even mu-mimo is of limited use as most routers only handle a handf= ul 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 p= ackets
>> into a=C2=A0 single transmission. This works well when you don'= ;t have
>> congestion and have a=C2=A0 small number of clients. But when you = have lots of
>> clients, spanning many=C2=A0 generations of wifi technology, you n= eed to go to
>> narrower channels, but more=C2=A0 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-fi= eld uses,
deploying wifi to support thousands of users in a conference setting. It= 9;s
possible that some people are doing the tests I describe below in their lab= s,
but from the way routers and wifi standards are advertised and the guides t= o
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 environ= ments
where only the devices on the test network exist, and they can always hear =
everyone on the network. In such environments, everything about existing wi= fi
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 h= idden
transmitters (stations A-B-C where B can hear A and C but A and C cannot he= ar
each other), dealing with weak signals (already covered), interactions of <= br> 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 no= t
802.11b to simulate old IoT devices), and a mix of bulk-transfers
(download/uploads), buffered streaming (constant traffic, but buffered so n= ot
super-sentitive to latency), unbuffered streaming (low bandwidth, but sensi= tive
to latency), and short, latency sensitive traffic (things that block other =
traffic until they are answered, like DNS, http cache checks, http main pag= es
that they pull lots of other URLs, etc)

test large number of people in a given area (start with an all wireless off= ice,
then move on to classroom density), test not just one room, but multiple ro= oms
that partially hear each other (the amount of attenuation or reflection bet= ween
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 tryin= g to
livestream (or view a livestream) at once.

Test not just the ultra-wide bandwidth with a single AP in the rooms, but <= br> 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 a= t
shorter distances) and set to low power (microcell approach). Test APs over= head
with directional antennas so they cover a small footprint.

Test with different types of walls around/between the rooms, metal studs an= d
sheetrock of a modern office have very little affect on signals, stone/bric= k
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 c= ould
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 th= ey
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 s= tations
end up yelling slowly to try and get through and the result is very high le= vels
of noise and no messages getting through. Somehow, the systems should detec= t
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 fr= om
the 'weak signal' mode of operation (which is appropriate in sparse=
environments), and instead work to talk faster and at lower power to try an= d
reduce the overall interference while still getting their signal through. <= br> (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 n= o way
for stations to signal what power they are using (and the effective power w= ould
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 hea= r you at 30%
with noise at 10%' <-> 'I'm transmitting at 100% of my ma= x 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 eve= ry test.
But when working on a new standard, it needs to go through a lot of these t= ests,
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/listin= fo/make-wifi-fast

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly 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@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--0000000000005bb64b0621265198--