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

Wed May 1 09:57:35 EDT 2024

Yep. Better than starlink.

On Wed, May 1, 2024, 12:32 AM Brian Munyao Longwe via LibreQoS <
libreqos at 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 at 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 at gmail.com
>>
>>
>> On Tue, Apr 30, 2024 at 11:53 PM Eugene Y Chang <eugene.chang at 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 at 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 at gmail.com
>>>
>>>
>>> On Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink <
>>> starlink at 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 at 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 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> 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> On Behalf Of
>>>>> starlink-request at lists.bufferbloat.net
>>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>>> To: 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>
>>>>> To: Colin_Higbie <CHigbie1 at Higbie.name>, Dave Taht via Starlink
>>>>> <starlink at lists.bufferbloat.net>
>>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>>> Message-ID: <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
>>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Starlink mailing list
>>>>> 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
>>>>
>>>
>>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240501/e1f4df45/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ECAF17B6-04A7-4DED-973C-06C041142505.png
Type: image/png
Size: 3756844 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20240501/e1f4df45/attachment-0001.png>