From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 DFAD53CB37; Mon, 20 Mar 2023 17:39:06 -0400 (EDT) Received: by mail-qk1-x736.google.com with SMTP id u9so1258792qkp.8; Mon, 20 Mar 2023 14:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679348346; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PQjEZtkBXlb7QUNnGXJxJkialTyDeAmKpsC17LZ1Fs0=; b=fVfjG7CJhjveFexGY1+sXXMFEiF/xvZYX5zIWpQBT5cD357z+DL2hVeP25NCc1vyzg deQuzt3gI1v84YJZ4OG94XFJG7ZJIKTgLjhhI7SLB1hOETPacDvxZMSNxwQgYxFnXX2a C8YxGGE4xmIybUSrQaVqORzQyTzjrjH8NV528auvxqvddBHnXoc9Hlmk8hnMe8mAv1Tx 9cFeXglnMWLIWQtTmWiNdyK12h6rDcDYRvrDAOmWdeR/YI8DGluy9SPkT9pnPwQUc4b8 JmnmjYi9W7VpE+W2L11mp3Ey8ml2VCtIllLf+qZ2PfwLfajgkFpFUpGXZht+WfO2j0Qq +QNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679348346; 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=PQjEZtkBXlb7QUNnGXJxJkialTyDeAmKpsC17LZ1Fs0=; b=TtjMnFNMCB1oFMIMT9vHES3LFqGsuOUK4kX6DZe/WaMGDPB4YnghhnBYEBgIRN3IIH 0ygQoZqxUJjGa4xHOAyrZn6TOh2J/5wLDMfQzTu6MZ7dIPm6xxOSTSJPdtWwOn99hcPG Mpbvk/jupUKuo+/bD3gbUJbFxuDG2nx+X3f2CgrIfy/bV0FO8uJ6afMs5OgXFS9X8Mah fI+uLCv5mJ0RUY5GHPunBs/3j0QeO4H43ljaeIwBooZQunU8i2KFcfUhe9PStzVlmaLJ itOaNusBuw5VJXyXHKNE6K81RPMCkASXLcJK1711ZHQKUNxY1JWXgDNfLqWnxIfgsGL5 MbRw== X-Gm-Message-State: AO0yUKW/6VUzMoikAxLUYsTbz4lVF8BmBoOrjECbrO0+2EUQP8rA6k3J zgNdpvg3ApOeOsuigSUwJ6eMYqsmSR9M2bz04OI= X-Google-Smtp-Source: AK7set9K6FbGbUWYRciurSvTgPr12kWSiHaIc0NNbLKJYb+BMCo3MWn/onUISw9gRJ8XbNXu4tj9tyK1/zH5ZrGWqSU= X-Received: by 2002:a37:a9c6:0:b0:746:7a11:b224 with SMTP id s189-20020a37a9c6000000b007467a11b224mr85139qke.12.1679348346175; Mon, 20 Mar 2023 14:39:06 -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: Frantisek Borsik Date: Mon, 20 Mar 2023 22:38:29 +0100 Message-ID: To: dan Cc: rjmcmahon , Rpm , libreqos , Dave Taht via Starlink , bloat , Michael Richardson Content-Type: multipart/alternative; boundary="000000000000a0c34105f75bc148" X-Mailman-Approved-At: Mon, 20 Mar 2023 20:22:18 -0400 Subject: Re: [LibreQoS] [Rpm] [Starlink] On FiWi X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2023 21:39:07 -0000 --000000000000a0c34105f75bc148 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Dan. So we got here, but how to get out of this craziness. The question is what (if anything) we can actually learn from the very beginning of the Internet. If I remember correctly, there was as part of this discussion here (or in the other thread) on IP vs LoRaWAN. Can we use something from the good ole IP frame work that would help us to do this? Also, is it even possible at all? Btw, here is a good example of explaining, learning of the performance (latency, jitter, bufferbloat) side of the Internet, shared with the customers by Robert, the guy behind the beginning of LibreQoS: https://jackrabbitwireless.com/performance/ Great inspiration. 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, Mar 20, 2023 at 10:28=E2=80=AFPM dan wrote: > 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' numb= er > 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 kno= w > 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 hav= e >> learned during my time with RF elements: >> >> --- 99% of the vendors out there (and most of the ISPs, I dare to say, a= s >> 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 >> to midnight" for ISPs, by RF elements Horns (and UltraHorns, UltraDish, >> Asymmetrical Horns later on), basically, that have inspired ("Imitation = is >> the sincerest form of flattery that mediocrity can pay to greatness." Os= car >> 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 >> and 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 topol= ogy >> ("if Your customers are 5 miles away from the AP, You will not blast lik= e >> crazy for 10 miles, because You will pick up all the noise") and they ev= en >> started to cooperate - frequency coordination, colocation - with other I= SPs >> on the same towers etc (the same co-ordination needs to be done between = the >> 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 a= t >> TurrisTech - secure, >> powerful open source Wi-Fi routers). The same story, basically, for vend= ors >> as well as ISPs. No actual respect for the underlying physics, attempts = to >> blast-over the noise, chasing clouds ("muah WiFi 6, 6E....oh no, here co= mes >> Wi-Fi 7 and this will change EVERYTHING ---> see, it was a lot of "fun" = to >> 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 importa= nt >> metric we should focus on nowadays in order to improve the overall Inter= net >> 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 wi= ll >> 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 >>> vanadalism) >>> 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 = 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 , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- *I*LIKE*TRAINS* >>> >>> >>> >>> _______________________________________________ >>> Rpm mailing list >>> Rpm@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/rpm >>> >> --000000000000a0c34105f75bc148 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Dan. So we got here, but how to get out of this cr= aziness.=C2=A0
The question is what (if anything) =C2=A0we can actually= learn from the very beginning of the Internet. If I remember correctly, th= ere was as part of this discussion here (or in the other thread) on IP vs L= oRaWAN.
Can we use something from the good ole IP frame work that= would help us to do this?
Also, is it even possible at all?

Btw, here is a good example of explaining, learning of= the performance (latency, jitter, bufferbloat) side of the Internet, share= d with the customers by Robert, the guy behind the beginning of LibreQoS:= =C2=A0https://jackr= abbitwireless.com/performance/
Great inspiration.
<= br>
All the best,

Frank

Frantisek (Frank) Borsik

=C2=A0=

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

Signal, Teleg= ram, WhatsApp: +421919416714=C2=A0

iMessage, mobile: +420775230885=

Skype: casioa5302c= a

frantisek.borsik@gmail.com

=


On Mo= n, Mar 20, 2023 at 10:28=E2=80=AFPM dan <dandenson@gmail.com> wrote:
I more or less agree with you Frantisek.=C2=A0 =C2=A0There are t= hroughput 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 m= ultiple 4K streams plus browsing and so forth, yet no one talks about laten= cy and packet loss and other useful metrics at all and consumers are not ab= le to and never will be able to understand more that a couple of numbers.= =C2=A0 This is an industry problem and unless we have some sort of working = group that is pushing this like the 'got milk?' advertisements I= 9;m not sure how we will ever get there.=C2=A0 The big vendors that have pu= shed docsis to extremes have no interest in these other details, they win o= n the big 'speed' number and will advertising all sorts of performa= nce around that number.

We need a marketing/lobby group.=C2=A0 Not w= ispa or other individual=C2=A0industry groups, but one specifically for *IS= Ps that will contribute as well as implement policies and put that out on s= ocial 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/car= e/respect thing as "simple", as physics.
=C2=A0
--- 2.4GHz was lost because of this, and 5GHz was saved like "5 min= utes to midnight" for ISPs, by RF elements Horns (and UltraHorns, Ultr= aDish, Asymmetrical Horns later on), basically, that have inspired ("I= mitation is the sincerest form of flattery that mediocrity can pay to great= ness." Oscar Wilde) some other vendors of the antennas to bring their = own version of Horns etc.=C2=A0

--- sure, lot of i= mprovements in order to fight noise, modulate, virtualise (like Tarana Wire= less) were done on the AP (radio) side, but still - physics is physics and = it was overlooked and neglected for such a LONG time.

<= div>--- ISPs were told by the vendors to basically BLAST through the noise = and many more BS like this. So they did as they were told, they were blasti= ng and blasting. Those that were getting smarter, switched to RF elements H= orns, stopped blasting, started to being reasonable with 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") and they even = started to cooperate - frequency coordination, colocation - with other ISPs= on the same towers etc (the same co-ordination needs to be done between th= e ISP behind the CPEs now - on the Wi-Fi routers of their customers.)
=

The similar development I was able to see when I got in= to Wi-Fi (while at TurrisTech - secure, powerful open source Wi-Fi ro= uters). The same story, basically, for vendors as well as ISPs. No actual r= espect for the underlying physics, attempts to blast-over the noise, chasin= g clouds ("muah WiFi 6, 6E....oh no, here comes Wi-Fi 7 and this will = change EVERYTHING ---> see, it was a lot of "fun" to 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 chas= ing (almost) empty numbers (bandwidth) instead of focusing on bufferbloat (= latency, jitter...).
Thanks to Domos for putting together the Und= erstanding Latency webinar series. I know that most of You are aware of lat= ency as the most important metric we should focus on nowadays in order to i= mprove the overall Internet experience, but still...
About 6 hour= s watch of watching. And rewatching:

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 w= ay better Wi-Fi enhancement, if the mesh units would be wired as much as po= ssible. We will reduce the noice, grow smart and save spectrum.
<= br>
Thanks for the great discussion.

All= the best,

Frank

Frantisek (Frank) Borsik

=C2=A0

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

Signal, Telegram, WhatsApp: +421919416714=C2= =A0

i= Message, mobile: +420775230885

Skype: casioa5302ca

frantisek.bors= ik@gmail.com

<= /div>


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.=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
--000000000000a0c34105f75bc148--