From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) (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 77D173B29D; Mon, 20 Mar 2023 17:28:36 -0400 (EDT) Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-544f7c176easo103015167b3.9; Mon, 20 Mar 2023 14:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679347716; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RKjBNh8gw0+ErHxRt4yTJlHkGAKO8xcrGFJ6yeFNOHc=; b=o8n+IojwrAPsLaerc9YJs52pBm5HBIybvpcBrxls6ugC5YbmM8q1KAhQbGothKXr4v 68EbWCY5jKil/lxd3v6KSh3YccDVE4XPWB3OSVF+E4wCMZxV6dvgDnwljPtZXOi6ta/h gFR9/U7vvG4mOMHe+Y1wAIMvkMdeKIeJK0NFMQtUzyIojlXF4aMJeMVGT60bsCxlKGWO tRGUf3BooK9G6cav28T4WoVsrDFYn4UDzBrgfyD2wr74e71uRAciLzt7rP+ulEeQUnGK jdFZLQriUXxBMG1c7Mzn7rqvSgn+iUpE2w/ZSKNgdLrJ1q2bd8oPAsG92/UI1RrdslOR 84fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679347716; h=cc: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=RKjBNh8gw0+ErHxRt4yTJlHkGAKO8xcrGFJ6yeFNOHc=; b=tG/johDuO304kScZZ4O7McbQq/RPFCRYMOKkRSOhUinM88vQwNpSO4hivUM/kIHm/8 5yJh5PFYR0RhhYjMChPsK1kWgaPJfaLxol4NfKaLTaA6pDS35FuPR8XtuOvW3dOjWIhH tIVUT88rhYtYKv0zE9ccTxQXBb9m7ev7tF6v1r5b12DvnxDLosfR6nxEGDdpyjlpnjOu UV9mOtHkKdJJ8lWfS6g0X4jq1OIZ8iotMwmYLh/PLCw2TZLVT/rH362w0ZIw4BAizadU xKJFkzv2uxERk4g7XrEQl+tteKjaQOoq+POHJYQMXDASY6GqNx//udMT7SJOwaJNb8cJ B6gg== X-Gm-Message-State: AO0yUKWK1xccokltjzUJfYmf3r5aeeNY1vw+fmRMCSpq+FIOtbwc7cHn MahQlXxtMCmzIvmTuD8Vh5O0R2vGOfVYjN7GKFM= X-Google-Smtp-Source: AK7set/Zg+iqrWRy2xl5I5RrDMCg/VMUmogFtJoHOOnC3DfIDIchn5uW0AmLdQ+ehZfaXcmCGCPtFA7gNRcoB/mnBQs= X-Received: by 2002:a81:4508:0:b0:541:6dce:50d6 with SMTP id s8-20020a814508000000b005416dce50d6mr10772765ywa.1.1679347715687; Mon, 20 Mar 2023 14:28:35 -0700 (PDT) MIME-Version: 1.0 References: <1672786712.106922180@apps.rackspace.com> <77CCAD19-07E0-4F9E-88C1-D207CF7BF376@cable.comcast.com> <83ffc0dad19e3343e49271889369cefc@rjmcmahon.com> <3CD0B9E6-0B2A-4A70-8F53-ED0822DF77A6@gmx.de> <13DE6E53-665F-4C20-BBE2-70E685421E9D@gmx.de> <22C819FA-DDD7-4B9B-8C09-8008D4273287@gmx.de> <5e7fac51071bdbb20837e72e7eedfc7c@rjmcmahon.com> <3f45d2a0b6e46d7b2775fb801e805f93@rjmcmahon.com> <70F71290-C6CB-4D19-8A88-F0F17C0BDDA2@gmx.de> <5e0cd693c4749d128dbb48d6c1129071@rjmcmahon.com> <2ab2983d-6beb-49cb-8c35-e481cbfdc7a3@Spark> <8F56CCA3-61C4-475F-975D-99D851C6A7CF@gmx.de> <1d6c10c9a692bb3f2869fb1b40fa449a@rjmcmahon.com> <005d1e7e3e1d19bce308436e46a3ec5e@rjmcmahon.com> <569691b3e7dfc57bbf98c4fc168fc6cf@rjmcmahon.com> <2885829.1679221616@dyas> In-Reply-To: From: dan Date: Mon, 20 Mar 2023 15:28:57 -0600 Message-ID: To: Frantisek Borsik Cc: rjmcmahon , Rpm , libreqos , Dave Taht via Starlink , bloat , Michael Richardson Content-Type: multipart/alternative; boundary="0000000000000c4a2805f75b9cd7" Subject: Re: [Rpm] [Starlink] [LibreQoS] On FiWi X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2023 21:28:36 -0000 --0000000000000c4a2805f75b9cd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I more or less agree with you Frantisek. There are throughput numbers that are need for current gen and next gen services, but those are often met with 50-100Mbps plans today that are enough to handle multiple 4K streams plus browsing and so forth, yet no one talks about latency and packet loss and other useful metrics at all and consumers are not able to and never will be able to understand more that a couple of numbers. This is an industry problem and unless we have some sort of working group that is pushing this like the 'got milk?' advertisements I'm not sure how we will ever get there. The big vendors that have pushed docsis to extremes have no interest in these other details, they win on the big 'speed' number and will advertising all sorts of performance around that number. We need a marketing/lobby group. Not wispa or other individual industry groups, but one specifically for *ISPs that will contribute as well as implement policies and put that out on social media etc etc. i don't know how we get there without a big player (ie Netflix, hulu..) contributing. On Mon, Mar 20, 2023 at 2:46=E2=80=AFPM Frantisek Borsik wrote: > > Late to the party, also not an engineer...but if there's something I have > learned during my time with RF elements: > > --- 99% of the vendors out there (and most of the ISPs, I dare to say, as > well) don't know/care/respect thing as "simple", as physics. > > --- 2.4GHz was lost because of this, and 5GHz was saved like "5 minutes t= o > midnight" for ISPs, by RF elements Horns (and UltraHorns, UltraDish, > Asymmetrical Horns later on), basically, that have inspired ("Imitation i= s > the sincerest form of flattery that mediocrity can pay to greatness." Osc= ar > Wilde) some other vendors of the antennas to bring their own version of > Horns etc. > > --- sure, lot of improvements in order to fight noise, modulate, > virtualise (like Tarana Wireless) were done on the AP (radio) side, but > still - physics is physics and it was overlooked and neglected for such a > LONG time. > > --- ISPs were told by the vendors to basically BLAST through the noise an= d > many more BS like this. So they did as they were told, they were blasting > and blasting. Those that were getting smarter, switched to RF elements > Horns, stopped blasting, started to being reasonable with topology ("if > Your customers are 5 miles away from the AP, You will not blast like craz= y > for 10 miles, because You will pick up all the noise") and they even > started to cooperate - frequency coordination, colocation - with other IS= Ps > on the same towers etc (the same co-ordination needs to be done between t= he > ISP behind the CPEs now - on the Wi-Fi routers of their customers.) > > The similar development I was able to see when I got into Wi-Fi (while at > TurrisTech - secure, > powerful open source Wi-Fi routers). The same story, basically, for vendo= rs > as well as ISPs. No actual respect for the underlying physics, attempts t= o > blast-over the noise, chasing clouds ("muah WiFi 6, 6E....oh no, here com= es > Wi-Fi 7 and this will change EVERYTHING ---> see, it was a lot of "fun" t= o > see this happening with 5G, and the amount of over-promise and > under-delivery BS was and even still is, staggering.) > The whole Wi-Fi industry is chasing (almost) empty numbers (bandwidth) > instead of focusing on bufferbloat (latency, jitter...). > Thanks to Domos for putting together the Understanding Latency webinar > series. I know that most of You are aware of latency as the most importan= t > metric we should focus on nowadays in order to improve the overall Intern= et > experience, but still... > About 6 hours watch of watching. And rewatching: > https://www.youtube.com/watch?v=3DKdTPz5srJ8M > https://www.youtube.com/watch?v=3DtAVwmUG21OY > https://www.youtube.com/watch?v=3DMRmcWyIVXvg > > Also, there is one more thing to add re Wi-Fi. If You can cable, You > should always cable. Mesh as we know it, would be a way better Wi-Fi > enhancement, if the mesh units would be wired as much as possible. We wil= l > reduce the noice, grow smart and save spectrum. > > Thanks for the great discussion. > > 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 Sun, Mar 19, 2023 at 11:27=E2=80=AFAM Michael Richardson via Rpm < > rpm@lists.bufferbloat.net> wrote: > >> >> {lots of lists on the CC} >> >> The problem I have with lorawan is that it's too small for anything but >> the >> smallest sensors. When it breaks (due to infant death or just vanadalis= m) >> who is going to notice enough to fix it? My belief is that people won't >> break things that they like/depend upon. Or at least, that there will b= e >> social pressure not to. >> >> Better to have a protected 1Mb/s sensor lan within a 144Mb/s wifi than a >> adjacent lorawan. >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- *I*LIKE*TRAINS* >> >> >> >> _______________________________________________ >> Rpm mailing list >> Rpm@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/rpm >> > --0000000000000c4a2805f75b9cd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I more or less agree with you Frantisek.=C2=A0 =C2=A0There= are throughput numbers that are need for current gen and next gen services= , but those are often met with 50-100Mbps plans today that are enough to ha= ndle multiple 4K streams plus browsing and so forth, yet no one talks about= latency and packet loss and other useful metrics at all and consumers are = not able to and never will be able to understand more that a couple of numb= ers.=C2=A0 This is an industry problem and unless we have some sort of work= ing group that is pushing this like the 'got milk?' advertisements = I'm not sure how we will ever get there.=C2=A0 The big vendors that hav= e pushed docsis to extremes have no interest in these other details, they w= in on the big 'speed' number and will advertising all sorts of perf= ormance around that number.

We need a marketing/lobby group.=C2=A0 N= ot wispa or other individual=C2=A0industry groups, but one specifically for= *ISPs that will contribute as well as implement policies and put that out = on social media etc etc.=C2=A0 i don't know how we get there without a = big player (ie Netflix, hulu..) contributing.

On Mon, Mar 20, 2023 at 2:46= =E2=80=AFPM Frantisek Borsik <frantisek.borsik@gmail.com> wrote:

Late to the party, also not an engineer...but if there's something I= have learned during my time with RF elements:

---= 99% of the vendors out there (and most of the ISPs, I dare to say, as well= ) don't know/care/respect thing as "simple", as physics.
=C2=A0
--- 2.4GHz was lost because of this, and 5GHz was sa= ved like "5 minutes to midnight" for ISPs, by RF elements Horns (= and UltraHorns, UltraDish, Asymmetrical Horns later on), basically, that ha= ve inspired ("Imitation is the sincerest form of flattery that mediocr= ity can pay to greatness." Oscar Wilde) some other vendors of the ante= nnas to bring their own version of Horns etc.=C2=A0

--- sure, lot of improvements in order to fight noise, modulate, virtuali= se (like Tarana Wireless) were done on the AP (radio) side, but still - phy= sics is physics and it was overlooked and neglected for such a LONG time.

--- ISPs were told by the vendors to basically BLAS= T through the noise and many more BS like this. So they did as they were to= ld, they were blasting and blasting. Those that were getting smarter, switc= hed to RF elements Horns, stopped blasting, started to being reasonable wit= h topology ("if Your customers are 5 miles away from the AP, You will = not blast like crazy for 10 miles, because You will pick up all the noise&q= uot;) and they even started to cooperate - frequency coordination, colocati= on - with other ISPs on the same towers etc (the same co-ordination needs t= o be done between the ISP behind the CPEs now - on the Wi-Fi routers of the= ir customers.)

The similar development I was able = to see when I got into Wi-Fi (while at TurrisTech - secure, powerful = open source Wi-Fi routers). The same story, basically, for vendors as well = as ISPs. No actual respect for the underlying physics, attempts to blast-ov= er the noise, chasing clouds ("muah WiFi 6, 6E....oh no, here comes Wi= -Fi 7 and this will change EVERYTHING ---> see, it was a lot of "fu= n" to see this happening with 5G, and the amount of over-promise and u= nder-delivery BS was and even still is, staggering.)
The whole Wi= -Fi industry is chasing (almost) empty numbers (bandwidth) instead of focus= ing on bufferbloat (latency, jitter...).
Thanks to Domos for putt= ing together the Understanding Latency webinar series. I know that most of = You are aware of latency as the most important metric we should focus on no= wadays in order to improve the overall Internet experience, but still...
About 6 hours watch of watching. And rewatching:

Also, there is one more th= ing to add re Wi-Fi. If You can cable, You should always cable. Mesh as we = know it, would be a way better Wi-Fi enhancement, if the mesh units would b= e wired as much as possible. We will reduce the noice, grow smart and save = spectrum.

Thanks for the great discussion.

All the best,

Frank

Frantisek (Frank) Borsik

<= p class=3D"MsoNormal" style=3D"color:rgb(34,34,34)">=C2=A0

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

<= p class=3D"MsoNormal" style=3D"color:rgb(34,34,34)">Signal, Telegram, Whats= App: +421919416714=C2=A0

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com



On Sun, Mar 19, 2023 at 11:27=E2=80=AFA= M Michael Richardson via Rpm <rpm@lists.bufferbloat.net> wrote:

{lots of lists on the CC}

The problem I have with lorawan is that it's too small for anything but= the
smallest sensors.=C2=A0 When it breaks (due to infant death or just vanadal= ism)
who is going to notice enough to fix it?=C2=A0 My belief is that people won= 't
break things that they like/depend upon.=C2=A0 Or at least, that there will= be
social pressure not to.

Better to have a protected 1Mb/s sensor lan within a 144Mb/s wifi than a adjacent lorawan.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *I*LIKE*TRAINS*



_______________________________________________
Rpm mailing list
Rpm@lists.bu= fferbloat.net
https://lists.bufferbloat.net/listinfo/rpm
--0000000000000c4a2805f75b9cd7--