[Starlink] Itʼs the Latency, FCC

[Sebastian Moeller]

Hi Colin,


> On 16. Mar 2024, at 20:26, Colin_Higbie <CHigbie1 at Higbie.name> wrote:
> 
> Sebastian,
> 
> Not sure if we're saying the same thing here or not. While I would agree with the statement that all else being equal, lower latency is always better than higher latency, there are definitely latency (and bandwidth) requirements, where if the latency is higher (or the bandwidth lower) than those requirements, the application becomes non-viable. That's what I mean when I say it falls short of being "good enough."
> 
> For example, you cannot have a pleasant phone call with someone if latency exceeds 1s. Yes, the call may go through, but it's a miserable UX.

[SM] That is my point, miserable but still funktional, while running a 100Kbps constant bitrate VoIP stream over a 50 Kbps link where the loss will make thinks completely imperceivable...


> For VoIP, I would suggest the latency ceiling, even under load, is 100ms. That's a bit arbitrary and I'd accept any number roughly in that ballpark. If a provider's latency gets worse than that for more than a few percent of packets, then that provider should not be able to claim that their Internet supports VoIP.

[SM] Interestingly the ITU claims that one way mouth-to-ear delay up to 200ms (aka 400ms RTT) results in very satisfied and up to 300ms OWD in satisfied telephony customers (ITU-T Rec. G.114 (05/2003)). That is considerably above your 100ms RTT. Now, I am still trying to find the actual psychophysics studies the ITU used to come to that conclusion (as I do not believe the numbers are showing what they are claimed to show), but policy makers still look at these numbers an take them as valid references.


> If the goal is to ensure that Internet providers, including Starlink, are going to provide Internet to meet the needs of users, it is essential to understand the good-enough levels for the expected use cases of those users. 
> 
> And we can do that based on the most common end-user applications:
> 
> Web browsing
> VoIP
> Video Conferencing
> HD Streaming
> 4K HDR Streaming
> Typical Gaming
> Competitive Gaming
> And maybe throw in to help users: time to DL and UL a 1GB file

[SM] Only if we think of latency as a budget, if I can competitively play with a latency up to 100ms, any millisecond of delay I am spending on the access link is not going to restrict my "cone" of players I can match radius with by approximately 100Km...


> Similarly, if we're going to evaluate the merits of government policy for defining latency and bandwidth requirements to qualify for earning taxpayer support, that comes down essentially to understanding those good-enough levels.

[SM] Here is the rub, for 100 Kbps VoIP it is pretty simple to understand that it needs capacity >= 100 Kbps, but if competitive gaming needs an RTT <= 100 ms, what is an ecceptable split between access link and distance?


> 
> Cheers,
> Colin
> 
> -----Original Message-----
> From: Sebastian Moeller <moeller0 at gmx.de> 
> Sent: Saturday, March 16, 2024 3:10 PM
> To: Colin_Higbie <CHigbie1 at Higbie.name>
> Cc: David Lang <david at lang.hm>; Dave Taht via Starlink <starlink at lists.bufferbloat.net>
> Subject: Re: [Starlink] Itʼs the Latency, FCC
> 
>> ...
> 
> Well, for most applications there is an absolute lower capacity limit below which it does not work, and for most there is also an upper limit beyond which any additional capacity will not result in noticeable improvements. Latency tends to work differently, instead of a hard cliff there tends to be a slow increasing degradation...
> And latency over the internet is never guaranteed, just as network paths outside a single AS rarely are guaranteed... 
> Now for different applications there are different amounts of delay that users find acceptable, for reaction time gates games this will be lower, for correspondence chess with one move per day this will be higher. Conceptually this can be thought of as a latency budget that one can spend on different components (access latency, transport latency, latency variation buffers...), and and latency in the immediate access network will eat into this budget irrevocably ... and that e.g. restricts the "conus" of the world that can be reached/communicated within the latency budget. But due to the lack of a hard cliff, it is always easy to argue that any latency number is good enough and hard to claim that any random latency number is too large.
> 
> Regards
> Sebastian
> 
>