Colin, I am overwhelmed with all the reasons that prevent low(er) or consistent latency. I think that our best ISP offerings should deliver graceful, agile, or nimble service. Sure, handle all the high-volume data. The high-volume service just shouldn’t preclude graceful service. Yes, the current ISP practices fall short. Can we help them improve their service?
Am I asking too much? Gene ---------------------------------------------- Eugene Chang IEEE Life Senior Member > On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink > <starlink@lists.bufferbloat.net> wrote: > > Gene, > > I think the lion's share of other people (many brilliant people here) on this > thread are focused on keeping latency down when under load. I generally just > read and don't contribute on those discussions, because that's not my area of > expertise. I only posted my point on bandwidth, not to detract from the > importance of reducing latency, but to correct what I believed to be an > important error on minimum bandwidth required to be able to perform standard > Internet functions. > > To my surprise, there was pushback on the figure, so I've responded to try to > educate this group on streaming usage in the hope that the people working on > the latency problem under load (core reason for this group to exist) can also > be aware of the minimum bandwidth needs to ensure they don't plan based on > bad assumptions. > > For a single user, minimum bandwidth (independent of latency) needs to be at > least 25Mbps assuming the goal is to provide access to all standard Internet > services. Anything short of that will deny users access to the primary > streaming services, and more specifically won't be able to watch 4K HDR > video, which is the market standard for streaming services today and likely > will remain at that level for the next several years. > > I think it's fine to offer lower-cost options that don't deliver 4K HDR video > (not everyone cares about that), but at least 25Mbps should be available to > an Internet customer for any new Internet service rollout. > > Cheers, > Colin > > > -----Original Message----- > From: Starlink <starlink-boun...@lists.bufferbloat.net> On Behalf Of > starlink-requ...@lists.bufferbloat.net > Sent: Tuesday, April 30, 2024 3:05 PM > To: starlink@lists.bufferbloat.net > Subject: Starlink Digest, Vol 37, Issue 15 > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 30 Apr 2024 09:04:43 -1000 > From: Eugene Y Chang <eugene.ch...@ieee.org> > To: Colin_Higbie <chigb...@higbie.name>, Dave Taht via Starlink > <starlink@lists.bufferbloat.net> > Subject: Re: [Starlink] It’s the Latency, FCC > Message-ID: <438b1bc4-d465-497a-b6ba-700e1d411...@ieee.org> > Content-Type: text/plain; charset="utf-8" > > I am always surprised how complicated these discussions become. (Surprised > mostly because I forgot the kind of issues this community care about.) The > discussion doesn’t shed light on the following scenarios. > > While watching stream content, activating controls needed to switch content > sometimes (often?) have long pauses. I attribute that to buffer bloat and > high latency. > > With a happy household user watching streaming media, a second user could > have terrible shopping experience with Amazon. The interactive response could > be (is often) horrible. (Personally, I would be doing email and working on a > shared doc. The Amazon analogy probably applies to more people.) > > How can we deliver graceful performance to both persons in a household? > Is seeking graceful performance too complicated to improve? > (I said “graceful” to allow technical flexibility.) > > Gene > ---------------------------------------------- > Eugene Chang > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
