From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 368463B2A4 for ; Thu, 6 Jun 2024 03:07:56 -0400 (EDT) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-52b8b7b8698so751319e87.1 for ; Thu, 06 Jun 2024 00:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717657675; x=1718262475; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CXTwGXGyDJNLeiznBtfNn2zZiizS3e98zeUL94dIIjE=; b=Qa7RxIb0Nw8GZ6HlvgSXrKWrYkt1iHcLnp6oi2DK81ohnCt7ZG8KzeKNvjxpwMoQlQ XHbbRiOixPVYHSfabM6M+O0kbvQ9CAiEWKtV71IRPFk2n9qW3mS1li8FnquFATELqEYH 6J4XCMUKD2pKht8bMsh7Nt4ZJ9P5/8rgRZ9yL6/ZDsRp+GAsa/CCiQrQurxrqTBx6DcM Fe9Xrmc2/4kCyV9Kbdw79Jmh4S1I7xlrxR8WoDub9BbbpyAMrGKN2hQaQMLjoK2iIXqC c8d8ZLlKOGcY8a6ZXPCXgL5sx6WqmHUaEgpiGVziOIYZ2TCxZXGbmvbkAFfoPK1VoWBq fMhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717657675; x=1718262475; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CXTwGXGyDJNLeiznBtfNn2zZiizS3e98zeUL94dIIjE=; b=tzoaXC2bQn5v+JG82tTyKzWLJeIuQVgpKWGJDdNcpdEHmfmcjWhKh2jbQw1TGsgAyi vMY9Ew/BKGoL/uVSsxK2t3rYjfX9EBFNI/VaSb8OBwiO2FCWOJXQYRNVWBRbJi3sRcX5 aCmqr7Z/m79ns/V850p96CJQWKD/DEDAKgEJghxiJmEeG9REohkD5Im6rHx6cJj2Gaqm A+ftkzwMydblPOkgYpkS2C5WSeEes6LBQ5l55pcOJfgPKNzljQr1jxkrJbPKW28ZdoSH BOhenFt1NGuQOTlLOM7Xf0DJqc/2HyYCjh7gTbherd+X+aQBST/TikAll+Mms6j6dzGk UIuA== X-Gm-Message-State: AOJu0YyehOhKL+J4yitCDuzXwR9+FG/JQM9b/O2psvak0kZuBnjy3RBn WKT/nzkN+1PKnveQy/ZvDlbM9IaitGR5doWwmh39DqX3mgaV08ApdheD6jgRoeMnqbeGHma/ZpI 4C32y//FPj5wLWvbeUALzOKQoErE= X-Google-Smtp-Source: AGHT+IGwREdwd44rHPx1tBx78lRdZZW30CwDODW9H5NmPdUlOXIeMa67t7CEOHVX50UJjqmxUPusO78Q3mKwJmX93qA= X-Received: by 2002:a2e:9dd0:0:b0:2ea:8f93:a49d with SMTP id 38308e7fff4ca-2eac7a526bemr26602941fa.38.1717657674257; Thu, 06 Jun 2024 00:07:54 -0700 (PDT) MIME-Version: 1.0 References: <4EC4AA2A-3B4D-4638-B515-92FC0EEC604F@gmx.de> In-Reply-To: <4EC4AA2A-3B4D-4638-B515-92FC0EEC604F@gmx.de> From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Thu, 6 Jun 2024 09:07:17 +0200 Message-ID: To: Sebastian Moeller Cc: starlink Content-Type: multipart/alternative; boundary="000000000000851b58061a335748" 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:07:56 -0000 --000000000000851b58061a335748 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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. 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-netw= ork-testing/network-performance-score/network-performance-score_250678.html= #video-rs-636544 Regards, David F. On Wed, 5 Jun 2024 at 18:23, Sebastian Moeller wrote: > Hi David, > > Thanks! > > > On 5. Jun 2024, at 17:16, David Fern=C3=A1ndez 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 go= od > 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 tha= t > 300ms is too much might be wrong). > > Regards > Sebastian > > > > > Regards, > > > > David F. > > > > 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 > > > > 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 =C3=A0 15:40, Gert Doering a =C3=A9crit : > > >>> 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 acceptab= le > 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 no= t > 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 o= f > 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... > > > > > > > > David Lang_______________________________________________ > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > > > --000000000000851b58061a335748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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):
The good quality thr= eshold for Remote Desktop could be 150 ms RTT.

I find it risky to work so much close to the= threshold of quality becoming bad for services, but they may have money ba= sed reasons to do that.=C2=A0
There is also no point on going bet= ter than the threshold of it being good, as mentioned here (it is wasteful)= :
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=C3=A1ndez via Starlink <starlink@list= s.bufferbloat.net> wrote:
>
> Hi Sebastian,
>
> " Our local regulator thinks that 150 ms access network OWD (so 3= 00msRTT) 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 teleph= ony.

[SM] Yes that is one of their sources for VoIP, and I already started to fi= nd 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 trans= atlantic phone calls that they did want to survive as possible in good qual= ity...

But the regulator also argues the same 300ms RTT for remote desktop applica= tions... 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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Starlink <starlink@lists.bufferbloat.net<= /a>>
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn&#= 39;t a problem
> Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de&= gt;
> Content-Type: text/plain;=C2=A0 =C2=A0 =C2=A0 =C2=A0charset=3Dutf-8 >
> Hi David,
>
>
> > On 5. Jun 2024, at 16:16, David Lang via Starlink <starlink@lists.buf= ferbloat.net> wrote:
> >
> > Alexandre Petrescu wrote:
> >
> >> Le 05/06/2024 =C3=A0 15:40, Gert Doering a =C3=A9crit :
> >>> Hi,
> >>>
> >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petre= scu via Starlink
> >> wrote:
> >>>> well, ok.=C2=A0 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 :-)=C2=A0 Rather than simply 'satcom' I should = have said satcom-haps-planes-drones.=C2=A0 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 sp= eed 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 reg= ulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable an= d I am trying to find studies that can shed a light on what acceptable dela= y is for different kind of interactive tasks. (Spoiler alert, I am not conv= inced that 300ms RTT is a great idea, I forced my self to remote desktop wi= th artificial 300ms delay and it was not fun, but not totaly unusable eithe= r, but then human can adapt and steer high inertia vehicles like loaded con= tainer ships...)
>
> Sorry for the tangent...
>
> Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sebastian
>
> P.S.: Dave occasionally reminds us how 'slow' in comparison th= e 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 a= nnoying, but the fact that you have to raise your voice considerably...
>
> >
> > David Lang_______________________________________________
> _______________________________________________
> Starlink mailing list
> St= arlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink<= /a>


--000000000000851b58061a335748--