From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 D372B3B29D for ; Tue, 4 Jun 2024 16:07:04 -0400 (EDT) Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-52b992fd796so1781301e87.0 for ; Tue, 04 Jun 2024 13:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717531623; x=1718136423; 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=+xmfjzPzZzEr/Pwmsedk+eoD/nJPBDNiqsPxLKVWt+w=; b=Y+etspO9c5XOaWMTDOO5bYFFg/G+172gCVQ1XMGslUpceuf6kEY9VjyCHtgjEJgFDx LYTPWp0bDSHCJ83YhrADtvmWQi2ooZHOENNHMxSdwN1T9cWeK01SDwZGZQbIJz0+kb8q VDKNxMM9q4+m+Zz/oZAKE7H9JUnrq3B7VGMsU6YBdDsJwvRGyazjgMtNMIZOIynoygvN 6pl3GlnV/Z9JXD51Nf/pSHmq/b/pumpPyTA8dZSnS4g7o5C3U1Fag4K7XSZ/CHQDNYNa MzlFIOkS88mVozzyGwm9Du9xwTCEGAjn5g5BnWUNkakk+pmBWhS1w+7ylmro4FH9z2oR lMBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717531623; x=1718136423; 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=+xmfjzPzZzEr/Pwmsedk+eoD/nJPBDNiqsPxLKVWt+w=; b=G4noUL0+8/ocKYPKtRLjd3P6Fpdnn3qvmosWBEk3jYHEZYGLIxpKVgWMOu4EvBNvrW 65YJoguXzJFnbiIFBlKxddRJpf4en6cvmQtDaOF/YUh9MDoIumHurYm2fk5X0dYbkpSJ w5WM7lpJUeDlBW93o71HKFTDcvpEiQANeAVVktODsmTbb47FFmUVid5TSt0IqntpUbYT w5Ks+kL0MyRa5VL5Ps34OY0qFK+n+8mfcboLjApl21xUXhOr+xu+Yh9KCDB/QKj5XnZR YtaVOOOkvE/hyN8fjXD3/VjH55ZpEkogLos6oJMpQJ5wY41uWhIh46gBDC0pYWmbvJM5 ft4g== X-Forwarded-Encrypted: i=1; AJvYcCWVVR/49K0MJTriIJ1pycUZ5ac0mmqPfXAwFJqlTDsTdsKypWnp+pLLoBmgvDbahXuwZvFzwF7+ZvLhvq9kuAQSBK+K7N/7iyYT57izbKg= X-Gm-Message-State: AOJu0Yw5yNBybntHUvoTDX7Dp40BXLd5BZL8GTsn19eBFMlOoUGJ77ey A5TXSbqGk2z4bOLikEGuMozAK+9h91drXvpgN1s9frfXZ3Nx0DAwvSiIF6NV4ggWNaipaZq2St+ W5Dt1RP8T52DgxH2O2VYojliEjoPN41Yi X-Google-Smtp-Source: AGHT+IEm7WVEZA3tNStCZpiPF1NCK9rlKfK9dawQSdrpGloEF8EYui+OnuxXvgOk/fs0nUkR3UenjbKF014vfQChLLY= X-Received: by 2002:a05:6512:214c:b0:52b:81de:1127 with SMTP id 2adb3069b0e04-52bab502198mr298737e87.50.1717531623181; Tue, 04 Jun 2024 13:07:03 -0700 (PDT) MIME-Version: 1.0 References: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org> <79C02ABB-B2A6-4B4D-98F4-6540D3F96EBB@ieee.org> <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com> <13rq2389-9012-p95n-s494-q3pp070s497n@ynat.uz> <6qop2p3o-351p-788q-q1q2-86sosnq3rn21@ynat.uz> <3FF32F52-4A93-496B-85FF-00020FA4A48B@gmx.de> <08F6942E-CC08-4956-B92E-CBEC091D86E4@ieee.org> <2F510BD5-2D7E-4A6A-A3DE-C529D14F6FBC@apple.com> In-Reply-To: <2F510BD5-2D7E-4A6A-A3DE-C529D14F6FBC@apple.com> From: Sauli Kiviranta Date: Tue, 4 Jun 2024 23:06:51 +0300 Message-ID: To: Stuart Cheshire Cc: Rich Brown , Dave Taht via Starlink , Colin_Higbie Content-Type: multipart/alternative; boundary="0000000000004a5759061a15fe4b" 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: Tue, 04 Jun 2024 20:07:05 -0000 --0000000000004a5759061a15fe4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good examples Stuart, it is quite interesting that as humanity we have not come up with aggregate term what would fairly collapse the dimensions to one single metric that would describe the snappy feeling we intuitively seek for but can not quite verbalize. Vehicles have the same issues, we have top speed (F1 at 360mph feels fast compared to Starship at 16000mph), we have acceleration (Hot-rod going 0 to 60 mph in 5 seconds feels high but pales in comparison to Tesla going 0 to 60 mph in 2 sec), we have horse powers (tractor plowing field with 300hp feels great but seems small compared to 1000hp of Hot-rod) then also there is torque (tractor with 1450 Nm of torque wins a Tesla having 900Nm on wheel while at completely different torque curve). Capacity has the same issue as literally the truck from your example shipping magnetic tapes for "raw carry capacity" but it does not feel responsive, snappy, good to handle in the "traffic" of Internet. We have jitter, that could be compared to how a vehicle does in repeatability of track laps? We have packet loss on how the car handles on curves and does it slip off the track or on accelerations spin the wheels? Download is speed forward, upload is almost like speed at reverse gear usually far worse. Latency is like a lap track as such, depends on the track, use-case specific tests "What time did it do on N=C3=BCrburgring?" or "How fast does= it go from 0 to 60Mbps? Less than 200ms?". Horse power feels much like raw capacity of the HW / radio channel and techniques available beam forming, frequencies etc. what was discussed here related to Starlink and even collectively across different technologies. Speed is then instead of how much specific combination of modem and base-station combo can achieve at certain configuration? Torque feels like ability to maintain that performance, closest we get is loaded performance in context of bufferbloat? Watching videos on Netflix require different performance characteristics than downloading a big update to Fortnite. One has certain acceleration need to have snappy user experience but focus is more on connection stability at certain bitrate. On the other hand Fortnite update you want to be delivered at brute force speeds without ruining others user experience. Maybe we can not find that aggregate property or metric, but just need to be rigorous on making sure we accurately characterize each dimension and standardize them so the confusion and play with words, specially with marketing, get stabilized. Each needs to have standardized benchmarks much like 3D rendering benchmarks and PC perf tests are done? All that said, as I failed to come up with a perfect term, "varying performance ISP links" feels like the right thing to say? Now we have obfuscated to be able to throw any of the dimensions underneath. Only thing left for us to do is then to provide those dimensions like a nutrient labels. We are getting there? Nothing new under the sun also to some extend. Just as a funny side note on the tractor marketing: =E2=80=9DTorque gives you the feeling of responsiveness and that the machin= e does the right things,=E2=80=9D Tapani Katila encapsulates his view. =E2=80=9CTh= e torque is directly linked to the feeling of having power available in the entire range of the power curve, resulting in more meaningful work.=E2=80=9D from https://www.agcopower.com/power-is-important-but-torque-is-crucial/ Seems like some other people are also trying to figure out what dimensions to showcase to customers? Thank you for the thought provoking examples! Is bufferbloat property of a vehicle or characteristic of the road design? Is it a question of ICE vs EV -or- roundabout vs crossing with traffic lights? Feels more like a roundabout, no? Is this the problem behind the objections? - Sauli On Tue, Jun 4, 2024 at 9:19=E2=80=AFPM Stuart Cheshire via Starlink < starlink@lists.bufferbloat.net> wrote: > On May 7, 2024, at 18:48, Dave Taht via Starlink < > starlink@lists.bufferbloat.net> wrote: > > > This was a wonderful post, rich! > > < > https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-p= roblem/ > > > > I agree. Thanks for writing this Rich. > > One minor change I will request. Any time you write words like =E2=80=9Cs= peed=E2=80=9D or > =E2=80=9Cfast=E2=80=9D, pause and consider whether it would be more accur= ate to use some > other term like =E2=80=9Ccapacity=E2=80=9D, =E2=80=9Cbandwidth=E2=80=9D, = or =E2=80=9Cthroughput=E2=80=9D. Part of what > keeps us in this mess is that people equate network capacity with =E2=80= =9Cspeed=E2=80=9D, > as if those terms were synonyms. We can=E2=80=99t change how people think > overnight, but at least we can avoid further reinforcing that wrong > thinking. > > If someone has 200 Mb/s Internet service and it feels slow, then they > might upgrade to 400 Mb/s Internet service and expect everything to be > uniformly twice as fast. We here know that doubling the network capacity > may make large downloads faster, but everything else is most likely > unchanged, and can be even worse. > > People never make this mistake in other contexts. If someone commutes to > work in their 20-foot RV feels that it=E2=80=99s too slow, then upgrading= to a > 40-foot RV will not get them to work faster. A 40-foot RV is *bigger* tha= n > a 20-foot RV, but it=E2=80=99s probably not *faster*. If you are moving a= vast > amount of cargo that requires multiple trips, then a larger truck will le= t > you complete that task in fewer trips. But for most daily driving, a bigg= er > truck will not get to your destination any quicker. > > Some simple edits: > > Instead of =E2=80=9Cvarying speed ISP links=E2=80=9D how about =E2=80=9Cv= arying capacity ISP > links=E2=80=9D? > > Instead of =E2=80=9Cthey profit if you decide your network is too slow an= d you > upgrade to a faster device/plan=E2=80=9D how about =E2=80=9Cthey profit i= f you decide your > network is too slow and you upgrade to a higher throughput device/plan=E2= =80=9D? > > Stuart Cheshire > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --0000000000004a5759061a15fe4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good examples Stuart, it is quite inte= resting that as humanity we have not come up with aggregate term what would= fairly collapse the dimensions to one single metric that would describe th= e snappy feeling we intuitively seek for but can not quite verbalize. Vehic= les have the same issues, we have top speed (F1 at 360mph feels fast compar= ed to Starship at 16000mph), we have acceleration (Hot-rod going 0 to 60 mp= h in 5 seconds feels high but pales in comparison to Tesla going 0 to 60 mp= h in 2 sec), we have horse powers (tractor plowing field with 300hp feels g= reat but seems small compared to 1000hp of Hot-rod) then also there is torq= ue (tractor with 1450 Nm of torque wins a Tesla having 900Nm on wheel while= at completely different torque curve).

Capacity has the sam= e issue as literally the truck from your example shipping magnetic tapes fo= r "raw carry capacity" but it does not feel responsive, snappy, g= ood to handle in the "traffic" of Internet. We have jitter, that = could be compared to how a vehicle does in repeatability of track laps? We = have packet loss on how the car handles on curves and does it slip off the = track or on accelerations spin the wheels? Download is speed forward, uploa= d is almost like speed at reverse gear usually far worse. Latency is like a= lap track as such, depends on the track, use-case specific tests "Wha= t time did it do on=C2=A0N=C3=BCrburgring?" or "How fast does it = go from 0 to 60Mbps? Less than 200ms?". Horse power feels much like ra= w capacity of the HW / radio channel and techniques available beam forming,= frequencies etc. what was discussed here related to Starlink and even coll= ectively across different technologies. Speed is then instead of how much s= pecific combination of modem and base-station combo can achieve at certain = configuration? Torque feels like ability to maintain that performance, clos= est we get is loaded performance in context of bufferbloat?

<= div>Watching videos on Netflix require different performance characteristic= s than downloading a big update to Fortnite. One has certain acceleration n= eed to have snappy user experience but focus is more on connection stabilit= y at certain bitrate. On the other hand Fortnite update you want to be deli= vered at brute force speeds without ruining others user experience.

=
Maybe we can not find that aggregate property or metric, but jus= t need to be rigorous on making sure we accurately characterize each dimens= ion and standardize them so the confusion and play with words, specially wi= th marketing, get stabilized. Each needs to have standardized benchmarks mu= ch like 3D rendering benchmarks and PC perf tests are done? All that said, = as I failed to come up with a perfect term, "varying performance ISP l= inks" feels like the right thing to say? Now we have obfuscated to be = able to throw any of the dimensions underneath. Only thing left for us to d= o is then to provide those dimensions like a nutrient labels. We are gettin= g there? Nothing new under the sun also to some extend.

J= ust as a funny side note on the tractor marketing:

=E2=80=9DTorque g= ives you the feeling of responsiveness and that the machine=20 does the right things,=E2=80=9D Tapani Katila encapsulates his view. =E2=80= =9CThe torque is directly linked to the feeling of having power available in the=20 entire range of the power curve, resulting in more meaningful work.=E2=80= =9D from https://www.agcopower.com/power-is-important-but-torque-is-cr= ucial/

Seems like some other people are also trying t= o figure out what dimensions to showcase to customers?

Thank you for the thought provoking examples!

Is buff= erbloat property of a vehicle or characteristic of the road design? Is it a= question of ICE vs EV -or- roundabout vs crossing with traffic lights? Fee= ls more like a roundabout, no? Is this the problem behind the objections?

- Sauli

On Tue, Jun 4, 2024 at 9:19=E2=80=AFPM St= uart Cheshire via Starlink <starlink@lists.bufferbloat.net> wrote:
On May 7, 2024, at 18:48, Dave Taht via= Starlink <starlink@lists.bufferbloat.net> wrote:

> This was a wonderful post, rich!

<https://randomne= uronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/>
I agree. Thanks for writing this Rich.

One minor change I will request. Any time you write words like =E2=80=9Cspe= ed=E2=80=9D or =E2=80=9Cfast=E2=80=9D, pause and consider whether it would = be more accurate to use some other term like =E2=80=9Ccapacity=E2=80=9D, = =E2=80=9Cbandwidth=E2=80=9D, or =E2=80=9Cthroughput=E2=80=9D. Part of what = keeps us in this mess is that people equate network capacity with =E2=80=9C= speed=E2=80=9D, as if those terms were synonyms. We can=E2=80=99t change ho= w people think overnight, but at least we can avoid further reinforcing tha= t wrong thinking.

If someone has 200 Mb/s Internet service and it feels slow, then they might= upgrade to 400 Mb/s Internet service and expect everything to be uniformly= twice as fast. We here know that doubling the network capacity may make la= rge downloads faster, but everything else is most likely unchanged, and can= be even worse.

People never make this mistake in other contexts. If someone commutes to wo= rk in their 20-foot RV feels that it=E2=80=99s too slow, then upgrading to = a 40-foot RV will not get them to work faster. A 40-foot RV is *bigger* tha= n a 20-foot RV, but it=E2=80=99s probably not *faster*. If you are moving a= vast amount of cargo that requires multiple trips, then a larger truck wil= l let you complete that task in fewer trips. But for most daily driving, a = bigger truck will not get to your destination any quicker.

Some simple edits:

Instead of =E2=80=9Cvarying speed ISP links=E2=80=9D how about =E2=80=9Cvar= ying capacity ISP links=E2=80=9D?

Instead of =E2=80=9Cthey profit if you decide your network is too slow and = you upgrade to a faster device/plan=E2=80=9D how about =E2=80=9Cthey profit= if you decide your network is too slow and you upgrade to a higher through= put device/plan=E2=80=9D?

Stuart Cheshire

_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
--0000000000004a5759061a15fe4b--