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

[Jim Forster <jim@connectivitycap.com>]

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

Gene, David,

Agreed that the technical problem is largely solved with cake & codel.

Also that demos are good. How to do one for this problem>

  — Jim

> The bandwidth mantra has been used for so long that a technical discussion cannot unseat the mantra.
> Some technical parties use the mantra to sell more, faster, ineffective service. Gullible customers accept that they would be happy if they could afford even more speed.
> 
> Shouldn’t we create a demo to show the solution?
> To show is more effective than to debate. It is impossible to explain to some people.
> Has anyone tried to create a demo (to unseat the bandwidth mantra)? 
> Is an effective demo too complicated to create?
> I’d be glad to participate in defining a demo and publicity campaign.
> 
> Gene
> 
> 
>> On Apr 30, 2024, at 2:36 PM, David Lang <david@lang.hm <mailto:david@lang.hm>> wrote:
>> 
>> On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote:
>> 
>>> 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.)
>> 
>> it's largely a solved problem from a technical point of view. fq_codel and cake solve this.
>> 
>> The solution is just not deployed widely, instead people argue that more bandwidth is needed instead.


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