From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 15F803B2A4 for ; Sat, 16 Mar 2024 15:46:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1710618368; x=1711223168; i=moeller0@gmx.de; bh=ibsKRO82k7+8AsA+LgBZM774+sZ5FBDiBs4/Q5N2QbU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=oZCuhZmlq6q4R2xasJdm64802kflvbCKj+B2qEaj1QILAtHlac6Gw3dKY2FlEoro WJTszyUQp3nyqEEV/ZggU7EF6qHJwxXotVJznqBMSdSKBeeGbjt8976a4CEXMHpHe URKjSkugBepyk0uyPto4xHfzI9P+INPJKY/jCm3/yd/lMeR9LV+gOLKvOarxfwxWH 4W0rXmzlEQ0aSto4xCwusdwuiMLiAE70bDgB2G49AFWV4oBuLkIdn+hEBNlHPRT5z WZ9H14AqMC3tNXwPyA4LuRv372rh8zJlnALOEhBjuC9KEqUKq+oWVXYiCXuwUPViU ZOFmRLpPZetHLnwBvw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MlNpH-1r4EtJ1hjZ-00lm76; Sat, 16 Mar 2024 20:46:08 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 16 Mar 2024 20:45:57 +0100 Cc: Dave Taht via Starlink Content-Transfer-Encoding: quoted-printable Message-Id: <61272BCC-B007-43B2-A0D9-F9A08416033B@gmx.de> References: <5CA23B3B-B3FB-4749-97BD-05D3A4552453@gmail.com> To: Colin_Higbie X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Provags-ID: V03:K1:wk+oVvyG67EKVQOePYUv/nT0C978os49eMIETLcH1g1ci3Rx+U5 Jn7xJcOmJ2+gimNxcB2HXLRoxkAFIR7wyWFO+xFn5zKcf8xRA2hzKkWLtJYpiGE1DhLggUJ 3PVJsO7bU9KFDzXeurb9RdM8Ekn3b0Tl0/6sccRrO8EJK6NY3DsiFdPmsuaZtDdJzxeTjIF AfkHOVpkQsVhxyi5D5nPQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:tWEDONuBHg0=;m4PJ5RIhEr++0eLnoBLAxTG5N0K GdAbb1TH75L3agWZB/yjB9zIIKRWT+ZI8h3Vxcrq7htDwqEsCQDsd2ONw1XFBsVTn7TC1cpHu 9x1RvGsGs/B9Mg0q0PLERCmY6LXMWwVt+NnMRbkYCj8a14N29GHL/WSSQCq7NP+RU/xdATm/Z QUsoghrIyuNfq+m+jrTUt2hYSOnjeNYKg29YYKoCwtNoU3nRGpnK0PijIutazbqOnXeJdX6uf ekHNwjA3nkkV+jgGblxVpnDyWlRFAuznL8FevsY8OW2ebtzbuWFBdNi4AW5x4qflM9RFiADVR juQ6hwaYYvTpDvQblqw9wGFkdhXFfbkGuCGg0U+iPh+XtPoURhG5s+nYlqdgr9SoTAMR5kvWA 0uWQVS8Zk/ogApw6S0cJ6mG8gjKS+VeYWihoqSBhoM1in4EaAgejV+AHIaR0/HWskMN+g3Jgn 7mdyLrCUt4DEuR13V7Enuh6UFskuA2ncUHj1ULWVcP3SQa6iJVc7ABK1sxwZI/ohBFWY/p8yR bidgefJdmbIA1spQSSeBXc2gd80Oz6ZhqLoprgaKk+i39Q3jCeyeHn+f2nakVgMaNk7gyNmp+ 1/FlaussbZciWSOWDEySCKHE2YjJvnc+xdjIa/h4TuP7tHRMPdSzaLK6onc4htEe3Dg3f7Y6P v0L5MkuUkIVHb5L+EyWIKpz2ouD/Li11x4+GlgTUQbE0/NYGO8QDOX28mdY1YWkx+wRSKBFb0 CGU3XQmlfaKfryQyYEji6LCYkj7Y7QNduTnSga/UyTh4R11TYRXl+bn1uxLCSTAfDfdkWSCY8 z/+DK2dsnVmA7SQaR4RIeEwhc3f+eyONyjOAs6vtCqezM= Subject: Re: [Starlink] =?utf-8?q?It=CA=BCs_the_Latency=2C_FCC?= 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: Sat, 16 Mar 2024 19:46:14 -0000 Hi Colin, > On 16. Mar 2024, at 20:26, Colin_Higbie wrote: >=20 > Sebastian, >=20 > Not sure if we're saying the same thing here or not. While I would = agree with the statement that all else being equal, lower latency is = always better than higher latency, there are definitely latency (and = bandwidth) requirements, where if the latency is higher (or the = bandwidth lower) than those requirements, the application becomes = non-viable. That's what I mean when I say it falls short of being "good = enough." >=20 > For example, you cannot have a pleasant phone call with someone if = latency exceeds 1s. Yes, the call may go through, but it's a miserable = UX. [SM] That is my point, miserable but still funktional, while running a = 100Kbps constant bitrate VoIP stream over a 50 Kbps link where the loss = will make thinks completely imperceivable... > For VoIP, I would suggest the latency ceiling, even under load, is = 100ms. That's a bit arbitrary and I'd accept any number roughly in that = ballpark. If a provider's latency gets worse than that for more than a = few percent of packets, then that provider should not be able to claim = that their Internet supports VoIP. [SM] Interestingly the ITU claims that one way mouth-to-ear delay up to = 200ms (aka 400ms RTT) results in very satisfied and up to 300ms OWD in = satisfied telephony customers (ITU-T Rec. G.114 (05/2003)). That is = considerably above your 100ms RTT. Now, I am still trying to find the = actual psychophysics studies the ITU used to come to that conclusion (as = I do not believe the numbers are showing what they are claimed to show), = but policy makers still look at these numbers an take them as valid = references. > If the goal is to ensure that Internet providers, including Starlink, = are going to provide Internet to meet the needs of users, it is = essential to understand the good-enough levels for the expected use = cases of those users.=20 >=20 > And we can do that based on the most common end-user applications: >=20 > Web browsing > VoIP > Video Conferencing > HD Streaming > 4K HDR Streaming > Typical Gaming > Competitive Gaming > And maybe throw in to help users: time to DL and UL a 1GB file [SM] Only if we think of latency as a budget, if I can competitively = play with a latency up to 100ms, any millisecond of delay I am spending = on the access link is not going to restrict my "cone" of players I can = match radius with by approximately 100Km... > Similarly, if we're going to evaluate the merits of government policy = for defining latency and bandwidth requirements to qualify for earning = taxpayer support, that comes down essentially to understanding those = good-enough levels. [SM] Here is the rub, for 100 Kbps VoIP it is pretty simple to = understand that it needs capacity >=3D 100 Kbps, but if competitive = gaming needs an RTT <=3D 100 ms, what is an ecceptable split between = access link and distance? >=20 > Cheers, > Colin >=20 > -----Original Message----- > From: Sebastian Moeller =20 > Sent: Saturday, March 16, 2024 3:10 PM > To: Colin_Higbie > Cc: David Lang ; Dave Taht via Starlink = > Subject: Re: [Starlink] It=CA=BCs the Latency, FCC >=20 >> ... >=20 > Well, for most applications there is an absolute lower capacity limit = below which it does not work, and for most there is also an upper limit = beyond which any additional capacity will not result in noticeable = improvements. Latency tends to work differently, instead of a hard cliff = there tends to be a slow increasing degradation... > And latency over the internet is never guaranteed, just as network = paths outside a single AS rarely are guaranteed...=20 > Now for different applications there are different amounts of delay = that users find acceptable, for reaction time gates games this will be = lower, for correspondence chess with one move per day this will be = higher. Conceptually this can be thought of as a latency budget that one = can spend on different components (access latency, transport latency, = latency variation buffers...), and and latency in the immediate access = network will eat into this budget irrevocably ... and that e.g. = restricts the "conus" of the world that can be reached/communicated = within the latency budget. But due to the lack of a hard cliff, it is = always easy to argue that any latency number is good enough and hard to = claim that any random latency number is too large. >=20 > Regards > Sebastian >=20 >=20