Re: [Starlink] It’s the Latency, FCC

Re: [Starlink] It’s the Latency, FCC

[Colin_Higbie]

Gene,

I think the lion's share of other people (many brilliant people here) on this thread are focused on keeping latency down when under load. I generally just read and don't contribute on those discussions, because that's not my area of expertise. I only posted my point on bandwidth, not to detract from the importance of reducing latency, but to correct what I believed to be an important error on minimum bandwidth required to be able to perform standard Internet functions. 

To my surprise, there was pushback on the figure, so I've responded to try to educate this group on streaming usage in the hope that the people working on the latency problem under load (core reason for this group to exist) can also be aware of the minimum bandwidth needs to ensure they don't plan based on bad assumptions.

For a single user, minimum bandwidth (independent of latency) needs to be at least 25Mbps assuming the goal is to provide access to all standard Internet services. Anything short of that will deny users access to the primary streaming services, and more specifically won't be able to watch 4K HDR video, which is the market standard for streaming services today and likely will remain at that level for the next several years.

I think it's fine to offer lower-cost options that don't deliver 4K HDR video (not everyone cares about that), but at least 25Mbps should be available to an Internet customer for any new Internet service rollout.

Cheers,
Colin


-----Original Message-----
From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of starlink-request@lists.bufferbloat.net
Sent: Tuesday, April 30, 2024 3:05 PM
To: starlink@lists.bufferbloat.net
Subject: Starlink Digest, Vol 37, Issue 15


----------------------------------------------------------------------

Message: 1
Date: Tue, 30 Apr 2024 09:04:43 -1000
From: Eugene Y Chang <eugene.chang@ieee.org>
To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
	<starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] It’s the Latency, FCC
Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
Content-Type: text/plain; charset="utf-8"

I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.

While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.

With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)

How can we deliver graceful performance to both persons in a household?
Is seeking graceful performance too complicated to improve?
(I said “graceful” to allow technical flexibility.)

Gene
----------------------------------------------
Eugene Chang

Re: [Starlink] It’s the Latency, FCC

[Eugene Y Chang]

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

Colin,
I am overwhelmed with all the reasons that prevent low(er) or consistent latency.
I think that our best ISP offerings should deliver graceful, agile, or nimble service. Sure, handle all the high-volume data. The high-volume service just shouldn’t preclude graceful service. Yes, the current ISP practices fall short. Can we help them improve their service?

Am I asking too much?

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member




> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> Gene,
> 
> I think the lion's share of other people (many brilliant people here) on this thread are focused on keeping latency down when under load. I generally just read and don't contribute on those discussions, because that's not my area of expertise. I only posted my point on bandwidth, not to detract from the importance of reducing latency, but to correct what I believed to be an important error on minimum bandwidth required to be able to perform standard Internet functions.
> 
> To my surprise, there was pushback on the figure, so I've responded to try to educate this group on streaming usage in the hope that the people working on the latency problem under load (core reason for this group to exist) can also be aware of the minimum bandwidth needs to ensure they don't plan based on bad assumptions.
> 
> For a single user, minimum bandwidth (independent of latency) needs to be at least 25Mbps assuming the goal is to provide access to all standard Internet services. Anything short of that will deny users access to the primary streaming services, and more specifically won't be able to watch 4K HDR video, which is the market standard for streaming services today and likely will remain at that level for the next several years.
> 
> I think it's fine to offer lower-cost options that don't deliver 4K HDR video (not everyone cares about that), but at least 25Mbps should be available to an Internet customer for any new Internet service rollout.
> 
> Cheers,
> Colin
> 
> 
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of starlink-request@lists.bufferbloat.net
> Sent: Tuesday, April 30, 2024 3:05 PM
> To: starlink@lists.bufferbloat.net
> Subject: Starlink Digest, Vol 37, Issue 15
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 30 Apr 2024 09:04:43 -1000
> From: Eugene Y Chang <eugene.chang@ieee.org>
> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
> 	<starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] It’s the Latency, FCC
> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
> Content-Type: text/plain; charset="utf-8"
> 
> I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.
> 
> While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.
> 
> With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)
> 
> How can we deliver graceful performance to both persons in a household?
> Is seeking graceful performance too complicated to improve?
> (I said “graceful” to allow technical flexibility.)
> 
> Gene
> ----------------------------------------------
> Eugene Chang
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Starlink] It’s the Latency, FCC

[Dave Taht]

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

Just fq codel or cake everything and you get all that.

Libreqos is free software for those that do not want to update their data
plane. Perhaps we should do a public demo of what it can do for every tech
on the planet. Dsl benefits, fiber does also (but it is the stats that
matter more on fiber because the customer wifi becomes bloated)

Starlink merely fq codeled their wifi and did some aqm work (not codel I
think) to get the amazing results they are getting today. I don't have the
waveform test results handy but they are amazing. I feel a sea change in
the wind...



On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Colin,
> I am overwhelmed with all the reasons that prevent low(er) or consistent
> latency.
> I think that our best ISP offerings should deliver graceful, agile, or
> nimble service. Sure, handle all the high-volume data. The high-volume
> service just shouldn’t preclude graceful service. Yes, the current ISP
> practices fall short. Can we help them improve their service?
>
> Am I asking too much?
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
>
>
>
>
> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
> Gene,
>
> I think the lion's share of other people (many brilliant people here) on
> this thread are focused on keeping latency down when under load. I
> generally just read and don't contribute on those discussions, because
> that's not my area of expertise. I only posted my point on bandwidth, not
> to detract from the importance of reducing latency, but to correct what I
> believed to be an important error on minimum bandwidth required to be able
> to perform standard Internet functions.
>
> To my surprise, there was pushback on the figure, so I've responded to try
> to educate this group on streaming usage in the hope that the people
> working on the latency problem under load (core reason for this group to
> exist) can also be aware of the minimum bandwidth needs to ensure they
> don't plan based on bad assumptions.
>
> For a single user, minimum bandwidth (independent of latency) needs to be
> at least 25Mbps assuming the goal is to provide access to all standard
> Internet services. Anything short of that will deny users access to the
> primary streaming services, and more specifically won't be able to watch 4K
> HDR video, which is the market standard for streaming services today and
> likely will remain at that level for the next several years.
>
> I think it's fine to offer lower-cost options that don't deliver 4K HDR
> video (not everyone cares about that), but at least 25Mbps should be
> available to an Internet customer for any new Internet service rollout.
>
> Cheers,
> Colin
>
>
> -----Original Message-----
> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
> starlink-request@lists.bufferbloat.net
> Sent: Tuesday, April 30, 2024 3:05 PM
> To: starlink@lists.bufferbloat.net
> Subject: Starlink Digest, Vol 37, Issue 15
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 30 Apr 2024 09:04:43 -1000
> From: Eugene Y Chang <eugene.chang@ieee.org>
> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
> <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] It’s the Latency, FCC
> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
> Content-Type: text/plain; charset="utf-8"
>
> I am always surprised how complicated these discussions become. (Surprised
> mostly because I forgot the kind of issues this community care about.) The
> discussion doesn’t shed light on the following scenarios.
>
> While watching stream content, activating controls needed to switch
> content sometimes (often?) have long pauses. I attribute that to buffer
> bloat and high latency.
>
> With a happy household user watching streaming media, a second user could
> have terrible shopping experience with Amazon. The interactive response
> could be (is often) horrible. (Personally, I would be doing email and
> working on a shared doc. The Amazon analogy probably applies to more
> people.)
>
> How can we deliver graceful performance to both persons in a household?
> Is seeking graceful performance too complicated to improve?
> (I said “graceful” to allow technical flexibility.)
>
> Gene
> ----------------------------------------------
> Eugene Chang
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

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

Re: [Starlink] It’s the Latency, FCC

[Frantisek Borsik]

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

Here are the tests Dave was talking about:

[image: image.png]
rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz
<https://chat.libreqos.io/user_uploads/2/8e/3WTCbgSVMmPJBl0orVwjo8_q/rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz>
tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz
<https://chat.libreqos.io/user_uploads/2/5e/mBHcvB2O-G4VByXrl_tZuLY0/tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz>
tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz
<https://chat.libreqos.io/user_uploads/2/9b/rN7DZy6-0xEuPkb0N9pwoIRU/tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz>

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 Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <
starlink@lists.bufferbloat.net> wrote:

> Just fq codel or cake everything and you get all that.
>
> Libreqos is free software for those that do not want to update their data
> plane. Perhaps we should do a public demo of what it can do for every tech
> on the planet. Dsl benefits, fiber does also (but it is the stats that
> matter more on fiber because the customer wifi becomes bloated)
>
> Starlink merely fq codeled their wifi and did some aqm work (not codel I
> think) to get the amazing results they are getting today. I don't have the
> waveform test results handy but they are amazing. I feel a sea change in
> the wind...
>
>
>
> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> Colin,
>> I am overwhelmed with all the reasons that prevent low(er) or consistent
>> latency.
>> I think that our best ISP offerings should deliver graceful, agile, or
>> nimble service. Sure, handle all the high-volume data. The high-volume
>> service just shouldn’t preclude graceful service. Yes, the current ISP
>> practices fall short. Can we help them improve their service?
>>
>> Am I asking too much?
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>>
>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>> Gene,
>>
>> I think the lion's share of other people (many brilliant people here) on
>> this thread are focused on keeping latency down when under load. I
>> generally just read and don't contribute on those discussions, because
>> that's not my area of expertise. I only posted my point on bandwidth, not
>> to detract from the importance of reducing latency, but to correct what I
>> believed to be an important error on minimum bandwidth required to be able
>> to perform standard Internet functions.
>>
>> To my surprise, there was pushback on the figure, so I've responded to
>> try to educate this group on streaming usage in the hope that the people
>> working on the latency problem under load (core reason for this group to
>> exist) can also be aware of the minimum bandwidth needs to ensure they
>> don't plan based on bad assumptions.
>>
>> For a single user, minimum bandwidth (independent of latency) needs to be
>> at least 25Mbps assuming the goal is to provide access to all standard
>> Internet services. Anything short of that will deny users access to the
>> primary streaming services, and more specifically won't be able to watch 4K
>> HDR video, which is the market standard for streaming services today and
>> likely will remain at that level for the next several years.
>>
>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>> video (not everyone cares about that), but at least 25Mbps should be
>> available to an Internet customer for any new Internet service rollout.
>>
>> Cheers,
>> Colin
>>
>>
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>> starlink-request@lists.bufferbloat.net
>> Sent: Tuesday, April 30, 2024 3:05 PM
>> To: starlink@lists.bufferbloat.net
>> Subject: Starlink Digest, Vol 37, Issue 15
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>> From: Eugene Y Chang <eugene.chang@ieee.org>
>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>> <starlink@lists.bufferbloat.net>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I am always surprised how complicated these discussions become.
>> (Surprised mostly because I forgot the kind of issues this community care
>> about.) The discussion doesn’t shed light on the following scenarios.
>>
>> While watching stream content, activating controls needed to switch
>> content sometimes (often?) have long pauses. I attribute that to buffer
>> bloat and high latency.
>>
>> With a happy household user watching streaming media, a second user could
>> have terrible shopping experience with Amazon. The interactive response
>> could be (is often) horrible. (Personally, I would be doing email and
>> working on a shared doc. The Amazon analogy probably applies to more
>> people.)
>>
>> How can we deliver graceful performance to both persons in a household?
>> Is seeking graceful performance too complicated to improve?
>> (I said “graceful” to allow technical flexibility.)
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

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

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 732492 bytes --]

Re: [Starlink] It’s the Latency, FCC

[Dave Taht]

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

he also had a waveform result as best as I recall. Simpler than running
flent.

On Tue, Apr 30, 2024 at 2:23 PM Frantisek Borsik <frantisek.borsik@gmail.com>
wrote:

> Here are the tests Dave was talking about:
>
> [image: image.png]
> rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz
> <https://chat.libreqos.io/user_uploads/2/8e/3WTCbgSVMmPJBl0orVwjo8_q/rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz>
> tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz
> <https://chat.libreqos.io/user_uploads/2/5e/mBHcvB2O-G4VByXrl_tZuLY0/tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz>
> tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz
> <https://chat.libreqos.io/user_uploads/2/9b/rN7DZy6-0xEuPkb0N9pwoIRU/tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz>
>
> 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 Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> Just fq codel or cake everything and you get all that.
>>
>> Libreqos is free software for those that do not want to update their data
>> plane. Perhaps we should do a public demo of what it can do for every tech
>> on the planet. Dsl benefits, fiber does also (but it is the stats that
>> matter more on fiber because the customer wifi becomes bloated)
>>
>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>> think) to get the amazing results they are getting today. I don't have the
>> waveform test results handy but they are amazing. I feel a sea change in
>> the wind...
>>
>>
>>
>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> Colin,
>>> I am overwhelmed with all the reasons that prevent low(er) or consistent
>>> latency.
>>> I think that our best ISP offerings should deliver graceful, agile, or
>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>> practices fall short. Can we help them improve their service?
>>>
>>> Am I asking too much?
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>> Gene,
>>>
>>> I think the lion's share of other people (many brilliant people here) on
>>> this thread are focused on keeping latency down when under load. I
>>> generally just read and don't contribute on those discussions, because
>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>> to detract from the importance of reducing latency, but to correct what I
>>> believed to be an important error on minimum bandwidth required to be able
>>> to perform standard Internet functions.
>>>
>>> To my surprise, there was pushback on the figure, so I've responded to
>>> try to educate this group on streaming usage in the hope that the people
>>> working on the latency problem under load (core reason for this group to
>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>> don't plan based on bad assumptions.
>>>
>>> For a single user, minimum bandwidth (independent of latency) needs to
>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>> Internet services. Anything short of that will deny users access to the
>>> primary streaming services, and more specifically won't be able to watch 4K
>>> HDR video, which is the market standard for streaming services today and
>>> likely will remain at that level for the next several years.
>>>
>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>> video (not everyone cares about that), but at least 25Mbps should be
>>> available to an Internet customer for any new Internet service rollout.
>>>
>>> Cheers,
>>> Colin
>>>
>>>
>>> -----Original Message-----
>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>> starlink-request@lists.bufferbloat.net
>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>> To: starlink@lists.bufferbloat.net
>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>> <starlink@lists.bufferbloat.net>
>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> I am always surprised how complicated these discussions become.
>>> (Surprised mostly because I forgot the kind of issues this community care
>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>
>>> While watching stream content, activating controls needed to switch
>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>> bloat and high latency.
>>>
>>> With a happy household user watching streaming media, a second user
>>> could have terrible shopping experience with Amazon. The interactive
>>> response could be (is often) horrible. (Personally, I would be doing email
>>> and working on a shared doc. The Amazon analogy probably applies to more
>>> people.)
>>>
>>> How can we deliver graceful performance to both persons in a household?
>>> Is seeking graceful performance too complicated to improve?
>>> (I said “graceful” to allow technical flexibility.)
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>

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

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

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 732492 bytes --]

Re: [Starlink] It’s the Latency, FCC

[Dave Taht]

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

Oh, the image from waveform was late to load. In the past months starlink
has gone from hundreds of ms of bufferbloat related latency to zero on the
upload and a mere 31ms on the download. For those that don´t know: that is
better than comcast, most fiber, all dsl, and most (non-libreqos or preseem
using) FWA, by a mile.

On Tue, Apr 30, 2024 at 3:02 PM Dave Taht <dave.taht@gmail.com> wrote:

> he also had a waveform result as best as I recall. Simpler than running
> flent.
>
> On Tue, Apr 30, 2024 at 2:23 PM Frantisek Borsik <
> frantisek.borsik@gmail.com> wrote:
>
>> Here are the tests Dave was talking about:
>>
>> [image: image.png]
>> rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz
>> <https://chat.libreqos.io/user_uploads/2/8e/3WTCbgSVMmPJBl0orVwjo8_q/rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz>
>> tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz
>> <https://chat.libreqos.io/user_uploads/2/5e/mBHcvB2O-G4VByXrl_tZuLY0/tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz>
>> tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz
>> <https://chat.libreqos.io/user_uploads/2/9b/rN7DZy6-0xEuPkb0N9pwoIRU/tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz>
>>
>> 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 Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software for those that do not want to update their
>>> data plane. Perhaps we should do a public demo of what it can do for every
>>> tech on the planet. Dsl benefits, fiber does also (but it is the stats that
>>> matter more on fiber because the customer wifi becomes bloated)
>>>
>>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>>> think) to get the amazing results they are getting today. I don't have the
>>> waveform test results handy but they are amazing. I feel a sea change in
>>> the wind...
>>>
>>>
>>>
>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>>> Colin,
>>>> I am overwhelmed with all the reasons that prevent low(er) or
>>>> consistent latency.
>>>> I think that our best ISP offerings should deliver graceful, agile, or
>>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>>> practices fall short. Can we help them improve their service?
>>>>
>>>> Am I asking too much?
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> IEEE Life Senior Member
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>>> starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Gene,
>>>>
>>>> I think the lion's share of other people (many brilliant people here)
>>>> on this thread are focused on keeping latency down when under load. I
>>>> generally just read and don't contribute on those discussions, because
>>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>>> to detract from the importance of reducing latency, but to correct what I
>>>> believed to be an important error on minimum bandwidth required to be able
>>>> to perform standard Internet functions.
>>>>
>>>> To my surprise, there was pushback on the figure, so I've responded to
>>>> try to educate this group on streaming usage in the hope that the people
>>>> working on the latency problem under load (core reason for this group to
>>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>>> don't plan based on bad assumptions.
>>>>
>>>> For a single user, minimum bandwidth (independent of latency) needs to
>>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>>> Internet services. Anything short of that will deny users access to the
>>>> primary streaming services, and more specifically won't be able to watch 4K
>>>> HDR video, which is the market standard for streaming services today and
>>>> likely will remain at that level for the next several years.
>>>>
>>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>>> video (not everyone cares about that), but at least 25Mbps should be
>>>> available to an Internet customer for any new Internet service rollout.
>>>>
>>>> Cheers,
>>>> Colin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>>> starlink-request@lists.bufferbloat.net
>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>> To: starlink@lists.bufferbloat.net
>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>>> <starlink@lists.bufferbloat.net>
>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> I am always surprised how complicated these discussions become.
>>>> (Surprised mostly because I forgot the kind of issues this community care
>>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>>
>>>> While watching stream content, activating controls needed to switch
>>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>>> bloat and high latency.
>>>>
>>>> With a happy household user watching streaming media, a second user
>>>> could have terrible shopping experience with Amazon. The interactive
>>>> response could be (is often) horrible. (Personally, I would be doing email
>>>> and working on a shared doc. The Amazon analogy probably applies to more
>>>> people.)
>>>>
>>>> How can we deliver graceful performance to both persons in a household?
>>>> Is seeking graceful performance too complicated to improve?
>>>> (I said “graceful” to allow technical flexibility.)
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>
>
> --
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos
>


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

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

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 732492 bytes --]

Re: [Starlink] [LibreQoS] It’s the Latency, FCC

[Jim Forster]

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

I kind of like Waveform BB test, but a couple issues:

* From some places in India? and Southern Africa, the closest server they use is far away.  Consequently the base latency is much higher than most content, which these days comes from CDNs.

* I don’t mind the ads, but I did get a comment from someone I referred to it, that the site was ‘mostly about trying to sell some gear’.  WF could alleviate that with an explanation of who they are, etc.  Maybe it’s there & I missed it?

  — Jim

> On Apr 30, 2024, at 6:02 PM, Dave Taht via LibreQoS <libreqos@lists.bufferbloat.net> wrote:
> 
> he also had a waveform result as best as I recall. Simpler than running flent.
> 
> On Tue, Apr 30, 2024 at 2:23 PM Frantisek Borsik <frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>> wrote:
>> Here are the tests Dave was talking about:
>> 
>> 


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

Re: [Starlink] [LibreQoS] It’s the Latency, FCC

[Frantisek Borsik]

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

Thanks for the comments, Jim. I'm adding Sina
<https://www.linkedin.com/in/sinakhanifar/>, CEO at Waveform, to the
conversation. Maybe he will have some answers...

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 Wed, May 1, 2024 at 5:28 AM Jim Forster <jrforster@mac.com> wrote:

> I kind of like Waveform BB test, but a couple issues:
>
> * From some places in India? and Southern Africa, the closest server they
> use is far away.  Consequently the base latency is much higher than most
> content, which these days comes from CDNs.
>
> * I don’t mind the ads, but I did get a comment from someone I referred to
> it, that the site was ‘mostly about trying to sell some gear’.  WF could
> alleviate that with an explanation of who they are, etc.  Maybe it’s there
> & I missed it?
>
>   — Jim
>
> On Apr 30, 2024, at 6:02 PM, Dave Taht via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
> he also had a waveform result as best as I recall. Simpler than running
> flent.
>
> On Tue, Apr 30, 2024 at 2:23 PM Frantisek Borsik <
> frantisek.borsik@gmail.com> wrote:
>
>> Here are the tests Dave was talking about:
>>
>> [image: image.png]
>>
>
>

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

[Starlink] Fwd: It’s the Latency, FCC

[Rich Brown]

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

> Eugene Y. Change writes...
>
> A public promotion (campaign) of modern best practices is needed. Then I need to have this campaign spill over to the subscriber community. The business community needs to be educated that their productivity will improve. The social leaders need to learn that their community will get better service. Then, and only then, can I see the ISP feeling the need to improve. It helps if the improvement is just open-source software on their hardware investment.

Another "pressure point" : Dave points out that after Starlink fq_codeled the Wi-Fi and did some other AQM work, their speeds are good and the latency is just fine. 

That's going to Outer Space, for gosh sakes, Outer Space! Why can't your $ISP do better?

Rich

> Begin forwarded message:
> 
> From: Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] It’s the Latency, FCC
> Date: April 30, 2024 at 5:22:33 PM EDT
> To: Dave Taht <dave.taht@gmail.com>, Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> Cc: Colin_Higbie <CHigbie1@higbie.name>, libreqos <libreqos@lists.bufferbloat.net>
> Reply-To: Frantisek Borsik <frantisek.borsik@gmail.com>
> Sender: "Starlink" <starlink-bounces@lists.bufferbloat.net>
> 
> Here are the tests Dave was talking about:
> 
> 
> rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz <https://chat.libreqos.io/user_uploads/2/8e/3WTCbgSVMmPJBl0orVwjo8_q/rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz>
> tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz <https://chat.libreqos.io/user_uploads/2/5e/mBHcvB2O-G4VByXrl_tZuLY0/tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz>
> tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz <https://chat.libreqos.io/user_uploads/2/9b/rN7DZy6-0xEuPkb0N9pwoIRU/tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz>
> 
> All the best,
> 
> Frank
> 
> Frantisek (Frank) Borsik
> 
>  
> 
> https://www.linkedin.com/in/frantisekborsik <https://www.linkedin.com/in/frantisekborsik>
> Signal, Telegram, WhatsApp: +421919416714 
> 
> iMessage, mobile: +420775230885
> 
> Skype: casioa5302ca
> 
> frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>
> 
> On Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> Just fq codel or cake everything and you get all that.
> 
> Libreqos is free software for those that do not want to update their data plane. Perhaps we should do a public demo of what it can do for every tech on the planet. Dsl benefits, fiber does also (but it is the stats that matter more on fiber because the customer wifi becomes bloated)
> 
> Starlink merely fq codeled their wifi and did some aqm work (not codel I think) to get the amazing results they are getting today. I don't have the waveform test results handy but they are amazing. I feel a sea change in the wind...
> 
> 
> 
> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> Colin,
> I am overwhelmed with all the reasons that prevent low(er) or consistent latency.
> I think that our best ISP offerings should deliver graceful, agile, or nimble service. Sure, handle all the high-volume data. The high-volume service just shouldn’t preclude graceful service. Yes, the current ISP practices fall short. Can we help them improve their service?
> 
> Am I asking too much?
> 
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> 
> 
> 
> 
>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> 
>> Gene,
>> 
>> I think the lion's share of other people (many brilliant people here) on this thread are focused on keeping latency down when under load. I generally just read and don't contribute on those discussions, because that's not my area of expertise. I only posted my point on bandwidth, not to detract from the importance of reducing latency, but to correct what I believed to be an important error on minimum bandwidth required to be able to perform standard Internet functions. 
>> 
>> To my surprise, there was pushback on the figure, so I've responded to try to educate this group on streaming usage in the hope that the people working on the latency problem under load (core reason for this group to exist) can also be aware of the minimum bandwidth needs to ensure they don't plan based on bad assumptions.
>> 
>> For a single user, minimum bandwidth (independent of latency) needs to be at least 25Mbps assuming the goal is to provide access to all standard Internet services. Anything short of that will deny users access to the primary streaming services, and more specifically won't be able to watch 4K HDR video, which is the market standard for streaming services today and likely will remain at that level for the next several years.
>> 
>> I think it's fine to offer lower-cost options that don't deliver 4K HDR video (not everyone cares about that), but at least 25Mbps should be available to an Internet customer for any new Internet service rollout.
>> 
>> Cheers,
>> Colin
>> 
>> 
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of starlink-request@lists.bufferbloat.net <mailto:starlink-request@lists.bufferbloat.net>
>> Sent: Tuesday, April 30, 2024 3:05 PM
>> To: starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>
>> Subject: Starlink Digest, Vol 37, Issue 15
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>> From: Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>>
>> To: Colin_Higbie <CHigbie1@Higbie.name <mailto:CHigbie1@Higbie.name>>, Dave Taht via Starlink
>> 	<starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org <mailto:438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.
>> 
>> While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.
>> 
>> With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)
>> 
>> How can we deliver graceful performance to both persons in a household?
>> Is seeking graceful performance too complicated to improve?
>> (I said “graceful” to allow technical flexibility.)
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #2.1: Type: text/html, Size: 20054 bytes --]

[-- Attachment #2.2: image.png --]
[-- Type: image/png, Size: 732492 bytes --]

Re: [Starlink] Fwd: It’s the Latency, FCC

[Dave Taht]

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

I think that the starlink results will create competitive pressure on the
landline ISPs (and starlink will continue their rapid growth, being that
they drop their next hop direct into multiple cdns).

That´s why I sank 3 years into this project, and this list, working for
free, and I hope it pays off with better internet for everyone.

On Tue, Apr 30, 2024 at 3:05 PM Rich Brown via Starlink <
starlink@lists.bufferbloat.net> wrote:

> > Eugene Y. Change writes...
> >
> > A public promotion (campaign) of modern best practices is needed. Then I
> need to have this campaign spill over to the subscriber community. The
> business community needs to be educated that their productivity will
> improve. The social leaders need to learn that their community will get
> better service. Then, and only then, can I see the ISP feeling the need to
> improve. It helps if the improvement is just open-source software on their
> hardware investment.
>
> Another "pressure point" : Dave points out that after Starlink fq_codeled
> the Wi-Fi and did some other AQM work, their speeds are good and the
> latency is just fine.
>
> That's going to Outer Space, for gosh sakes, Outer Space! Why can't your
> $ISP do better?
>
> Rich
>
> Begin forwarded message:
>
> *From: *Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net>
> *Subject: **Re: [Starlink] It’s the Latency, FCC*
> *Date: *April 30, 2024 at 5:22:33 PM EDT
> *To: *Dave Taht <dave.taht@gmail.com>, Dave Taht via Starlink <
> starlink@lists.bufferbloat.net>
> *Cc: *Colin_Higbie <CHigbie1@higbie.name>, libreqos <
> libreqos@lists.bufferbloat.net>
> *Reply-To: *Frantisek Borsik <frantisek.borsik@gmail.com>
> *Sender: *"Starlink" <starlink-bounces@lists.bufferbloat.net>
>
> Here are the tests Dave was talking about:
>
> [image: image.png]
> rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz
> <https://chat.libreqos.io/user_uploads/2/8e/3WTCbgSVMmPJBl0orVwjo8_q/rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz>
> tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz
> <https://chat.libreqos.io/user_uploads/2/5e/mBHcvB2O-G4VByXrl_tZuLY0/tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz>
> tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz
> <https://chat.libreqos.io/user_uploads/2/9b/rN7DZy6-0xEuPkb0N9pwoIRU/tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz>
>
> 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 Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> Just fq codel or cake everything and you get all that.
>>
>> Libreqos is free software for those that do not want to update their data
>> plane. Perhaps we should do a public demo of what it can do for every tech
>> on the planet. Dsl benefits, fiber does also (but it is the stats that
>> matter more on fiber because the customer wifi becomes bloated)
>>
>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>> think) to get the amazing results they are getting today. I don't have the
>> waveform test results handy but they are amazing. I feel a sea change in
>> the wind...
>>
>>
>>
>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> Colin,
>>> I am overwhelmed with all the reasons that prevent low(er) or consistent
>>> latency.
>>> I think that our best ISP offerings should deliver graceful, agile, or
>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>> practices fall short. Can we help them improve their service?
>>>
>>> Am I asking too much?
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>> Gene,
>>>
>>> I think the lion's share of other people (many brilliant people here) on
>>> this thread are focused on keeping latency down when under load. I
>>> generally just read and don't contribute on those discussions, because
>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>> to detract from the importance of reducing latency, but to correct what I
>>> believed to be an important error on minimum bandwidth required to be able
>>> to perform standard Internet functions.
>>>
>>> To my surprise, there was pushback on the figure, so I've responded to
>>> try to educate this group on streaming usage in the hope that the people
>>> working on the latency problem under load (core reason for this group to
>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>> don't plan based on bad assumptions.
>>>
>>> For a single user, minimum bandwidth (independent of latency) needs to
>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>> Internet services. Anything short of that will deny users access to the
>>> primary streaming services, and more specifically won't be able to watch 4K
>>> HDR video, which is the market standard for streaming services today and
>>> likely will remain at that level for the next several years.
>>>
>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>> video (not everyone cares about that), but at least 25Mbps should be
>>> available to an Internet customer for any new Internet service rollout.
>>>
>>> Cheers,
>>> Colin
>>>
>>>
>>> -----Original Message-----
>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>> starlink-request@lists.bufferbloat.net
>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>> To: starlink@lists.bufferbloat.net
>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>> <starlink@lists.bufferbloat.net>
>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> I am always surprised how complicated these discussions become.
>>> (Surprised mostly because I forgot the kind of issues this community care
>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>
>>> While watching stream content, activating controls needed to switch
>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>> bloat and high latency.
>>>
>>> With a happy household user watching streaming media, a second user
>>> could have terrible shopping experience with Amazon. The interactive
>>> response could be (is often) horrible. (Personally, I would be doing email
>>> and working on a shared doc. The Amazon analogy probably applies to more
>>> people.)
>>>
>>> How can we deliver graceful performance to both persons in a household?
>>> Is seeking graceful performance too complicated to improve?
>>> (I said “graceful” to allow technical flexibility.)
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


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

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

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 732492 bytes --]

Re: [Starlink] It’s the Latency, FCC

[Rich Brown]

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


> On Apr 30, 2024, at 6:10 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I think that the starlink results will create competitive pressure on the landline ISPs (and starlink will continue their rapid growth, being that they drop their next hop direct into multiple cdns). 

Of course, it's important to remember that Starlink "cheated" - they are using science! (Even if we did have to browbeat them to pay attention...)

> That´s why I sank 3 years into this project, and this list, working for free, and I hope it pays off with better internet for everyone.


Thanks, Dave!

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

Re: [Starlink] It’s the Latency, FCC

[Dave Taht]

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

On Tue, Apr 30, 2024, 3:42 PM Rich Brown <richb.hanover@gmail.com> wrote:

>
> On Apr 30, 2024, at 6:10 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
> I think that the starlink results will create competitive pressure on the
> landline ISPs (and starlink will continue their rapid growth, being that
> they drop their next hop direct into multiple cdns).
>
>
> Of course, it's important to remember that Starlink "cheated" - they are
> using science! (Even if we did have to browbeat them to pay attention...)
>
> That´s why I sank 3 years into this project, and this list, working for
> free, and I hope it pays off with better internet for everyone.
>
>
> Thanks, Dave!
>

And all I asked Elon for was a new motor and batteries for my boat. And a
Christmas card....

https://youtu.be/c9gLo6Xrwgw?si=RyLWEtIWISEFX1kw

I don't think a tesla semi engine is needed to push 36 tons through the
water or not, but I do hope to get some help also on the design and install
thrown in.

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

Re: [Starlink] It’s the Latency, FCC

[Eugene Y Chang]

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

I need some technical peers to participate in performance-related publicity to get the story out.
I am very aware that I can’t handle all the roles alone. Sharing the good news needs a team of experts.

I am building an alliance with the eSports league. Of course, they want better latency.

I really need to teach the business community they are paying a performance penalty with the status quo. The needs of the business community will have more urgency than eSports.

I will note that most of the local networking experts (especially those working for the state) were developed at the local telco. They all have serious ISP-itis.

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member




> On Apr 30, 2024, at 12:05 PM, Rich Brown via Starlink <starlink@lists.bufferbloat.net> wrote:
> 
> > Eugene Y. Change writes...
> >
> > A public promotion (campaign) of modern best practices is needed. Then I need to have this campaign spill over to the subscriber community. The business community needs to be educated that their productivity will improve. The social leaders need to learn that their community will get better service. Then, and only then, can I see the ISP feeling the need to improve. It helps if the improvement is just open-source software on their hardware investment.
> 
> Another "pressure point" : Dave points out that after Starlink fq_codeled the Wi-Fi and did some other AQM work, their speeds are good and the latency is just fine.
> 
> That's going to Outer Space, for gosh sakes, Outer Space! Why can't your $ISP do better?
> 
> Rich
> 
>> Begin forwarded message:
>> 
>> From: Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>> Date: April 30, 2024 at 5:22:33 PM EDT
>> To: Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>>, Dave Taht via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>> Cc: Colin_Higbie <CHigbie1@higbie.name <mailto:CHigbie1@higbie.name>>, libreqos <libreqos@lists.bufferbloat.net <mailto:libreqos@lists.bufferbloat.net>>
>> Reply-To: Frantisek Borsik <frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>>
>> Sender: "Starlink" <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>>
>> 
>> Here are the tests Dave was talking about:
>> 
>> 
>> rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz <https://chat.libreqos.io/user_uploads/2/8e/3WTCbgSVMmPJBl0orVwjo8_q/rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz>
>> tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz <https://chat.libreqos.io/user_uploads/2/5e/mBHcvB2O-G4VByXrl_tZuLY0/tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz>
>> tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz <https://chat.libreqos.io/user_uploads/2/9b/rN7DZy6-0xEuPkb0N9pwoIRU/tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz>
>> 
>> All the best,
>> 
>> Frank
>> 
>> Frantisek (Frank) Borsik
>> 
>> 
>> 
>> https://www.linkedin.com/in/frantisekborsik <https://www.linkedin.com/in/frantisekborsik>
>> Signal, Telegram, WhatsApp: +421919416714
>> 
>> iMessage, mobile: +420775230885
>> 
>> Skype: casioa5302ca
>> 
>> frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>
>> 
>> On Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> Just fq codel or cake everything and you get all that.
>> 
>> Libreqos is free software for those that do not want to update their data plane. Perhaps we should do a public demo of what it can do for every tech on the planet. Dsl benefits, fiber does also (but it is the stats that matter more on fiber because the customer wifi becomes bloated)
>> 
>> Starlink merely fq codeled their wifi and did some aqm work (not codel I think) to get the amazing results they are getting today. I don't have the waveform test results handy but they are amazing. I feel a sea change in the wind...
>> 
>> 
>> 
>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> Colin,
>> I am overwhelmed with all the reasons that prevent low(er) or consistent latency.
>> I think that our best ISP offerings should deliver graceful, agile, or nimble service. Sure, handle all the high-volume data. The high-volume service just shouldn’t preclude graceful service. Yes, the current ISP practices fall short. Can we help them improve their service?
>> 
>> Am I asking too much?
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>> 
>> 
>> 
>> 
>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> 
>>> Gene,
>>> 
>>> I think the lion's share of other people (many brilliant people here) on this thread are focused on keeping latency down when under load. I generally just read and don't contribute on those discussions, because that's not my area of expertise. I only posted my point on bandwidth, not to detract from the importance of reducing latency, but to correct what I believed to be an important error on minimum bandwidth required to be able to perform standard Internet functions.
>>> 
>>> To my surprise, there was pushback on the figure, so I've responded to try to educate this group on streaming usage in the hope that the people working on the latency problem under load (core reason for this group to exist) can also be aware of the minimum bandwidth needs to ensure they don't plan based on bad assumptions.
>>> 
>>> For a single user, minimum bandwidth (independent of latency) needs to be at least 25Mbps assuming the goal is to provide access to all standard Internet services. Anything short of that will deny users access to the primary streaming services, and more specifically won't be able to watch 4K HDR video, which is the market standard for streaming services today and likely will remain at that level for the next several years.
>>> 
>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR video (not everyone cares about that), but at least 25Mbps should be available to an Internet customer for any new Internet service rollout.
>>> 
>>> Cheers,
>>> Colin
>>> 
>>> 
>>> -----Original Message-----
>>> From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of starlink-request@lists.bufferbloat.net <mailto:starlink-request@lists.bufferbloat.net>
>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>> To: starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>
>>> Subject: Starlink Digest, Vol 37, Issue 15
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> 
>>> Message: 1
>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>> From: Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>>
>>> To: Colin_Higbie <CHigbie1@Higbie.name <mailto:CHigbie1@Higbie.name>>, Dave Taht via Starlink
>>> 	<starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org <mailto:438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>>
>>> Content-Type: text/plain; charset="utf-8"
>>> 
>>> I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.
>>> 
>>> While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.
>>> 
>>> With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)
>>> 
>>> How can we deliver graceful performance to both persons in a household?
>>> Is seeking graceful performance too complicated to improve?
>>> (I said “graceful” to allow technical flexibility.)
>>> 
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> 
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


[-- Attachment #1.2.1: Type: text/html, Size: 24644 bytes --]

[-- Attachment #1.2.2: image.png --]
[-- Type: image/png, Size: 85252 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Starlink] It’s the Latency, FCC

[Eugene Y Chang]

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

OK. I need help teaching my ISPs that they can do this without threatening their business model.
Who can help me?

A public demo? Yes! Are you saying that if our (my) neighborhood ISP adopted the lessons from the public demo, most of the latency issues would be solved? What won’t get fixed? How do we make this a widely adopted best practice? Am I crying over issues that are already fixed? Does this simplify the issues at the FCC?

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member




> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Just fq codel or cake everything and you get all that.
> 
> Libreqos is free software for those that do not want to update their data plane. Perhaps we should do a public demo of what it can do for every tech on the planet. Dsl benefits, fiber does also (but it is the stats that matter more on fiber because the customer wifi becomes bloated)
> 
> Starlink merely fq codeled their wifi and did some aqm work (not codel I think) to get the amazing results they are getting today. I don't have the waveform test results handy but they are amazing. I feel a sea change in the wind...
> 
> 
> 
> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> Colin,
> I am overwhelmed with all the reasons that prevent low(er) or consistent latency.
> I think that our best ISP offerings should deliver graceful, agile, or nimble service. Sure, handle all the high-volume data. The high-volume service just shouldn’t preclude graceful service. Yes, the current ISP practices fall short. Can we help them improve their service?
> 
> Am I asking too much?
> 
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> 
> 
> 
> 
>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> 
>> Gene,
>> 
>> I think the lion's share of other people (many brilliant people here) on this thread are focused on keeping latency down when under load. I generally just read and don't contribute on those discussions, because that's not my area of expertise. I only posted my point on bandwidth, not to detract from the importance of reducing latency, but to correct what I believed to be an important error on minimum bandwidth required to be able to perform standard Internet functions.
>> 
>> To my surprise, there was pushback on the figure, so I've responded to try to educate this group on streaming usage in the hope that the people working on the latency problem under load (core reason for this group to exist) can also be aware of the minimum bandwidth needs to ensure they don't plan based on bad assumptions.
>> 
>> For a single user, minimum bandwidth (independent of latency) needs to be at least 25Mbps assuming the goal is to provide access to all standard Internet services. Anything short of that will deny users access to the primary streaming services, and more specifically won't be able to watch 4K HDR video, which is the market standard for streaming services today and likely will remain at that level for the next several years.
>> 
>> I think it's fine to offer lower-cost options that don't deliver 4K HDR video (not everyone cares about that), but at least 25Mbps should be available to an Internet customer for any new Internet service rollout.
>> 
>> Cheers,
>> Colin
>> 
>> 
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of starlink-request@lists.bufferbloat.net <mailto:starlink-request@lists.bufferbloat.net>
>> Sent: Tuesday, April 30, 2024 3:05 PM
>> To: starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>
>> Subject: Starlink Digest, Vol 37, Issue 15
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>> From: Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>>
>> To: Colin_Higbie <CHigbie1@Higbie.name <mailto:CHigbie1@Higbie.name>>, Dave Taht via Starlink
>> 	<starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org <mailto:438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.
>> 
>> While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.
>> 
>> With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)
>> 
>> How can we deliver graceful performance to both persons in a household?
>> Is seeking graceful performance too complicated to improve?
>> (I said “graceful” to allow technical flexibility.)
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>


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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Starlink] It’s the Latency, FCC

[Frantisek Borsik]

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

Eugene - the easiest thing in the case of your ISP would be tell him about
us: https://libreqos.io

He can take a look on it, join our support chat and get help if he won't be
able to get it up and running:
https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/

But most of the ISPs don't need to talk with us at all, it's easy to deploy.


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 Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
starlink@lists.bufferbloat.net> wrote:

> OK. I need help teaching my ISPs that they can do this without threatening
> their business model.
> Who can help me?
>
> A public demo? Yes! Are you saying that if our (my) neighborhood ISP
> adopted the lessons from the public demo, most of the latency issues would
> be solved? What won’t get fixed? How do we make this a widely adopted best
> practice? Am I crying over issues that are already fixed? Does this
> simplify the issues at the FCC?
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
>
>
>
>
> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
> Just fq codel or cake everything and you get all that.
>
> Libreqos is free software for those that do not want to update their data
> plane. Perhaps we should do a public demo of what it can do for every tech
> on the planet. Dsl benefits, fiber does also (but it is the stats that
> matter more on fiber because the customer wifi becomes bloated)
>
> Starlink merely fq codeled their wifi and did some aqm work (not codel I
> think) to get the amazing results they are getting today. I don't have the
> waveform test results handy but they are amazing. I feel a sea change in
> the wind...
>
>
>
> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> Colin,
>> I am overwhelmed with all the reasons that prevent low(er) or consistent
>> latency.
>> I think that our best ISP offerings should deliver graceful, agile, or
>> nimble service. Sure, handle all the high-volume data. The high-volume
>> service just shouldn’t preclude graceful service. Yes, the current ISP
>> practices fall short. Can we help them improve their service?
>>
>> Am I asking too much?
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>>
>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>> Gene,
>>
>> I think the lion's share of other people (many brilliant people here) on
>> this thread are focused on keeping latency down when under load. I
>> generally just read and don't contribute on those discussions, because
>> that's not my area of expertise. I only posted my point on bandwidth, not
>> to detract from the importance of reducing latency, but to correct what I
>> believed to be an important error on minimum bandwidth required to be able
>> to perform standard Internet functions.
>>
>> To my surprise, there was pushback on the figure, so I've responded to
>> try to educate this group on streaming usage in the hope that the people
>> working on the latency problem under load (core reason for this group to
>> exist) can also be aware of the minimum bandwidth needs to ensure they
>> don't plan based on bad assumptions.
>>
>> For a single user, minimum bandwidth (independent of latency) needs to be
>> at least 25Mbps assuming the goal is to provide access to all standard
>> Internet services. Anything short of that will deny users access to the
>> primary streaming services, and more specifically won't be able to watch 4K
>> HDR video, which is the market standard for streaming services today and
>> likely will remain at that level for the next several years.
>>
>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>> video (not everyone cares about that), but at least 25Mbps should be
>> available to an Internet customer for any new Internet service rollout.
>>
>> Cheers,
>> Colin
>>
>>
>> -----Original Message-----
>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>> starlink-request@lists.bufferbloat.net
>> Sent: Tuesday, April 30, 2024 3:05 PM
>> To: starlink@lists.bufferbloat.net
>> Subject: Starlink Digest, Vol 37, Issue 15
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>> From: Eugene Y Chang <eugene.chang@ieee.org>
>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>> <starlink@lists.bufferbloat.net>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I am always surprised how complicated these discussions become.
>> (Surprised mostly because I forgot the kind of issues this community care
>> about.) The discussion doesn’t shed light on the following scenarios.
>>
>> While watching stream content, activating controls needed to switch
>> content sometimes (often?) have long pauses. I attribute that to buffer
>> bloat and high latency.
>>
>> With a happy household user watching streaming media, a second user could
>> have terrible shopping experience with Amazon. The interactive response
>> could be (is often) horrible. (Personally, I would be doing email and
>> working on a shared doc. The Amazon analogy probably applies to more
>> people.)
>>
>> How can we deliver graceful performance to both persons in a household?
>> Is seeking graceful performance too complicated to improve?
>> (I said “graceful” to allow technical flexibility.)
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

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

Re: [Starlink] It’s the Latency, FCC

[Eugene Y Chang]

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

Frank,
Thank you. What you suggest makes sense if it was objective!

In my neighborhood, the ISP’s organization will feel they have nothing to learn from outsiders. (Worst, both major ISPs are just a subsidiary of another organization. They just implement corporate standards. The local managers are not motivated to deviate from their corporate marching orders.)

A public promotion (campaign) of modern best practices is needed. Then I need to have this campaign spill over to the subscriber community. The business community needs to be educated that their productivity will improve. The social leaders need to learn that their community will get better service. Then, and only then, can I see the ISP feeling the need to improve. It helps if the improvement is just open-source software on their hardware investment.


Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member



> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:
> 
> Eugene - the easiest thing in the case of your ISP would be tell him about us: https://libreqos.io <https://libreqos.io/>
> 
> He can take a look on it, join our support chat and get help if he won't be able to get it up and running: https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/ <https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/>
> 
> But most of the ISPs don't need to talk with us at all, it's easy to deploy.
> 
> 
> All the best,
> 
> Frank
> 
> Frantisek (Frank) Borsik
> 
> 
> 
> https://www.linkedin.com/in/frantisekborsik <https://www.linkedin.com/in/frantisekborsik>
> Signal, Telegram, WhatsApp: +421919416714
> 
> iMessage, mobile: +420775230885
> 
> Skype: casioa5302ca
> 
> frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>
> 
> On Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
> OK. I need help teaching my ISPs that they can do this without threatening their business model.
> Who can help me?
> 
> A public demo? Yes! Are you saying that if our (my) neighborhood ISP adopted the lessons from the public demo, most of the latency issues would be solved? What won’t get fixed? How do we make this a widely adopted best practice? Am I crying over issues that are already fixed? Does this simplify the issues at the FCC?
> 
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> 
> 
> 
> 
>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>> wrote:
>> 
>> Just fq codel or cake everything and you get all that.
>> 
>> Libreqos is free software for those that do not want to update their data plane. Perhaps we should do a public demo of what it can do for every tech on the planet. Dsl benefits, fiber does also (but it is the stats that matter more on fiber because the customer wifi becomes bloated)
>> 
>> Starlink merely fq codeled their wifi and did some aqm work (not codel I think) to get the amazing results they are getting today. I don't have the waveform test results handy but they are amazing. I feel a sea change in the wind...
>> 
>> 
>> 
>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> Colin,
>> I am overwhelmed with all the reasons that prevent low(er) or consistent latency.
>> I think that our best ISP offerings should deliver graceful, agile, or nimble service. Sure, handle all the high-volume data. The high-volume service just shouldn’t preclude graceful service. Yes, the current ISP practices fall short. Can we help them improve their service?
>> 
>> Am I asking too much?
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>> 
>> 
>> 
>> 
>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> 
>>> Gene,
>>> 
>>> I think the lion's share of other people (many brilliant people here) on this thread are focused on keeping latency down when under load. I generally just read and don't contribute on those discussions, because that's not my area of expertise. I only posted my point on bandwidth, not to detract from the importance of reducing latency, but to correct what I believed to be an important error on minimum bandwidth required to be able to perform standard Internet functions.
>>> 
>>> To my surprise, there was pushback on the figure, so I've responded to try to educate this group on streaming usage in the hope that the people working on the latency problem under load (core reason for this group to exist) can also be aware of the minimum bandwidth needs to ensure they don't plan based on bad assumptions.
>>> 
>>> For a single user, minimum bandwidth (independent of latency) needs to be at least 25Mbps assuming the goal is to provide access to all standard Internet services. Anything short of that will deny users access to the primary streaming services, and more specifically won't be able to watch 4K HDR video, which is the market standard for streaming services today and likely will remain at that level for the next several years.
>>> 
>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR video (not everyone cares about that), but at least 25Mbps should be available to an Internet customer for any new Internet service rollout.
>>> 
>>> Cheers,
>>> Colin
>>> 
>>> 
>>> -----Original Message-----
>>> From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of starlink-request@lists.bufferbloat.net <mailto:starlink-request@lists.bufferbloat.net>
>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>> To: starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>
>>> Subject: Starlink Digest, Vol 37, Issue 15
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> 
>>> Message: 1
>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>> From: Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>>
>>> To: Colin_Higbie <CHigbie1@Higbie.name <mailto:CHigbie1@Higbie.name>>, Dave Taht via Starlink
>>> 	<starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org <mailto:438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>>
>>> Content-Type: text/plain; charset="utf-8"
>>> 
>>> I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.
>>> 
>>> While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.
>>> 
>>> With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)
>>> 
>>> How can we deliver graceful performance to both persons in a household?
>>> Is seeking graceful performance too complicated to improve?
>>> (I said “graceful” to allow technical flexibility.)
>>> 
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> 
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>


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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Starlink] It’s the Latency, FCC

[David Lang]

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

Now you are talking about the real problem, how to get the ISPs to listen. It's 
not bandwidth.

David Lang

On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote:

> Frank,
> Thank you. What you suggest makes sense if it was objective!
>
> In my neighborhood, the ISP’s organization will feel they have nothing to learn from outsiders. (Worst, both major ISPs are just a subsidiary of another organization. They just implement corporate standards. The local managers are not motivated to deviate from their corporate marching orders.)
>
> A public promotion (campaign) of modern best practices is needed. Then I need to have this campaign spill over to the subscriber community. The business community needs to be educated that their productivity will improve. The social leaders need to learn that their community will get better service. Then, and only then, can I see the ISP feeling the need to improve. It helps if the improvement is just open-source software on their hardware investment.
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
>
>
>
>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:
>>
>> Eugene - the easiest thing in the case of your ISP would be tell him about us: https://libreqos.io <https://libreqos.io/>
>>
>> He can take a look on it, join our support chat and get help if he won't be able to get it up and running: https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/ <https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/>
>>
>> But most of the ISPs don't need to talk with us at all, it's easy to deploy.
>>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik <https://www.linkedin.com/in/frantisekborsik>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>
>>
>> On Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> OK. I need help teaching my ISPs that they can do this without threatening their business model.
>> Who can help me?
>>
>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP adopted the lessons from the public demo, most of the latency issues would be solved? What won’t get fixed? How do we make this a widely adopted best practice? Am I crying over issues that are already fixed? Does this simplify the issues at the FCC?
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>>
>>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>> wrote:
>>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software for those that do not want to update their data plane. Perhaps we should do a public demo of what it can do for every tech on the planet. Dsl benefits, fiber does also (but it is the stats that matter more on fiber because the customer wifi becomes bloated)
>>>
>>> Starlink merely fq codeled their wifi and did some aqm work (not codel I think) to get the amazing results they are getting today. I don't have the waveform test results handy but they are amazing. I feel a sea change in the wind...
>>>
>>>
>>>
>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> Colin,
>>> I am overwhelmed with all the reasons that prevent low(er) or consistent latency.
>>> I think that our best ISP offerings should deliver graceful, agile, or nimble service. Sure, handle all the high-volume data. The high-volume service just shouldn’t preclude graceful service. Yes, the current ISP practices fall short. Can we help them improve their service?
>>>
>>> Am I asking too much?
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>>>
>>>> Gene,
>>>>
>>>> I think the lion's share of other people (many brilliant people here) on this thread are focused on keeping latency down when under load. I generally just read and don't contribute on those discussions, because that's not my area of expertise. I only posted my point on bandwidth, not to detract from the importance of reducing latency, but to correct what I believed to be an important error on minimum bandwidth required to be able to perform standard Internet functions.
>>>>
>>>> To my surprise, there was pushback on the figure, so I've responded to try to educate this group on streaming usage in the hope that the people working on the latency problem under load (core reason for this group to exist) can also be aware of the minimum bandwidth needs to ensure they don't plan based on bad assumptions.
>>>>
>>>> For a single user, minimum bandwidth (independent of latency) needs to be at least 25Mbps assuming the goal is to provide access to all standard Internet services. Anything short of that will deny users access to the primary streaming services, and more specifically won't be able to watch 4K HDR video, which is the market standard for streaming services today and likely will remain at that level for the next several years.
>>>>
>>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR video (not everyone cares about that), but at least 25Mbps should be available to an Internet customer for any new Internet service rollout.
>>>>
>>>> Cheers,
>>>> Colin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of starlink-request@lists.bufferbloat.net <mailto:starlink-request@lists.bufferbloat.net>
>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>> To: starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>
>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>> From: Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>>
>>>> To: Colin_Higbie <CHigbie1@Higbie.name <mailto:CHigbie1@Higbie.name>>, Dave Taht via Starlink
>>>> 	<starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org <mailto:438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.
>>>>
>>>> While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.
>>>>
>>>> With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)
>>>>
>>>> How can we deliver graceful performance to both persons in a household?
>>>> Is seeking graceful performance too complicated to improve?
>>>> (I said “graceful” to allow technical flexibility.)
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>
>

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

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

Re: [Starlink] It’s the Latency, FCC

[Frantisek Borsik]

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

Basically, Eugene, the situation you are describing is calling for a
competitor to disrupt them!

This is such an old story - so many ISPs, especially WIPSs, started just
because they either didn't have any option or all those options available
were really terrible.

Don't you want to pick up the glove? :P

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 Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang <eugene.chang@ieee.org>
wrote:

> Frank,
> Thank you. What you suggest makes sense if it was objective!
>
> In my neighborhood, the ISP’s organization will feel they have nothing to
> learn from outsiders. (Worst, both major ISPs are just a subsidiary of
> another organization. They just implement corporate standards. The local
> managers are not motivated to deviate from their corporate marching orders.)
>
> A public promotion (campaign) of modern best practices is needed. Then I
> need to have this campaign spill over to the subscriber community. The
> business community needs to be educated that their productivity will
> improve. The social leaders need to learn that their community will get
> better service. Then, and only then, can I see the ISP feeling the need to
> improve. It helps if the improvement is just open-source software on their
> hardware investment.
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
>
>
>
> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <frantisek.borsik@gmail.com>
> wrote:
>
> Eugene - the easiest thing in the case of your ISP would be tell him about
> us: https://libreqos.io
>
> He can take a look on it, join our support chat and get help if he won't
> be able to get it up and running:
> https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
>
> But most of the ISPs don't need to talk with us at all, it's easy to
> deploy.
>
>
> 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 Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> OK. I need help teaching my ISPs that they can do this without
>> threatening their business model.
>> Who can help me?
>>
>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP
>> adopted the lessons from the public demo, most of the latency issues would
>> be solved? What won’t get fixed? How do we make this a widely adopted best
>> practice? Am I crying over issues that are already fixed? Does this
>> simplify the issues at the FCC?
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>>
>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Just fq codel or cake everything and you get all that.
>>
>> Libreqos is free software for those that do not want to update their data
>> plane. Perhaps we should do a public demo of what it can do for every tech
>> on the planet. Dsl benefits, fiber does also (but it is the stats that
>> matter more on fiber because the customer wifi becomes bloated)
>>
>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>> think) to get the amazing results they are getting today. I don't have the
>> waveform test results handy but they are amazing. I feel a sea change in
>> the wind...
>>
>>
>>
>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> Colin,
>>> I am overwhelmed with all the reasons that prevent low(er) or consistent
>>> latency.
>>> I think that our best ISP offerings should deliver graceful, agile, or
>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>> practices fall short. Can we help them improve their service?
>>>
>>> Am I asking too much?
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>> Gene,
>>>
>>> I think the lion's share of other people (many brilliant people here) on
>>> this thread are focused on keeping latency down when under load. I
>>> generally just read and don't contribute on those discussions, because
>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>> to detract from the importance of reducing latency, but to correct what I
>>> believed to be an important error on minimum bandwidth required to be able
>>> to perform standard Internet functions.
>>>
>>> To my surprise, there was pushback on the figure, so I've responded to
>>> try to educate this group on streaming usage in the hope that the people
>>> working on the latency problem under load (core reason for this group to
>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>> don't plan based on bad assumptions.
>>>
>>> For a single user, minimum bandwidth (independent of latency) needs to
>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>> Internet services. Anything short of that will deny users access to the
>>> primary streaming services, and more specifically won't be able to watch 4K
>>> HDR video, which is the market standard for streaming services today and
>>> likely will remain at that level for the next several years.
>>>
>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>> video (not everyone cares about that), but at least 25Mbps should be
>>> available to an Internet customer for any new Internet service rollout.
>>>
>>> Cheers,
>>> Colin
>>>
>>>
>>> -----Original Message-----
>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>> starlink-request@lists.bufferbloat.net
>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>> To: starlink@lists.bufferbloat.net
>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>> <starlink@lists.bufferbloat.net>
>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> I am always surprised how complicated these discussions become.
>>> (Surprised mostly because I forgot the kind of issues this community care
>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>
>>> While watching stream content, activating controls needed to switch
>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>> bloat and high latency.
>>>
>>> With a happy household user watching streaming media, a second user
>>> could have terrible shopping experience with Amazon. The interactive
>>> response could be (is often) horrible. (Personally, I would be doing email
>>> and working on a shared doc. The Amazon analogy probably applies to more
>>> people.)
>>>
>>> How can we deliver graceful performance to both persons in a household?
>>> Is seeking graceful performance too complicated to improve?
>>> (I said “graceful” to allow technical flexibility.)
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>
>

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

Re: [Starlink] [LibreQoS] It’s the Latency, FCC

[Brian Munyao Longwe]

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

Just got this result from my house in Lilongwe, Malawi, which is connected
via fiber to a POP 12kms away which backhauls over Ubiquiti Wave to our
core, which is then connected via Zambia to South African submarine cables.
Our LibreQOS box sits between our core and border devices.


On Wed, 1 May 2024 at 9:28 AM, Frantisek Borsik via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> Basically, Eugene, the situation you are describing is calling for a
> competitor to disrupt them!
>
> This is such an old story - so many ISPs, especially WIPSs, started just
> because they either didn't have any option or all those options available
> were really terrible.
>
> Don't you want to pick up the glove? :P
>
> 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 Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang <eugene.chang@ieee.org>
> wrote:
>
>> Frank,
>> Thank you. What you suggest makes sense if it was objective!
>>
>> In my neighborhood, the ISP’s organization will feel they have nothing to
>> learn from outsiders. (Worst, both major ISPs are just a subsidiary of
>> another organization. They just implement corporate standards. The local
>> managers are not motivated to deviate from their corporate marching orders.)
>>
>> A public promotion (campaign) of modern best practices is needed. Then I
>> need to have this campaign spill over to the subscriber community. The
>> business community needs to be educated that their productivity will
>> improve. The social leaders need to learn that their community will get
>> better service. Then, and only then, can I see the ISP feeling the need to
>> improve. It helps if the improvement is just open-source software on their
>> hardware investment.
>>
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <
>> frantisek.borsik@gmail.com> wrote:
>>
>> Eugene - the easiest thing in the case of your ISP would be tell him
>> about us: https://libreqos.io
>>
>> He can take a look on it, join our support chat and get help if he won't
>> be able to get it up and running:
>> https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
>>
>> But most of the ISPs don't need to talk with us at all, it's easy to
>> deploy.
>>
>>
>> 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 Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> OK. I need help teaching my ISPs that they can do this without
>>> threatening their business model.
>>> Who can help me?
>>>
>>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP
>>> adopted the lessons from the public demo, most of the latency issues would
>>> be solved? What won’t get fixed? How do we make this a widely adopted best
>>> practice? Am I crying over issues that are already fixed? Does this
>>> simplify the issues at the FCC?
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software for those that do not want to update their
>>> data plane. Perhaps we should do a public demo of what it can do for every
>>> tech on the planet. Dsl benefits, fiber does also (but it is the stats that
>>> matter more on fiber because the customer wifi becomes bloated)
>>>
>>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>>> think) to get the amazing results they are getting today. I don't have the
>>> waveform test results handy but they are amazing. I feel a sea change in
>>> the wind...
>>>
>>>
>>>
>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>>> Colin,
>>>> I am overwhelmed with all the reasons that prevent low(er) or
>>>> consistent latency.
>>>> I think that our best ISP offerings should deliver graceful, agile, or
>>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>>> practices fall short. Can we help them improve their service?
>>>>
>>>> Am I asking too much?
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> IEEE Life Senior Member
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>>> starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Gene,
>>>>
>>>> I think the lion's share of other people (many brilliant people here)
>>>> on this thread are focused on keeping latency down when under load. I
>>>> generally just read and don't contribute on those discussions, because
>>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>>> to detract from the importance of reducing latency, but to correct what I
>>>> believed to be an important error on minimum bandwidth required to be able
>>>> to perform standard Internet functions.
>>>>
>>>> To my surprise, there was pushback on the figure, so I've responded to
>>>> try to educate this group on streaming usage in the hope that the people
>>>> working on the latency problem under load (core reason for this group to
>>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>>> don't plan based on bad assumptions.
>>>>
>>>> For a single user, minimum bandwidth (independent of latency) needs to
>>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>>> Internet services. Anything short of that will deny users access to the
>>>> primary streaming services, and more specifically won't be able to watch 4K
>>>> HDR video, which is the market standard for streaming services today and
>>>> likely will remain at that level for the next several years.
>>>>
>>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>>> video (not everyone cares about that), but at least 25Mbps should be
>>>> available to an Internet customer for any new Internet service rollout.
>>>>
>>>> Cheers,
>>>> Colin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>>> starlink-request@lists.bufferbloat.net
>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>> To: starlink@lists.bufferbloat.net
>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>>> <starlink@lists.bufferbloat.net>
>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> I am always surprised how complicated these discussions become.
>>>> (Surprised mostly because I forgot the kind of issues this community care
>>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>>
>>>> While watching stream content, activating controls needed to switch
>>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>>> bloat and high latency.
>>>>
>>>> With a happy household user watching streaming media, a second user
>>>> could have terrible shopping experience with Amazon. The interactive
>>>> response could be (is often) horrible. (Personally, I would be doing email
>>>> and working on a shared doc. The Amazon analogy probably applies to more
>>>> people.)
>>>>
>>>> How can we deliver graceful performance to both persons in a household?
>>>> Is seeking graceful performance too complicated to improve?
>>>> (I said “graceful” to allow technical flexibility.)
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>
>> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

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

[-- Attachment #2: ECAF17B6-04A7-4DED-973C-06C041142505.png --]
[-- Type: image/png, Size: 3756844 bytes --]

Re: [Starlink] [LibreQoS] It’s the Latency, FCC

[Jim Forster]

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

Brian,

A+ — fantastic!

Any guesses or memory of what it would be without LibreQoS?

Where’s the Waveform server? I’m curious what a trace route to that sever looks like from CTN

   — Jim

> On May 1, 2024, at 3:32 AM, Brian Munyao Longwe via LibreQoS <libreqos@lists.bufferbloat.net> wrote:
> 
> Just got this result from my house in Lilongwe, Malawi, which is connected via fiber to a POP 12kms away which backhauls over Ubiquiti Wave to our core, which is then connected via Zambia to South African submarine cables. Our LibreQOS box sits between our core and border devices.


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

Re: [Starlink] [LibreQoS] It’s the Latency, FCC

[Brian Munyao Longwe]

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

Hey Jim,

From the trace it looks like the server is in South Africa (second last hop
is Liquids Harare POP)

Results before turning on LibreQOS were pretty bad C-F.

Thanks,

Brian

On Wed, 1 May 2024 at 3:26 PM, Jim Forster <jim@connectivitycap.com> wrote:

> Brian,
>
> A+ — fantastic!
>
> Any guesses or memory of what it would be without LibreQoS?
>
> Where’s the Waveform server? I’m curious what a trace route to that sever
> looks like from CTN
>
>    — Jim
>
> On May 1, 2024, at 3:32 AM, Brian Munyao Longwe via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
> Just got this result from my house in Lilongwe, Malawi, which is connected
> via fiber to a POP 12kms away which backhauls over Ubiquiti Wave to our
> core, which is then connected via Zambia to South African submarine cables.
> Our LibreQOS box sits between our core and border devices.
>
>
>

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

Re: [Starlink] [LibreQoS] It’s the Latency, FCC

[Dave Taht]

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

Yep. Better than starlink.

On Wed, May 1, 2024, 12:32 AM Brian Munyao Longwe via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> Just got this result from my house in Lilongwe, Malawi, which is connected
> via fiber to a POP 12kms away which backhauls over Ubiquiti Wave to our
> core, which is then connected via Zambia to South African submarine cables.
> Our LibreQOS box sits between our core and border devices.
>
>
> On Wed, 1 May 2024 at 9:28 AM, Frantisek Borsik via LibreQoS <
> libreqos@lists.bufferbloat.net> wrote:
>
>> Basically, Eugene, the situation you are describing is calling for a
>> competitor to disrupt them!
>>
>> This is such an old story - so many ISPs, especially WIPSs, started just
>> because they either didn't have any option or all those options available
>> were really terrible.
>>
>> Don't you want to pick up the glove? :P
>>
>> 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 Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang <eugene.chang@ieee.org>
>> wrote:
>>
>>> Frank,
>>> Thank you. What you suggest makes sense if it was objective!
>>>
>>> In my neighborhood, the ISP’s organization will feel they have nothing
>>> to learn from outsiders. (Worst, both major ISPs are just a subsidiary of
>>> another organization. They just implement corporate standards. The local
>>> managers are not motivated to deviate from their corporate marching orders.)
>>>
>>> A public promotion (campaign) of modern best practices is needed. Then I
>>> need to have this campaign spill over to the subscriber community. The
>>> business community needs to be educated that their productivity will
>>> improve. The social leaders need to learn that their community will get
>>> better service. Then, and only then, can I see the ISP feeling the need to
>>> improve. It helps if the improvement is just open-source software on their
>>> hardware investment.
>>>
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <
>>> frantisek.borsik@gmail.com> wrote:
>>>
>>> Eugene - the easiest thing in the case of your ISP would be tell him
>>> about us: https://libreqos.io
>>>
>>> He can take a look on it, join our support chat and get help if he won't
>>> be able to get it up and running:
>>> https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
>>>
>>> But most of the ISPs don't need to talk with us at all, it's easy to
>>> deploy.
>>>
>>>
>>> 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 Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>>> OK. I need help teaching my ISPs that they can do this without
>>>> threatening their business model.
>>>> Who can help me?
>>>>
>>>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP
>>>> adopted the lessons from the public demo, most of the latency issues would
>>>> be solved? What won’t get fixed? How do we make this a widely adopted best
>>>> practice? Am I crying over issues that are already fixed? Does this
>>>> simplify the issues at the FCC?
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> IEEE Life Senior Member
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>
>>>> Just fq codel or cake everything and you get all that.
>>>>
>>>> Libreqos is free software for those that do not want to update their
>>>> data plane. Perhaps we should do a public demo of what it can do for every
>>>> tech on the planet. Dsl benefits, fiber does also (but it is the stats that
>>>> matter more on fiber because the customer wifi becomes bloated)
>>>>
>>>> Starlink merely fq codeled their wifi and did some aqm work (not codel
>>>> I think) to get the amazing results they are getting today. I don't have
>>>> the waveform test results handy but they are amazing. I feel a sea change
>>>> in the wind...
>>>>
>>>>
>>>>
>>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>>>> starlink@lists.bufferbloat.net> wrote:
>>>>
>>>>> Colin,
>>>>> I am overwhelmed with all the reasons that prevent low(er) or
>>>>> consistent latency.
>>>>> I think that our best ISP offerings should deliver graceful, agile, or
>>>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>>>> practices fall short. Can we help them improve their service?
>>>>>
>>>>> Am I asking too much?
>>>>>
>>>>> Gene
>>>>> ----------------------------------------------
>>>>> Eugene Chang
>>>>> IEEE Life Senior Member
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>>>> starlink@lists.bufferbloat.net> wrote:
>>>>>
>>>>> Gene,
>>>>>
>>>>> I think the lion's share of other people (many brilliant people here)
>>>>> on this thread are focused on keeping latency down when under load. I
>>>>> generally just read and don't contribute on those discussions, because
>>>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>>>> to detract from the importance of reducing latency, but to correct what I
>>>>> believed to be an important error on minimum bandwidth required to be able
>>>>> to perform standard Internet functions.
>>>>>
>>>>> To my surprise, there was pushback on the figure, so I've responded to
>>>>> try to educate this group on streaming usage in the hope that the people
>>>>> working on the latency problem under load (core reason for this group to
>>>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>>>> don't plan based on bad assumptions.
>>>>>
>>>>> For a single user, minimum bandwidth (independent of latency) needs to
>>>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>>>> Internet services. Anything short of that will deny users access to the
>>>>> primary streaming services, and more specifically won't be able to watch 4K
>>>>> HDR video, which is the market standard for streaming services today and
>>>>> likely will remain at that level for the next several years.
>>>>>
>>>>> I think it's fine to offer lower-cost options that don't deliver 4K
>>>>> HDR video (not everyone cares about that), but at least 25Mbps should be
>>>>> available to an Internet customer for any new Internet service rollout.
>>>>>
>>>>> Cheers,
>>>>> Colin
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>>>> starlink-request@lists.bufferbloat.net
>>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>>> To: starlink@lists.bufferbloat.net
>>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> Message: 1
>>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>>>> <starlink@lists.bufferbloat.net>
>>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>
>>>>> I am always surprised how complicated these discussions become.
>>>>> (Surprised mostly because I forgot the kind of issues this community care
>>>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>>>
>>>>> While watching stream content, activating controls needed to switch
>>>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>>>> bloat and high latency.
>>>>>
>>>>> With a happy household user watching streaming media, a second user
>>>>> could have terrible shopping experience with Amazon. The interactive
>>>>> response could be (is often) horrible. (Personally, I would be doing email
>>>>> and working on a shared doc. The Amazon analogy probably applies to more
>>>>> people.)
>>>>>
>>>>> How can we deliver graceful performance to both persons in a household?
>>>>> Is seeking graceful performance too complicated to improve?
>>>>> (I said “graceful” to allow technical flexibility.)
>>>>>
>>>>> Gene
>>>>> ----------------------------------------------
>>>>> Eugene Chang
>>>>>
>>>>> _______________________________________________
>>>>> Starlink mailing list
>>>>> Starlink@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Starlink mailing list
>>>>> Starlink@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>
>>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

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

[-- Attachment #2: ECAF17B6-04A7-4DED-973C-06C041142505.png --]
[-- Type: image/png, Size: 3756844 bytes --]

Re: [Starlink] musings on disruption and competition [was] It’s the Latency, FCC

[Sebastian Moeller]

Hi Frank.

On 1 May 2024 09:27:37 CEST, Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net> wrote:
>Basically, Eugene, the situation you are describing is calling for a
>competitor to disrupt them!

[SM] Not a big fan of the silicon valley nomenclature... 'disruption' evokes thoughts of 'revolutionary' yet what typically happens is rather 'evolutionary' once one looks behind the marketing/hype... and that is not a bad thing, as real revolutions can be quite painful.
That said, sure if the incumbents leave sufficient specialized demand unfulfilled that opens a niche/opportunity for competitors, but that IMHO is one of the core promises of market economies, and nothing that silicon valley created/realized de novo, no?

>
>This is such an old story - so many ISPs, especially WIPSs, started just
>because they either didn't have any option or all those options available
>were really terrible.

[SM] Exactly, under serving real demand creates opportunities for those willing to step in!

>
>Don't you want to pick up the glove? :P

[SM] I would be terrible at it, for sure ;) but most importantly, the situation in Germany is not that bad, even without considering starlink (which given its relative high price, still leaves room for competitors). Only 5-10% of households are clearly underserved, in that they do not even get full sync with ADSL, and these tend to be far from the next CO and cabinet, so these are expensive to connect no matter the technology...
The EU (optimistic) plan to hook everyone up via FTTH until 2030 is going to be god sent for those households, and since most of these will be built with federal grants they come with (not fully specified) OpenAccess regulations, that might actually allow real competition in offering IA services over those fibers. But the same looming FTTH built out also makes it tough to invest much in alternative technology to reach those households in the interim.

>
>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 Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang <eugene.chang@ieee.org>
>wrote:
>
>> Frank,
>> Thank you. What you suggest makes sense if it was objective!
>>
>> In my neighborhood, the ISP’s organization will feel they have nothing to
>> learn from outsiders. (Worst, both major ISPs are just a subsidiary of
>> another organization. They just implement corporate standards. The local
>> managers are not motivated to deviate from their corporate marching orders.)
>>
>> A public promotion (campaign) of modern best practices is needed. Then I
>> need to have this campaign spill over to the subscriber community. The
>> business community needs to be educated that their productivity will
>> improve. The social leaders need to learn that their community will get
>> better service. Then, and only then, can I see the ISP feeling the need to
>> improve. It helps if the improvement is just open-source software on their
>> hardware investment.
>>
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <frantisek.borsik@gmail.com>
>> wrote:
>>
>> Eugene - the easiest thing in the case of your ISP would be tell him about
>> us: https://libreqos.io
>>
>> He can take a look on it, join our support chat and get help if he won't
>> be able to get it up and running:
>> https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
>>
>> But most of the ISPs don't need to talk with us at all, it's easy to
>> deploy.
>>
>>
>> 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 Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> OK. I need help teaching my ISPs that they can do this without
>>> threatening their business model.
>>> Who can help me?
>>>
>>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP
>>> adopted the lessons from the public demo, most of the latency issues would
>>> be solved? What won’t get fixed? How do we make this a widely adopted best
>>> practice? Am I crying over issues that are already fixed? Does this
>>> simplify the issues at the FCC?
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software for those that do not want to update their data
>>> plane. Perhaps we should do a public demo of what it can do for every tech
>>> on the planet. Dsl benefits, fiber does also (but it is the stats that
>>> matter more on fiber because the customer wifi becomes bloated)
>>>
>>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>>> think) to get the amazing results they are getting today. I don't have the
>>> waveform test results handy but they are amazing. I feel a sea change in
>>> the wind...
>>>
>>>
>>>
>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>>> Colin,
>>>> I am overwhelmed with all the reasons that prevent low(er) or consistent
>>>> latency.
>>>> I think that our best ISP offerings should deliver graceful, agile, or
>>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>>> practices fall short. Can we help them improve their service?
>>>>
>>>> Am I asking too much?
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> IEEE Life Senior Member
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>>> starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Gene,
>>>>
>>>> I think the lion's share of other people (many brilliant people here) on
>>>> this thread are focused on keeping latency down when under load. I
>>>> generally just read and don't contribute on those discussions, because
>>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>>> to detract from the importance of reducing latency, but to correct what I
>>>> believed to be an important error on minimum bandwidth required to be able
>>>> to perform standard Internet functions.
>>>>
>>>> To my surprise, there was pushback on the figure, so I've responded to
>>>> try to educate this group on streaming usage in the hope that the people
>>>> working on the latency problem under load (core reason for this group to
>>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>>> don't plan based on bad assumptions.
>>>>
>>>> For a single user, minimum bandwidth (independent of latency) needs to
>>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>>> Internet services. Anything short of that will deny users access to the
>>>> primary streaming services, and more specifically won't be able to watch 4K
>>>> HDR video, which is the market standard for streaming services today and
>>>> likely will remain at that level for the next several years.
>>>>
>>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>>> video (not everyone cares about that), but at least 25Mbps should be
>>>> available to an Internet customer for any new Internet service rollout.
>>>>
>>>> Cheers,
>>>> Colin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>>> starlink-request@lists.bufferbloat.net
>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>> To: starlink@lists.bufferbloat.net
>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>>> <starlink@lists.bufferbloat.net>
>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> I am always surprised how complicated these discussions become.
>>>> (Surprised mostly because I forgot the kind of issues this community care
>>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>>
>>>> While watching stream content, activating controls needed to switch
>>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>>> bloat and high latency.
>>>>
>>>> With a happy household user watching streaming media, a second user
>>>> could have terrible shopping experience with Amazon. The interactive
>>>> response could be (is often) horrible. (Personally, I would be doing email
>>>> and working on a shared doc. The Amazon analogy probably applies to more
>>>> people.)
>>>>
>>>> How can we deliver graceful performance to both persons in a household?
>>>> Is seeking graceful performance too complicated to improve?
>>>> (I said “graceful” to allow technical flexibility.)
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Starlink] musings on disruption and competition [was] It’s the Latency, FCC

[Eugene Y Chang]

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



> On Apr 30, 2024, at 10:48 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Hi Frank.
> 
> On 1 May 2024 09:27:37 CEST, Frantisek Borsik via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> Basically, Eugene, the situation you are describing is calling for a
>> competitor to disrupt them!
> 
> [SM] Not a big fan of the silicon valley nomenclature... 'disruption' evokes thoughts of 'revolutionary' yet what typically happens is rather 'evolutionary' once one looks behind the marketing/hype... and that is not a bad thing, as real revolutions can be quite painful.
> That said, sure if the incumbents leave sufficient specialized demand unfulfilled that opens a niche/opportunity for competitors, but that IMHO is one of the core promises of market economies, and nothing that silicon valley created/realized de novo, no?
> 

[EC]  I also dislike the term “disruption”.  It is just finding a hungry vendor that will fill the (our) need. I like a #3 that is trying to grow. Then if the larger vendor sees our goal is too insignificant to care, the smalller vendor will peel away (insignificant) market share and everyone is happy. If the smaller vendor starts taking away too much market share then the dominant vendor will change. This kind of change is better than talking to a dominant vendor sitting pretty.

Eugene Chang


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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Starlink] It’s the Latency, FCC

[Eugene Y Chang]

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

Pick up the glove?
I can be part of a team. I am not as close as to the equipment as I used to be.
I need help assembling a demo configuration that can engage the subscribers.
Building a local team for this has been very slow going.

I like helping a market #3 or #4 disrupt an incumbent. In most cases I have seen, the #2 already has a game plan for competing with #1. A distant #3 is usually the most hungry.

Gene.
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE Communications Society & Signal Processing Society,
    Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang@ieee.org
m 781-799-0233 (in Honolulu)



> On Apr 30, 2024, at 9:27 PM, Frantisek Borsik <frantisek.borsik@gmail.com> wrote:
> 
> Basically, Eugene, the situation you are describing is calling for a competitor to disrupt them!
> 
> This is such an old story - so many ISPs, especially WIPSs, started just because they either didn't have any option or all those options available were really terrible.
> 
> Don't you want to pick up the glove? :P
> 
> All the best,
> 
> Frank
> 
> Frantisek (Frank) Borsik
> 
> 
> 
> https://www.linkedin.com/in/frantisekborsik <https://www.linkedin.com/in/frantisekborsik>
> Signal, Telegram, WhatsApp: +421919416714
> 
> iMessage, mobile: +420775230885
> 
> Skype: casioa5302ca
> 
> frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>
> 
> On Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>> wrote:
> Frank,
> Thank you. What you suggest makes sense if it was objective!
> 
> In my neighborhood, the ISP’s organization will feel they have nothing to learn from outsiders. (Worst, both major ISPs are just a subsidiary of another organization. They just implement corporate standards. The local managers are not motivated to deviate from their corporate marching orders.)
> 
> A public promotion (campaign) of modern best practices is needed. Then I need to have this campaign spill over to the subscriber community. The business community needs to be educated that their productivity will improve. The social leaders need to learn that their community will get better service. Then, and only then, can I see the ISP feeling the need to improve. It helps if the improvement is just open-source software on their hardware investment.
> 
> 
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> 
> 
> 
>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>> wrote:
>> 
>> Eugene - the easiest thing in the case of your ISP would be tell him about us: https://libreqos.io <https://libreqos.io/>
>> 
>> He can take a look on it, join our support chat and get help if he won't be able to get it up and running: https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/ <https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/>
>> 
>> But most of the ISPs don't need to talk with us at all, it's easy to deploy.
>> 
>> 
>> All the best,
>> 
>> Frank
>> 
>> Frantisek (Frank) Borsik
>> 
>> 
>> 
>> https://www.linkedin.com/in/frantisekborsik <https://www.linkedin.com/in/frantisekborsik>
>> Signal, Telegram, WhatsApp: +421919416714
>> 
>> iMessage, mobile: +420775230885
>> 
>> Skype: casioa5302ca
>> 
>> frantisek.borsik@gmail.com <mailto:frantisek.borsik@gmail.com>
>> 
>> On Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>> OK. I need help teaching my ISPs that they can do this without threatening their business model.
>> Who can help me?
>> 
>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP adopted the lessons from the public demo, most of the latency issues would be solved? What won’t get fixed? How do we make this a widely adopted best practice? Am I crying over issues that are already fixed? Does this simplify the issues at the FCC?
>> 
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>> 
>> 
>> 
>> 
>>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>> wrote:
>>> 
>>> Just fq codel or cake everything and you get all that.
>>> 
>>> Libreqos is free software for those that do not want to update their data plane. Perhaps we should do a public demo of what it can do for every tech on the planet. Dsl benefits, fiber does also (but it is the stats that matter more on fiber because the customer wifi becomes bloated)
>>> 
>>> Starlink merely fq codeled their wifi and did some aqm work (not codel I think) to get the amazing results they are getting today. I don't have the waveform test results handy but they are amazing. I feel a sea change in the wind...
>>> 
>>> 
>>> 
>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>> Colin,
>>> I am overwhelmed with all the reasons that prevent low(er) or consistent latency.
>>> I think that our best ISP offerings should deliver graceful, agile, or nimble service. Sure, handle all the high-volume data. The high-volume service just shouldn’t preclude graceful service. Yes, the current ISP practices fall short. Can we help them improve their service?
>>> 
>>> Am I asking too much?
>>> 
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>> 
>>> 
>>> 
>>> 
>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:
>>>> 
>>>> Gene,
>>>> 
>>>> I think the lion's share of other people (many brilliant people here) on this thread are focused on keeping latency down when under load. I generally just read and don't contribute on those discussions, because that's not my area of expertise. I only posted my point on bandwidth, not to detract from the importance of reducing latency, but to correct what I believed to be an important error on minimum bandwidth required to be able to perform standard Internet functions.
>>>> 
>>>> To my surprise, there was pushback on the figure, so I've responded to try to educate this group on streaming usage in the hope that the people working on the latency problem under load (core reason for this group to exist) can also be aware of the minimum bandwidth needs to ensure they don't plan based on bad assumptions.
>>>> 
>>>> For a single user, minimum bandwidth (independent of latency) needs to be at least 25Mbps assuming the goal is to provide access to all standard Internet services. Anything short of that will deny users access to the primary streaming services, and more specifically won't be able to watch 4K HDR video, which is the market standard for streaming services today and likely will remain at that level for the next several years.
>>>> 
>>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR video (not everyone cares about that), but at least 25Mbps should be available to an Internet customer for any new Internet service rollout.
>>>> 
>>>> Cheers,
>>>> Colin
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net>> On Behalf Of starlink-request@lists.bufferbloat.net <mailto:starlink-request@lists.bufferbloat.net>
>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>> To: starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>
>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> 
>>>> Message: 1
>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>> From: Eugene Y Chang <eugene.chang@ieee.org <mailto:eugene.chang@ieee.org>>
>>>> To: Colin_Higbie <CHigbie1@Higbie.name <mailto:CHigbie1@Higbie.name>>, Dave Taht via Starlink
>>>> 	<starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>>
>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org <mailto:438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>>
>>>> Content-Type: text/plain; charset="utf-8"
>>>> 
>>>> I am always surprised how complicated these discussions become. (Surprised mostly because I forgot the kind of issues this community care about.) The discussion doesn’t shed light on the following scenarios.
>>>> 
>>>> While watching stream content, activating controls needed to switch content sometimes (often?) have long pauses. I attribute that to buffer bloat and high latency.
>>>> 
>>>> With a happy household user watching streaming media, a second user could have terrible shopping experience with Amazon. The interactive response could be (is often) horrible. (Personally, I would be doing email and working on a shared doc. The Amazon analogy probably applies to more people.)
>>>> 
>>>> How can we deliver graceful performance to both persons in a household?
>>>> Is seeking graceful performance too complicated to improve?
>>>> (I said “graceful” to allow technical flexibility.)
>>>> 
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> 
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>>> 
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
> 


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

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Starlink] It’s the Latency, FCC

[Dave Taht]

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

I agree the number 3s are the most motivated. For example I think mediatek
is doing a massive come from behind win vs Broadcom and Qualcomm in the
wifi ap market




On Wed, May 1, 2024, 12:26 PM Eugene Y Chang <eugene.chang@ieee.org> wrote:

> Pick up the glove?
> I can be part of a team. I am not as close as to the equipment as I used
> to be.
> I need help assembling a demo configuration that can engage the
> subscribers.
> Building a local team for this has been very slow going.
>
> I like helping a market #3 or #4 disrupt an incumbent. In most cases I
> have seen, the #2 already has a game plan for competing with #1. A distant
> #3 is usually the most hungry.
>
> Gene.
> ----------------------------------------------
> Eugene Chang
> IEEE Life Senior Member
> IEEE Communications Society & Signal Processing Society,
>     Hawaii Chapter Chair
> IEEE Life Member Affinity Group Hawaii Chair
> IEEE Entrepreneurship, Mentor
> eugene.chang@ieee.org
> m 781-799-0233 (in Honolulu)
>
>
>
> On Apr 30, 2024, at 9:27 PM, Frantisek Borsik <frantisek.borsik@gmail.com>
> wrote:
>
> Basically, Eugene, the situation you are describing is calling for a
> competitor to disrupt them!
>
> This is such an old story - so many ISPs, especially WIPSs, started just
> because they either didn't have any option or all those options available
> were really terrible.
>
> Don't you want to pick up the glove? :P
>
> 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 Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang <eugene.chang@ieee.org>
> wrote:
>
>> Frank,
>> Thank you. What you suggest makes sense if it was objective!
>>
>> In my neighborhood, the ISP’s organization will feel they have nothing to
>> learn from outsiders. (Worst, both major ISPs are just a subsidiary of
>> another organization. They just implement corporate standards. The local
>> managers are not motivated to deviate from their corporate marching orders.)
>>
>> A public promotion (campaign) of modern best practices is needed. Then I
>> need to have this campaign spill over to the subscriber community. The
>> business community needs to be educated that their productivity will
>> improve. The social leaders need to learn that their community will get
>> better service. Then, and only then, can I see the ISP feeling the need to
>> improve. It helps if the improvement is just open-source software on their
>> hardware investment.
>>
>>
>> Gene
>> ----------------------------------------------
>> Eugene Chang
>> IEEE Life Senior Member
>>
>>
>>
>> On Apr 30, 2024, at 11:35 AM, Frantisek Borsik <
>> frantisek.borsik@gmail.com> wrote:
>>
>> Eugene - the easiest thing in the case of your ISP would be tell him
>> about us: https://libreqos.io
>>
>> He can take a look on it, join our support chat and get help if he won't
>> be able to get it up and running:
>> https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
>>
>> But most of the ISPs don't need to talk with us at all, it's easy to
>> deploy.
>>
>>
>> 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 Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> OK. I need help teaching my ISPs that they can do this without
>>> threatening their business model.
>>> Who can help me?
>>>
>>> A public demo? Yes! Are you saying that if our (my) neighborhood ISP
>>> adopted the lessons from the public demo, most of the latency issues would
>>> be solved? What won’t get fixed? How do we make this a widely adopted best
>>> practice? Am I crying over issues that are already fixed? Does this
>>> simplify the issues at the FCC?
>>>
>>> Gene
>>> ----------------------------------------------
>>> Eugene Chang
>>> IEEE Life Senior Member
>>>
>>>
>>>
>>>
>>> On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software for those that do not want to update their
>>> data plane. Perhaps we should do a public demo of what it can do for every
>>> tech on the planet. Dsl benefits, fiber does also (but it is the stats that
>>> matter more on fiber because the customer wifi becomes bloated)
>>>
>>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>>> think) to get the amazing results they are getting today. I don't have the
>>> waveform test results handy but they are amazing. I feel a sea change in
>>> the wind...
>>>
>>>
>>>
>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>>> Colin,
>>>> I am overwhelmed with all the reasons that prevent low(er) or
>>>> consistent latency.
>>>> I think that our best ISP offerings should deliver graceful, agile, or
>>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>>> practices fall short. Can we help them improve their service?
>>>>
>>>> Am I asking too much?
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> IEEE Life Senior Member
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>>> starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Gene,
>>>>
>>>> I think the lion's share of other people (many brilliant people here)
>>>> on this thread are focused on keeping latency down when under load. I
>>>> generally just read and don't contribute on those discussions, because
>>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>>> to detract from the importance of reducing latency, but to correct what I
>>>> believed to be an important error on minimum bandwidth required to be able
>>>> to perform standard Internet functions.
>>>>
>>>> To my surprise, there was pushback on the figure, so I've responded to
>>>> try to educate this group on streaming usage in the hope that the people
>>>> working on the latency problem under load (core reason for this group to
>>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>>> don't plan based on bad assumptions.
>>>>
>>>> For a single user, minimum bandwidth (independent of latency) needs to
>>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>>> Internet services. Anything short of that will deny users access to the
>>>> primary streaming services, and more specifically won't be able to watch 4K
>>>> HDR video, which is the market standard for streaming services today and
>>>> likely will remain at that level for the next several years.
>>>>
>>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>>> video (not everyone cares about that), but at least 25Mbps should be
>>>> available to an Internet customer for any new Internet service rollout.
>>>>
>>>> Cheers,
>>>> Colin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>>> starlink-request@lists.bufferbloat.net
>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>> To: starlink@lists.bufferbloat.net
>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>>> <starlink@lists.bufferbloat.net>
>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> I am always surprised how complicated these discussions become.
>>>> (Surprised mostly because I forgot the kind of issues this community care
>>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>>
>>>> While watching stream content, activating controls needed to switch
>>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>>> bloat and high latency.
>>>>
>>>> With a happy household user watching streaming media, a second user
>>>> could have terrible shopping experience with Amazon. The interactive
>>>> response could be (is often) horrible. (Personally, I would be doing email
>>>> and working on a shared doc. The Amazon analogy probably applies to more
>>>> people.)
>>>>
>>>> How can we deliver graceful performance to both persons in a household?
>>>> Is seeking graceful performance too complicated to improve?
>>>> (I said “graceful” to allow technical flexibility.)
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>
>>
>

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