[Starlink] The "reasons" that bufferbloat isn't a problem

[Bless, Roland (TM)]

Hi,

On 05.06.24 at 17:16 David Fernández via Starlink wrote:
> " Our local regulator thinks that 150 ms access network OWD (so 
> 300msRTT) is acceptable"
> 
> Your local regulator is following ITU-T advice in Recommendation G.114, 
> where it is said that up to 150 ms one-way delay is acceptable for 
> telephony.

That is actually mouth-to-ear delay IIRC, so network delay is only a 
part of it. One has to consider play-buffering delay and codec delay
as well. Interactive gaming usually requires smaller delays for a good
QoE.

Regards,
  Roland

> Date: Wed, 5 Jun 2024 17:10:26 +0200
> From: Sebastian Moeller <moeller0 at gmx.de <mailto:moeller0 at gmx.de>>
> To: David Lang <david at lang.hm <mailto:david at lang.hm>>
> Cc: Alexandre Petrescu <alexandre.petrescu at gmail.com 
> <mailto:alexandre.petrescu at gmail.com>>, Dave Taht via
>          Starlink <starlink at lists.bufferbloat.net 
> <mailto:starlink at lists.bufferbloat.net>>
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD at gmx.de 
> <mailto:C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD at gmx.de>>
> Content-Type: text/plain;       charset=utf-8
> 
> Hi David,
> 
> 
>  > On 5. Jun 2024, at 16:16, David Lang via Starlink 
> <starlink at lists.bufferbloat.net <mailto:starlink at lists.bufferbloat.net>> 
> wrote:
>  >
>  > Alexandre Petrescu wrote:
>  >
>  >> Le 05/06/2024 à 15:40, Gert Doering a écrit :
>  >>> Hi,
>  >>>
>  >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via 
> Starlink
>  >> wrote:
>  >>>> well, ok.  One day the satcom latency will be so low that we will 
> not have
>  >>>> enough requirements for its use :-)
>  >>> Your disbelief in physics keeps amazing me :-)
>  >>
>  >> sorry :-)  Rather than simply 'satcom' I should have said 
> satcom-haps-planes-drones.  I dont have a name for that.
>  >
>  > you would be better off with plans that don't require beating the 
> speed of light. Yes, quantum entanglement may be a path to beat the 
> speed of light, but you still need the electronics to handle it, and 
> have the speed of sound at temperatures and pressures that humans can 
> live at as a restriction.
>  >
>  > by comparison to your 1ms latency goals, extensive AT&T phone testing 
> decades ago showed that 100ms was the threshold where people could start 
> to detect a delay.
> 
> Would you have any pointer for that study/those studies? Our local 
> regulator thinks that 150 ms access network OWD (so 300msRTT) is 
> acceptable and I am trying to find studies that can shed a light on what 
> acceptable delay is for different kind of interactive tasks. (Spoiler 
> alert, I am not convinced that 300ms RTT is a great idea, I forced my 
> self to remote desktop with artificial 300ms delay and it was not fun, 
> but not totaly unusable either, but then human can adapt and steer high 
> inertia vehicles like loaded container ships...)
> 
> Sorry for the tangent...
> 
> Regards
>          Sebastian
> 
> P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of 
> sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343 
> m/millisecond that is even at a distance of 1 meter delay will be at a 3 
> ms... and when talking to folks 10m away it is not the delay that is 
> annoying, but the fact that you have to raise your voice considerably...
> 
>  >
>  > David Lang_______________________________________________