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 ECF973B2A4 for ; Sat, 16 Mar 2024 13:36:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1710610615; x=1711215415; i=moeller0@gmx.de; bh=yFvPWvzdMVcPJK4gnqDNeUZymjvLfktsP82uAz8N8Lc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References: To; b=TrIWf13DREzIxlaw3ksi7I3Shkms4Wqjd1sRsEh7yHS7An5GWrsSm31aytiFuJp+ NotyBp4iUQVRB5gX2kdxx3NpVjBkAR46kuJjLvD4XJocR7wFy3gP31iSv+J3ap42P VpwPhFjuLFayzzvjXmb9rCrhA3JLcYRjonknGh61RVEuDT8rMQswmliVm4hkc56tj fuy7j5mE2Z5YJ+WR4Z3hDoj0rlUuMp8DhmsDOeZL/cwH1gwehi9EIrLmKt5qb56Tu zSE/jHJkyDGCrJ+qv3tHWU5TkyVYVG+H9QBVOl9VFwroX4hdSqSvOrXXYmUNtjuMA vQKxxirACGF9BBiikw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mplc7-1qzqna2foD-00qDFd; Sat, 16 Mar 2024 18:36:55 +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 18:36:44 +0100 Cc: Dave Taht via Starlink Content-Transfer-Encoding: quoted-printable Message-Id: References: <5CA23B3B-B3FB-4749-97BD-05D3A4552453@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Provags-ID: V03:K1:IqB6Cu7/xzJlMFRo9Gru9Ga7r3skM1gX2fKBneItBg/7xRIcS1U 3fpgr9ExGBLbNF2W05kI6wOw3E6AtI/NLwFyJ0StjUdA1tUm06SRyiuy8qzsbs6QYI2hD2L cQW1aTfJaX52A8PZjP27oj9jmtYyEUH5e0rkwTAekd0upKlpxg6lcWbPYh/DeHZ7DjFxP4n Kh7z07q6vD0bagf5kC2cw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:zSnaVn3Bwnw=;jUnWkdNYACsHkma3Y1XeuCI3SEZ JCIMoVd/Ki15f6YMF+tjjZQihoPinyQ5Q7E1BVDAtR2O4gIgf4VEi4BBe7w724GtamqcBfCdz vly3s3lohuNicIo8RVzVTrX5IW/Z/sy2UyAuvr511wKQDsWOMGSlsXWQzWzsAKZO82TFlb4v5 xxaLKPvcadBDmjpKj3qq4ocNQI55BFl4+f2TO97tSm5QMu89DsJmmwuvtz+0JkEVufl7vtHva o77jJRbaOdMkT7sLU2WlzeyrrDQ1XautkA8esWiJpDkjVacSJFuuvUzLP7V0qR1xBM2FZFlc/ 3aOHKOIT36rN3/bX8pnGvnRyjPBUNVqVImPvrIMWDgmURaWFf6WVK17Yx2qnOnBcJrFK9A/vm jJ9iCDZvFxl4gwNhor/lrKD2Ll75CVXwcPTeDvMiaxc67mvbwioIeZcYkWGCziFCA3JafKAZi PGgdmBS/AEzaAibRncOWw4Zw4qH8mwM7cMPUwsXSxXnAZw+HayPHLu0Wdo8iePjobB5KKhlcx Ceqnm+RDPVho3+fT61cn/IM2pkwzpde2NLdXxxnMCBcgafC/nF+fcmlhAJMjDTpOE5HePXQI5 59MXRYeWYXwk0ZlmPXQytvcKmsU+HUBohqKo6dJp0Z5BJjej6gWG+tCaofEXfOpCQMm91pAW6 wIjIHpQmYxjSW/mhrM2Af1QheJkzyeAuNdAdNCWIs47G6hAiRNeZHFBNP4Eggi4HDe8gGImWd guZqAhCQaxwip1KUqUGFcITw6HUjwUVRbCcyZMD3hCdf4wpgGn4ngKyeoI/uelTh/cDT1O/XO g0OJcNifj0WQiN+HylMioah6P3RhFpc+QHzUhj/umzh6w= Subject: Re: [Starlink] =?utf-8?q?It=E2=80=99s_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 17:36:58 -0000 Hi Alex... > On 16. Mar 2024, at 18:18, Alexandre Petrescu via Starlink = wrote: >=20 >=20 > Le 15/03/2024 =C3=A0 21:31, Colin_Higbie via Starlink a =C3=A9crit : >> Spencer, great point. We certainly see that with RAM, CPU, and = graphics power that the software just grows to fill up the space. I do = think that there are still enough users with bandwidth constraints = (millions of users limited to DSL and 7Mbps DL speeds) that it provides = some pressure against streaming and other services requiring huge swaths = of data for basic functions, but, to your point, if there were a mandate = that everyone would have 100Mbps connection, I agree that would then = quickly become saturated so everyone would need more. >>=20 >> Fortunately, the video compression codecs have improved dramatically = over the past couple of decades from MPEG-1 to MPEG-2 to H.264 to VP9 = and H.265. There's still room for further improvements, but I think = we're probably getting to a point of diminishing returns on further = compression improvements. Even with further improvements, I don't think = we'll see bandwidth needs drop so much as improved quality at the same = bandwidth, but this does offset the natural = bloat-to-fill-available-capacity movement we see. >=20 > I think the 4K-latency discussion is a bit difficult, regardless of = how great the codecs are. >=20 > For one, 4K can be considered outdated for those who look forward to = 8K and why not 16K; so we should forget 4K.=20 [SM] Mmmh, numerically that might make sense, however increasing the = resolution of video material brings diminishing returns in perceived = quality (the human optical system has limits...).... I remember well how = the steps from QVGA, to VGA/SD to HD (720) to FullHD (1080) each = resulted in an easily noticeable improvement in quality. However now I = have a hard time seeing an improvement (heck even just noticing) if I = see fullHD of 4K material on our 43" screen from a normal distance (I = need to do immediate A?B comparisons from short distance)....=20 I am certainly not super sensitive/picky, but I guess others = will reach the same point maybe after 4K or after 8K. My point is the = potential for growth in resolution is limited by psychophysics = (ultimately driven by the visual arc covered by individual = photoreceptors in the fovea). And I am not sure whether for normal = screen sizes and distances we do not already have past that point at = 4K.... > 8K is delivered from space already by a japanese provider, but not on = IP. So, if we discuss TV resolutions we should look at these (8K, 16K, = and why not 3D 16K for ever more strength testing). [SM] This might work as a gimmick for marketing, but if 16K does not = deliver clearly superior experience why bother putting in the extra = effort and energy (and storage size and network capacity) to actually = deliver something like that? >=20 > Second, 4K etc. are for TV. In TV the latency is rarely if ever an = issue. There are some rare cases where latency is very important in TV = (I could think of betting in sports, time synch of clocks) but they dont = look at such low latency as in our typical visioconference or remote = surgery [SM] Can we please bury this example please, "remote surgery" over the = best effort internet, is really really a stupid idea, or something that = should only ever be attempted as the very last effort. As a society we = already failed if we need to rely somthing like that. > or group music playing use-cases [SM] That IMHO is a great example for a realistic low latency use-case = (exactly because the failure mode is not as catastrophic as in tele = surgery, so this seems acceptable for a best effort network). > on Internet starlink. >=20 > So, I dont know how much 4K, 8K, 16K might be imposing any new latency = requirement on starlink. >=20 > Alex >=20 >>=20 >>=20 >> -----Original Message----- >> From: Spencer Sevilla >> Sent: Friday, March 15, 2024 3:54 PM >> To: Colin_Higbie >> Cc: Dave Taht via Starlink >> Subject: Re: [Starlink] It=E2=80=99s the Latency, FCC >>=20 >> Your comment about 4k HDR TVs got me thinking about the bandwidth = =E2=80=9Carms race=E2=80=9D between infrastructure and its clients. = It=E2=80=99s a particular pet peeve of mine that as any resource = (bandwidth in this case, but the same can be said for memory) becomes = more plentiful, software engineers respond by wasting it until it=E2=80=99= s scarce enough to require optimization again. Feels like an awkward = kind of malthusian inflation that ends up forcing us to buy = newer/faster/better devices to perform the same basic functions, which = haven=E2=80=99t changed almost at all. >>=20 >> I completely agree that no one =E2=80=9Cneeds=E2=80=9D 4K UHDR, but = when we say this I think we generally mean as opposed to a slightly = lower codec, like regular HDR or 1080p. In practice, I=E2=80=99d be = willing to bet that there=E2=80=99s at least one poorly programmed TV = out there that doesn=E2=80=99t downgrade well or at all, so the tradeoff = becomes "4K UHDR or endless stuttering/buffering.=E2=80=9D Under this = (totally unnecessarily forced upon us!) paradigm, 4K UHDR feels a lot = more necessary, or we=E2=80=99ve otherwise arms raced ourselves into a = TV that can=E2=80=99t really stream anything. A technical downgrade from = literally the 1960s. >>=20 >> See also: The endless march of =E2=80=9Csmart appliances=E2=80=9D and = TVs/gaming systems that require endless humongous software updates. My = stove requires natural gas and 120VAC, and I like it that way. Other = stoves require=E2=80=A6 how many Mbps to function regularly? Other food = for thought, I wonder how increasing minimum broadband speed = requirements across the country will encourage or discourage this = behavior among network engineers. I sincerely don=E2=80=99t look forward = to a future in which we all require 10Gbps to the house but can=E2=80=99t = do much with it cause it=E2=80=99s all taken up by lightbulb software = updates every evening /rant. >>=20 >>> On Mar 15, 2024, at 11:41, Colin_Higbie via Starlink = wrote: >>>=20 >>>> I have now been trying to break the common conflation that download = "speed" >>>> means anything at all for day to day, minute to minute, second to >>>> second, use, once you crack 10mbit, now, for over 14 years. Am I >>>> succeeding? I lost the 25/10 battle, and keep pointing at really >>>> terrible latency under load and wifi weirdnesses for many existing = 100/20 services today. >>> While I completely agree that latency has bigger impact on how = responsive the Internet feels to use, I do think that 10Mbit is too low = for some standard applications regardless of latency: with the more = recent availability of 4K and higher streaming, that does require a = higher minimum bandwidth to work at all. One could argue that no one = NEEDS 4K streaming, but many families would view this as an important = part of what they do with their Internet (Starlink makes this reliably = possible at our farmhouse). 4K HDR-supporting TV's are among the most = popular TVs being purchased in the U.S. today. Netflix, Amazon, Max, = Disney and other streaming services provide a substantial portion of 4K = HDR content. >>>=20 >>> So, I agree that 25/10 is sufficient, for up to 4k HDR streaming. = 100/20 would provide plenty of bandwidth for multiple concurrent 4K = users or a 1-2 8K streams. >>>=20 >>> For me, not claiming any special expertise on market needs, just my = own personal assessment on what typical families will need and care = about: >>>=20 >>> Latency: below 50ms under load always feels good except for some >>> intensive gaming (I don't see any benefit to getting loaded latency >>> further below ~20ms for typical applications, with an exception for >>> cloud-based gaming that benefits with lower latency all the way down >>> to about 5ms for young, really fast players, the rest of us won't be >>> able to tell the difference) >>>=20 >>> Download Bandwidth: 10Mbps good enough if not doing UHD video >>> streaming >>>=20 >>> Download Bandwidth: 25 - 100Mbps if doing UHD video streaming, >>> depending on # of streams or if wanting to be ready for 8k >>>=20 >>> Upload Bandwidth: 10Mbps good enough for quality video conferencing, >>> higher only needed for multiple concurrent outbound streams >>>=20 >>> So, for example (and ignoring upload for this), I would rather have = latency at 50ms (under load) and DL bandwidth of 25Mbps than latency of = 1ms with a max bandwidth of 10Mbps, because the super-low latency = doesn't solve the problem with insufficient bandwidth to watch 4K HDR = content. But, I'd also rather have latency of 20ms with 100Mbps DL, then = latency that exceeds 100ms under load with 1Gbps DL bandwidth. I think = the important thing is to reach "good enough" on both, not just excel at = one while falling short of "good enough" on the other. >>>=20 >>> Note that Starlink handles all of this well, including kids watching = YouTube while my wife and I watch 4K UHD Netflix, except the upload = speed occasionally tops at under 3Mbps for me, causing quality = degradation for outbound video calls (or used to, it seems to have = gotten better in recent months =E2=80=93 no problems since sometime in = 2023). >>>=20 >>> Cheers, >>> Colin >>>=20 >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/starlink >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink