From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 441E03B2A4 for ; Wed, 5 Jun 2024 12:25:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1717604699; x=1718209499; i=moeller0@gmx.de; bh=fl4u1BMFwmohYOq+ZU8ohVmaXdgQquMQCvUxRGCLeAY=; 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=Mnw8sINarMTKyN7VqI0XOGq8OUXOCJ4C6C5pbYftqYR+Su9u7X6+kYrCQfmUoc3V 0Bpe6+LdWXRDCXW/1iAG3sHJHeIv8GIge7BO9VdnORGWeLM2RgQTR4OdFI25Y3qZj yMhfGVvOYhTbKMWefnFld8Z8GeZGjxqMYdhh4bEwbUYmraPA79Vqq2lq5FT3YGFml TRWkbxekDrVj0kgU/CQgKDJA/kEMau9g9y32KRRJPvb1UOoip2eoZMt7tq/3biQ5J aSdhnTidg5ezudASypVhvolkYFRsto/Hna7ODX882k4pIQttP3Hr9y/H0fQG90gzn ffLmDADOqeiUG1L+BQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([95.116.173.22]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MsYqv-1sZSSn3EB1-014WkB; Wed, 05 Jun 2024 18:24:58 +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: <467ccff0-5586-4b9f-b656-e1aa3d1865b4@kit.edu> Date: Wed, 5 Jun 2024 18:24:48 +0200 Cc: =?utf-8?Q?David_Fern=C3=A1ndez?= , starlink Content-Transfer-Encoding: quoted-printable Message-Id: <2F613DF8-3F06-4355-82F6-5543565DFE4A@gmx.de> References: <467ccff0-5586-4b9f-b656-e1aa3d1865b4@kit.edu> To: "Bless, Roland (TM)" X-Mailer: Apple Mail (2.3774.600.62) X-Provags-ID: V03:K1:uosZfznLGSCaPFvzoUQfvTIMDeOND49OyGYOd7U4NKCgSSpNQfd VqnnyBBaaBml6m5vQlrzNBmQT6dTcmbfCrHBFNekSCIKZd8ITL4+4WZKq3GTr+k4cai2i4/ PTrDxMvWxuy/nRIoDuCqkr8Gq9NFr9Wb/qh4ocFj5YC24NA9YmGbm6S3XRDrfIrlwadRVIR NwZFPRWwwf+tjYDtXBjIA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:gqmDF0bUtlU=;BFqGntq+ZB4FoxbN1nd1AcF0hRS 5agayln2jzpMEQU8ZObA13+HiKXRU5aDbDxan+7JT+u5ZkRH4sKSDHCQ40RGSLx6wQ8gXwygs PYjwxpVGWygPiT0YZO1vVAIz9XI4pANzkmSY80OKIMKSxFuzdK1GHZlzdLqDedBuwcScBeZUD YsrjkUiP4hnk1VMFj9dw+eHwr4ZpoJYWxAbSbPtMD2aGH//k4nNfxj8WTD6O12T3P7qTc0e+s piMzNcCQEHzBaVnfbTvT1UK1xrvH3rv8WeO2UuHg2joj4lBRaAdKwln7X7yZuBmglWWW8s6VE 7NIZeGrJsho74ZHEr0MD8OOBYOlfn89WNMbEbqC4gd5Xmb6TGQnHSGzg6245p69LmC0sx8ENh Rl9wPp2WqBGZLbi74gBxEJsTvGsbsIopE1hKKrBHQ2YCy+IgO+7sCmSqXvIV2eJyxSRpeHoBN YRuaxicz/tgbwV58I/WOt5pEX1qb9+cUa0zjVjeL77VrcuHvPsZPg+Pfgn6qibwLBTQFGShp1 67e8b7wUQzl8A3pKmwefvdvyCT7ASaFsy0Kf4mQNOkJjkl+JOG9EgwghkmM9gyCOdSaPmZ0DJ mGDNzwu7w2uG+ImfDlbsQykaEnyIdyJFgGBwP5PJOmxMzqJpb+DCAY8JG9AgVu58cbIe52i/h ldIQ0IHsGfgi7eQ+hjWT2VM7Njmao5kb5uVZWACwJ+gndEEYtxVPXihLu2ngoAhWkXFWkMtNi o12B+Gt85n9JX9VaZuPrQZQf152fY+XxOgosqTRQvx0QAz+93RSiP98C9JSR2UjWOO9kvbiIM 9Iwb0jlKyWLClqi+whuFoyOZP8+o8b+OqzmeCnijXpJJc= 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: Wed, 05 Jun 2024 16:25:02 -0000 Hi Roland, Thanks! > On 5. Jun 2024, at 17:21, Bless, Roland (TM) via Starlink = wrote: >=20 > Hi, >=20 > On 05.06.24 at 17:16 David Fern=C3=A1ndez 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. >=20 > 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. [SM] Yes, however Gaming is not in the enumerated list of use-cases the = regulator cares about (in the context of the minimal internet quality = end users are guaranteed). >=20 > Regards, > Roland >=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 >> Hi David, >> > On 5. Jun 2024, at 16:16, David Lang via Starlink = > = 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 = 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 =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_______________________________________________ >=20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink