From: Sebastian Moeller <moeller0@gmx.de>
To: "David Fernández" <davidfdzp@gmail.com>
Cc: starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Date: Thu, 6 Jun 2024 09:41:50 +0200 [thread overview]
Message-ID: <CD8852A5-8447-4CEA-95C1-4ACA71D87C97@gmx.de> (raw)
In-Reply-To: <CAC=tZ0pRFQh8S4adyDJqv8No=CDHHHh3FTvmz6082vAEOw3UdA@mail.gmail.com>
Hi David,
> On 6. Jun 2024, at 09:07, David Fernández <davidfdzp@gmail.com> wrote:
>
> Hi Sebastian,
>
> You are welcome! Your ISP seems to take the maximum limit also for RTT for RDP recommended by Microsoft users (300 ms RTT):
> https://learn.microsoft.com/en-us/archive/msdn-technet-forums/165af0fb-b3f0-469f-bc67-548fa26da266
> The good quality threshold for Remote Desktop could be 150 ms RTT.
[SM] Honestly the numbers from AWS/Azure are pretty useless as IMHO it is maximally unclear when/if the mean delay as in RTT and when as in OWD, and reading through this I am convinced that they are not talking exclusively about one or the other... And with all respect to the boffins at the cloud providers, for an interactive thing like remote desktop OWD makes very little sense... as a user expects to see reactions to all actions he/she initiates. But I am not looking to address this by saying "you (or rather the paid consultants writing the assessments) interpret the data wrong" I would rather like to present a "have you had a look at recent and pertinent study", so giving everybody a way of not loosing face...
> I find it risky to work so much close to the threshold of quality becoming bad for services, but they may have money based reasons to do that.
[SM] They do, the minimal internet guarantees define the internet service each inhabitant of Germany is entitled to receive (currently >= 10/1.7 Mbps Down/UP, with <=150ms OWDs, or <= 300ms RTT). ISPs will be forced to supply that at a 'reasonable price' (essentially the average price of the service class in Germany). BUT if the ISP can show that this results in losses the ISP will be 'made whole' out of state funds. So yes there is a cost component to this, and the official plan is (still) to reach 100% availability of gigabit plans by 2030, so it is expected these minimal guarantees to be rare in actual use.
> There is also no point on going better than the threshold of it being good, as mentioned here (it is wasteful):
> https://www.rohde-schwarz.com/fi/solutions/test-and-measurement/mobile-network-testing/network-performance-score/network-performance-score_250678.html#video-rs-636544
[SM] I guess that makes a ton of sense, as does not making the guaranteed minimus a gold-plated extravaganza... still remote desktop with 300ms RTT is decidedly little fun, and I would hope to be able to push this number down a peg... (150ms RTT IMHO wold be considerably less terrible even for a guaranteed minimum).
As is the 300ms RTT limit at least rules out geo stationary satellite as suitable providers.
And the cycle back the the topic of this list, LEO are well within that limit and starlink especially with the recent push for lower latency, pretty comfortably. Which is a good thing, as the regulator just tasked Starlink to supply one such case in which traditional ISPs could not deliver the minimal guarantees. The situation is a bit complicated in that the affected households are likely to receive FTTH by 2030 and none of the two fixed net ISP operating there prepared to deploy FTTH right now and made the argument that extending the copper network now only to switch to FTTH by 2030 would be a massive waste of resources...
Anyway, for the affected households starlink will be a decent solution allowing to comfortably wait for FTTH deployment...
Regards
Sebastian
>
> Regards,
>
> David F.
>
> On Wed, 5 Jun 2024 at 18:23, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi David,
>
> Thanks!
>
> > On 5. Jun 2024, at 17:16, David Fernández via Starlink <starlink@lists.bufferbloat.net> wrote:
> >
> > Hi Sebastian,
> >
> > " 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.
>
> [SM] Yes that is one of their sources for VoIP, and I already started to find the original studies as I am not convinced the interpretation in 114 is the only possible or even best, after all Telcos had a clear use-case transatlantic phone calls that they did want to survive as possible in good quality...
>
> But the regulator also argues the same 300ms RTT for remote desktop applications... any data showing what latency is acceptable for specific use cases is appreciated. (And I am open for the option that my hunch that 300ms is too much might be wrong).
>
> Regards
> Sebastian
>
> >
> > Regards,
> >
> > David F.
> >
> > Date: Wed, 5 Jun 2024 17:10:26 +0200
> > From: Sebastian Moeller <moeller0@gmx.de>
> > To: David Lang <david@lang.hm>
> > Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Dave Taht via
> > Starlink <starlink@lists.bufferbloat.net>
> > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> > Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>
> > Content-Type: text/plain; charset=utf-8
> >
> > Hi David,
> >
> >
> > > On 5. Jun 2024, at 16:16, David Lang via Starlink <starlink@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_______________________________________________
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
>
next prev parent reply other threads:[~2024-06-06 7:42 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 15:16 David Fernández
2024-06-05 15:21 ` Bless, Roland (TM)
2024-06-05 15:32 ` David Fernández
2024-06-05 16:24 ` Sebastian Moeller
2024-06-06 23:10 ` Michael Richardson
2024-06-07 1:39 ` David Lang
2024-06-07 6:20 ` Sebastian Moeller
2024-06-07 17:41 ` Eugene Y Chang
2024-06-07 17:51 ` David Lang
2024-06-07 20:09 ` Eugene Y Chang
2024-06-08 1:53 ` David Lang
2024-06-05 16:23 ` Sebastian Moeller
2024-06-06 7:07 ` David Fernández
2024-06-06 7:41 ` Sebastian Moeller [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-06-07 7:36 David Fernández
2024-06-05 14:46 David Fernández
2024-06-05 14:57 ` Vint Cerf
2024-06-06 17:12 ` Michael Richardson
2024-06-06 10:18 ` Alexandre Petrescu
2024-06-06 10:37 ` Aidan Van Dyk
2024-06-06 10:33 ` Alexandre Petrescu
2024-05-08 9:31 David Fernández
2024-05-07 12:13 David Fernández
2024-05-07 12:46 ` Dave Collier-Brown
2024-05-07 19:09 ` Eugene Y Chang
2024-05-07 19:11 ` Dave Taht
2024-05-07 19:14 ` Jeremy Austin
2024-05-07 19:46 ` Dave Taht
2024-05-07 20:03 ` Eugene Y Chang
2024-05-07 20:05 ` Frantisek Borsik
2024-05-07 20:25 ` Eugene Y Chang
[not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` [Starlink] It’s the Latency, FCC Colin_Higbie
2024-04-30 19:04 ` Eugene Y Chang
2024-05-01 0:36 ` David Lang
2024-05-01 1:30 ` [Starlink] Itʼs " Eugene Y Chang
2024-05-01 1:52 ` Jim Forster
2024-05-01 3:59 ` Eugene Y Chang
2024-05-01 4:12 ` David Lang
2024-05-01 18:51 ` Eugene Y Chang
2024-05-01 19:18 ` David Lang
2024-05-01 21:12 ` Eugene Y Chang
2024-05-01 21:27 ` Sebastian Moeller
2024-05-01 22:19 ` Eugene Y Chang
2024-05-06 11:25 ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
2024-05-06 12:11 ` Dave Collier-Brown
2024-05-07 0:43 ` Eugene Y Chang
2024-05-07 12:05 ` Dave Collier-Brown
[not found] ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
2024-05-06 19:47 ` Rich Brown
2024-05-07 0:38 ` Eugene Y Chang
2024-05-07 10:50 ` Rich Brown
2024-05-08 1:48 ` Dave Taht
2024-05-08 7:58 ` Frantisek Borsik
2024-05-08 8:01 ` Frantisek Borsik
2024-05-08 18:29 ` Eugene Y Chang
2024-06-04 18:19 ` Stuart Cheshire
2024-06-04 20:06 ` Sauli Kiviranta
2024-06-04 20:58 ` Eugene Y Chang
2024-06-05 11:36 ` Alexandre Petrescu
2024-06-05 13:08 ` Aidan Van Dyk
2024-06-05 13:28 ` Alexandre Petrescu
2024-06-05 13:40 ` Gert Doering
2024-06-05 13:43 ` Alexandre Petrescu
2024-06-05 14:16 ` David Lang
2024-06-05 15:10 ` Sebastian Moeller
2024-06-05 16:21 ` Alexandre Petrescu
2024-06-05 19:17 ` Eugene Y Chang
2024-06-04 23:03 ` Rich Brown
2024-06-06 17:51 ` Stuart Cheshire
2024-06-07 2:28 ` Dave Taht
2024-06-07 5:36 ` Sebastian Moeller
2024-06-07 7:51 ` Gert Doering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CD8852A5-8447-4CEA-95C1-4ACA71D87C97@gmx.de \
--to=moeller0@gmx.de \
--cc=davidfdzp@gmail.com \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox