[Starlink] It’s the Latency, FCC

Tue Apr 30 18:31:07 EDT 2024

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 at 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 at lists.bufferbloat.net <mailto:starlink at 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 at gmail.com <mailto:dave.taht at gmail.com>>, Dave Taht via Starlink <starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>>
>> Cc: Colin_Higbie <CHigbie1 at higbie.name <mailto:CHigbie1 at higbie.name>>, libreqos <libreqos at lists.bufferbloat.net <mailto:libreqos at lists.bufferbloat.net>>
>> Reply-To: Frantisek Borsik <frantisek.borsik at gmail.com <mailto:frantisek.borsik at gmail.com>>
>> Sender: "Starlink" <starlink-bounces at lists.bufferbloat.net <mailto:starlink-bounces at 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 at gmail.com <mailto:frantisek.borsik at gmail.com>
>> 
>> On Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <starlink at lists.bufferbloat.net <mailto:starlink at 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 at lists.bufferbloat.net <mailto:starlink at 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 at lists.bufferbloat.net <mailto:starlink at 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 at lists.bufferbloat.net <mailto:starlink-bounces at lists.bufferbloat.net>> On Behalf Of starlink-request at lists.bufferbloat.net <mailto:starlink-request at lists.bufferbloat.net>
>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>> To: starlink at lists.bufferbloat.net <mailto:starlink at 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 at ieee.org <mailto:eugene.chang at ieee.org>>
>>> To: Colin_Higbie <CHigbie1 at Higbie.name <mailto:CHigbie1 at Higbie.name>>, Dave Taht via Starlink
>>> 	<starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>>
>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036 at ieee.org <mailto:438B1BC4-D465-497A-B6BA-700E1D411036 at 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 at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net <mailto:Starlink at lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/starlink
> 
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240430/422e5baa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 85252 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240430/422e5baa/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240430/422e5baa/attachment-0001.sig>