From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 159173B2A4 for ; Thu, 6 Jun 2024 03:42:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1717659721; x=1718264521; i=moeller0@gmx.de; bh=heXjHsEHVpfoH4xOMG86dSfLb/xHQ6io3BYqnMVl87Y=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=Bf+2D8zEnLBwOYINgtOjSyzfm7YqxRgyvWilLEE1GbOlDJ9762OAZjLHf+YPLEp+ LXXnk/Eel0wBlReutKYmFVRPCSI7uu9vhCe0yJ21P+JSxMHBonaJsmFIE+1fahnm/ pyd4YZHebPC2Nda6ibnR+ZEDVyGOsT+S3eVU6vHJVjAmmHV0d6xcuyeYDbX9csDdI FZPDrGnOX9+uUxlmI/Ug4N+1gIvKX2VCkWsoHOQUZdbYWW0nJXhN+qUdoj/kdPj6U 3nRWlQP8BJcHw180li0GRKYbWX5reT+HI49hrWf9mZI/PxpF+Rit6KMPsY7O00Ioq qQQazeCa9M3c6TV3nw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MgvvJ-1svtlU0ezt-00dnDS; Thu, 06 Jun 2024 09:42:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 6 Jun 2024 09:41:50 +0200 Cc: starlink Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC4AA2A-3B4D-4638-B515-92FC0EEC604F@gmx.de> To: =?utf-8?Q?David_Fern=C3=A1ndez?= X-Mailer: Apple Mail (2.3774.600.62) X-Provags-ID: V03:K1:jvQN8B3/nb5uKE1XQGpUJsxXrV7kCz3A9b+Wc1zqYShL1+OfAEt oZifouaRC9SxyQlZwDFg6jRDgkY2vHYhdGKLkJ3CjgIMwv3zjJK8ucVJ6ksxR8jtHb5+cQG Y6kzIu0/Cv6Qmt0VUVmW+FvSLn3iWCbD7e2z3klayvFEdbobFE9QyrH2U2f+33QzEay3jhX TpqljdGZvKBLWmE48QCDA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:fgXyxHa7AQ8=;3nfm+cX6OYHGXPIZ4T5fS8K6Zvd UCLyvXN7pQPLQUeuQhg3eWF9lpQ9TC0xIAme3S7EJMrHJrxQWNo3rPJCbIVOQtRi9bLSauOnz V6rBN5zoN6nEIMdf1RyJHYvrnNPIVfmLK1YjrGHr9xtAiLEbTEIZvZnJ17xXWq1cw9tqQbvFj hK2TNBrsR9YDnIFQkNthIRyJVuXufZUzj/5JV6Se504gvJyZjX7pMLXJu+0IJfRE8IFZYEbZ9 ldJEL0crjcyWnbGNNk7k+K42jfUtINqfhcWppE/GIGPHQLvHS4j8SsRlbpJx/Cuy0vdSNhAiJ npJWMnPfeKniO4nDHceu86uSmW/7gUDkKigQoGeiBRfYaemNqFY8jYJdadztFrwQW5HofOSQW H8VrdZT4RPJy+NNgJTT6oYfs1Iq1c/CY0CRX+iubhaqFQTybixEoQ1eQXuV9tqXyWnN4TjelG wm42Di4PLg1chIQ5P2bQ0/KN+SGJPjHPUvHp0OQ6B4SZD8Tu7SCRyrLX3xkqe7/Z0WwVruRva YMgYK/0pwY9OyEhfkVlmxKtouv/cEVSydbdGVcP6waPyHDPK9toRXxQXAkGttxVVO8dqKoC3X jlagJp91RH7DZ15UDKvdQ2bTqbE4jhLL6TBHK3xcj3Z30CE2iGVdVllOXjf24dHjOPyaFQpcr iqxA50LsbM3Shgh1CfqrOmcZ0DceX0j0t1DcgztCfOMelwCep3vUsw/SvkHXMntzTDiN27WOH dsjGuG6TQhZhvbH5iCF88TjVYDylQdhUdq5QxTmRt0+uVQ/tKzsTx2WDm2CeyUSDvU1VSp5+E wQDUWzuN0L5wj3DQ8wRbI3RyP6iu+djwe6UxrDPqUCH0c= Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2024 07:42:03 -0000 Hi David, > On 6. Jun 2024, at 09:07, David Fern=C3=A1ndez = wrote: >=20 > Hi Sebastian, >=20 > 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-b3f= 0-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.=20 [SM] They do, the minimal internet guarantees define the internet = service each inhabitant of Germany is entitled to receive (currently >=3D = 10/1.7 Mbps Down/UP, with <=3D150ms OWDs, or <=3D 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.=20 > 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-net= work-testing/network-performance-score/network-performance-score_250678.ht= ml#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 >=20 > Regards, >=20 > David F. >=20 > On Wed, 5 Jun 2024 at 18:23, Sebastian Moeller = wrote: > Hi David, >=20 > Thanks! >=20 > > On 5. Jun 2024, at 17:16, David Fern=C3=A1ndez via Starlink = wrote: > >=20 > > Hi Sebastian, > >=20 > > " Our local regulator thinks that 150 ms access network OWD (so = 300msRTT) is acceptable" > >=20 > > 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. >=20 > [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... >=20 > 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). >=20 > Regards > Sebastian >=20 > >=20 > > Regards, > >=20 > > David F. > >=20 > > Date: Wed, 5 Jun 2024 17:10:26 +0200 > > From: Sebastian Moeller > > To: David Lang > > Cc: Alexandre Petrescu , Dave Taht via > > Starlink > > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a = problem > > Message-ID: > > Content-Type: text/plain; charset=3Dutf-8 > >=20 > > Hi David, > >=20 > >=20 > > > On 5. Jun 2024, at 16:16, David Lang via Starlink = wrote: > > >=20 > > > Alexandre Petrescu wrote: > > >=20 > > >> Le 05/06/2024 =C3=A0 15:40, Gert Doering a =C3=A9crit : > > >>> Hi, > > >>>=20 > > >>> 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 :-) > > >>=20 > > >> sorry :-) Rather than simply 'satcom' I should have said = satcom-haps-planes-drones. I dont have a name for that. > > >=20 > > > 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. > > >=20 > > > 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. > >=20 > > 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...) > >=20 > > Sorry for the tangent... > >=20 > > Regards > > Sebastian > >=20 > > P.S.: Dave occasionally reminds us how 'slow' in comparison the = speed of sound is ~343 m/second (depending on conditions) or 343/1000 =3D = 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... > >=20 > > >=20 > > > David Lang_______________________________________________ > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink >=20 >=20