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

[David Lang <david@lang.hm>]

On Sat, 16 Mar 2024, Colin_Higbie wrote:

> At the same time, I do think if you give people tools where latency is rarely 
> an issue (say a 10x improvement, so perception of 1/10 the latency), 
> developers will be less efficient UNTIL that inefficiency begins to yield poor 
> UX. For example, if I know I can rely on latency being 10ms and users don't 
> care until total lag exceeds 500ms, I might design something that uses a lot 
> of back-and-forth between client and server. As long as there are fewer than 
> 50 iterations (500 / 10), users will be happy. But if I need to do 100 
> iterations to get the result, then I'll do some bundling of the operations to 
> keep the total observable lag at or below that 500ms.

I don't think developers think about latency at all (as a general rule)

they develop and test over their local lan, and assume it will 'just work' over 
the Internet.

> In terms of user experience (UX), I think of there as being "good enough" 
> plateaus based on different use-cases. For example, when web browsing, even 
> 1,000ms of latency is barely noticeable. So any web browser application that 
> comes in under 1,000ms will be "good enough." For VoIP, the "good enough" 
> figure is probably more like 100ms. For video conferencing, maybe it's 80ms 
> (the ability to see the person's facial expression likely increases the 
> expectation of reactions and reduces the tolerance for lag). For some forms of 
> cloud gaming, the "good enough" figure may be as low as 5ms.

1 second for the page to load is acceptable (ot nice), but one second delay in 
reacting to a clip is unacceptable.

As I understand it, below 100ms is considered 'instantanious response' for most 
people.

> That's not to say that 20ms isn't better for VoIP than 100 or 500ms isn't 
> better than 1,000 for web browsing, just that the value for each further 
> incremental reduction in latency drops significantly once you get to that 
> good-enough point. However, those further improvements may open entirely new 
> applications, such as enabling VoIP where before maybe it was only "good 
> enough" for web browsing (think geosynchronous satellites).

the problem is that latency stacks, you click on the web page, you do a dns 
lookup for the page, then a http request for the page contents, which triggers a 
http request for a css page, and possibly multiple dns/http requests for 
libraries

so a 100ms latency on the network can result in multiple second page load times 
for the user (even if all of the content ends up being cached already)

<snip a bunch of good discussion>

> So all taken together, there can be fairly straightforward descriptions of 
> latency and bandwidth based on expected usage. These are not mysterious 
> attributes. It can be easily calculated per user based on expected use cases.

however, the lag between new uses showing up and changes to the network driven 
by those new uses is multiple years long, so the network operators and engineers 
need to be proactive, not reactive.

don't wait until the users are complaining before upgrading bandwidth/latency

David Lang