From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 AF7F93B29E for ; Fri, 6 Jan 2023 04:43:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1672998200; bh=zOCg4iyDbrj/f9CEzrkDjsz1vZDMA59X21rdDjTAoS0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=AFbtUcS/PjMWIMOvdTtrZL19a33demKjRszDb/pSBEJj629m17c6BqqQMGGbXOSkl m3a4hvIUELhW3pjtRmvHpB2wezGcT/6tl/Z8reU/kwkHO3cq/aDTCQjTMFzwDM8z4Y 0s2XXMv3shDQBfwLYQcGJe8YSW59AeDtkOx5ALM977l2Pe9jQjJOYSKRG8J28FYljH +UZK7AUGpX+rr85kZHU4y5pVrlRlMDnWUvm3Jvrch2AFYtkLfUxjiikDZxquWm2N56 mUxbIp/2g+i0gcj7SZ6BdJupqojIGiBRB5iA2w6Msv3x2oke2mtnpfCbGci1eleT85 m7uehpHegXMWA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MLiCu-1pVG8l3rdI-00Hf5p; Fri, 06 Jan 2023 10:43:19 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: <653AFAEF2C3340F38CE34BEE61AED229@SRA6> Date: Fri, 6 Jan 2023 10:43:18 +0100 Cc: Dave Collier-Brown , starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <88FD70A1-B38F-4094-8629-2A7E88EF974D@gmx.de> References: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com> <82cfa31b-3694-7f6f-3f29-8de77559dd6f@indexexchange.com> <15EBCC5BF2474AAB82C050259229B5FB@SRA6> <12C74FE9-3190-4088-A333-B90DFB8E3277@gmx.de> <653AFAEF2C3340F38CE34BEE61AED229@SRA6> To: Dick Roy X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:JU12yPnp0DnUGuFEGyLPg5FKfyAWrucPsCITmIyTFtDyNv1uzMF zglLogY0lxJ96kTjbuZd/FyyqI1fwpWmaI5tfMHnZP52CeNRIHv1fG8gWKeqp6NP52oDpPs +IYGPMqfkydMslcqP3dOsf7nIgFNerj6MTSGQavRIRD3pern3QLNt6hCfFiwekSscAu2WrR G2To3rybqkUjsKK00EQDg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:q5o56LWSnZw=;/b3sBS/9wlSDd0kiFrza25hZDqn JJi9ob8BlUkzJCcm9jaLOlMKhdxgZQBqu9BRxfAW8sHbQT/r0abNZNDfu+Ud8LJa8wRBHj/Ek 5e8v3VtrTeuyMH6f1NFEj1uIczWJ5eu26TngXMUayTxnr1CmSKohwSsR1lBgeYjmm4svwmAkI 02ilNuGGCVa1y06wHWXzxjicf9VOyki7dJtNA1y3dAVX7w5RA0+cHKk2ASn3eUauG3Qf7P6JS +kyFlnAnpDDy9LGANdKW1GLEIFKm5XlnMY/zssC0cIHtBOSdQG5U1erDav2mhM5sZa1vnHPla /yXmSnshZnY2YsUmItz1JjGAwKUBA11y0ZusJoWkh3ZGR83fBiczkJnsiaOoOaf8cochvPY1o b1MVELdhU9yBh5ltYe8ur1ZbtdfRNSDkPn+vZpGmyZdChRYpD4Y2IoOnUoS2iFgfx2fgQB9QP DwjN3upGUwKfQKwg/BI9dRAyJTigVf34chF9dKCcg/2uvYQbcNmKDlpU3DUm7lIYMKuzu3966 ozHnyYWY6cNqy+WXv0Ospp+JXIwr0LVf7D4fjNJ7bag87dzL6Obq/yC2iNaGBoPPuB1iiIvuC EQ4ND/HWfiDB/+3vHhpqxGeH9Bzim5brxfMCK4WOos903IajZrFbAQqn6OffJEOJVkAyDISGF jsqaqJpj8EvT/ApRq6+VcO1sh3nsuJ3om0m/N0edMOGYSiSJjhqa+eFiHcSvZz+3pDagw44au jPBG5IFApshfOgAs96O6DIXJcexgpT6jIvCm9S7kRjiVuFiZtjR6f4+iJOXdugHk0Lqm6QwU1 cuxXXlfC/q/uBSQod2thSZ5l8L6XlGAbEItylTN0n8OiYy+K8XZBjGCnaRLIsbr9LPv7FXB9l C9BKHj3aEt9NjKvlewEOEYFEw099Mlyj+Zq6H0gIOuZV3KQB1IEHpQmh+I3IRZG5ritHTdiNj N6QCySS+4PJYqcrP5alZH60x7i8= Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas present 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: Fri, 06 Jan 2023 09:43:26 -0000 Hi RR, > On Jan 6, 2023, at 01:01, Dick Roy wrote: >=20 > Hi Sebastian, > =20 > See below =E2=80=A6 > =20 > -----Original Message----- > From: Sebastian Moeller [mailto:moeller0@gmx.de]=20 > Sent: Thursday, January 5, 2023 3:26 AM > To: Dick Roy > Cc: Dave Collier-Brown; starlink@lists.bufferbloat.net > Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas = present > =20 > Hi RR, > =20 > =20 > > On Jan 5, 2023, at 04:11, Dick Roy via Starlink = wrote: > >=20 > > =20 > > =20 > > From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On = Behalf Of Dave Collier-Brown via Starlink > > Sent: Wednesday, January 4, 2023 6:48 PM > > To: starlink@lists.bufferbloat.net > > Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's = christmas present > > =20 > > I think using "speed" for "the inverse of delay" is pretty normal = English, if technically erroneous when speaking nerd or physicist. > >=20 > > [RR] I=E2=80=99ve not heard of that usage before. The units = aren=E2=80=99t commensurate either.=20 > >=20 > > Using it for volume? Arguably more like fraudulent... > >=20 > > [RR] I don=E2=80=99t think that was Bob=E2=80=99s intent. I think = =E2=80=9Cload volume=E2=80=9D was meant to be a metaphor for =E2=80=9Cnumb= er of bits/bytes=E2=80=9D being transported (=E2=80=9Cby the semi=E2=80=9D= ). =20 > >=20 > > That said, aren=E2=80=99t users these days educated on =E2=80=9Cgigs=E2= =80=9D which they intuitively understand to be Gigabits per second (or = Gbps)? Oddly enough, that is an expression of = =E2=80=9Cdata/information/communication rate=E2=80=9D in the appropriate = units with the nominal technically correct meaning. =20 > =20 > [SM] Gigs would have the following confounds if used without a = proper definition: > a) base10 or base2^10? > b) giga-what? Bit or Byte > c) Volume or capacity > d) if capacity, minimal, average, or maximal? > =20 > I note (again, sorry to sound like a broken record) that the national = regulatory agency for networks (Bundes-Netzagentur, short BNetzA) in = Germany has some detailed instructions about what information ISPs need = to supply to their potential customers pre-sale = (seehttps://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/T= elekommunikation/Unternehmen_Institutionen/Anbieterpflichten/Kundenschutz/= Transparenzma=C3=9Fnahmen/Instruction_for_drawing_up_PIS.pdf?__blob=3Dpubl= icationFile&v=3D1) where the headlines talk correctly about "data = transmission rates" but in the text they occasionally fall back to = "speed". They also state: "Data transmission rates must be given in = megabits per second (Mbit/s)." > This is both in response to our "speed" discussion, but also one = potential way to clarify b) c) and d) above... given that is official = this probably also answers a) (base10 otherwise the text would be "Data = transmission rates must be given in mebibits per second (Mibit/s).") > [RR] My reference to =E2=80=9Cgigs=E2=80=9D was to the ads out = nowadays from AT&T about becoming Gagillionaires (=E2=80=9CYes, I am = Jurgous. =E2=80=A6 We know!=E2=80=9D) that =E2=80=9Cnow have gig speed = wireless from AT&T=E2=80=9D so they can play all kinds of VR games.=20 [SM2] Ah, not being in the U.S. that campaign has completely = evaded my attention. > J That said, not sure why BNetzA mandates a particular unit for = information rates, but that=E2=80=99s their prerogative I guess. [SM2] My bigger point was actually that they use the term "data = transmission rates" instead of speed... But to your point the product = information sheets are designed specifically to make it easy for = consumers to compare different offers (for all values of consumer = knowledge of networking and SI-prefixes) and requiring a single unit = makes comparison simple and gives less leeway to play games. This BNetzA = initiative basically removed the previous "up to XX Mbps" promise of = ISPs and especially the interpretation that YY with YY << XX is still = the contractually fine as "up to" implies not guarantee. > Given that the fundamental unit of information is the answer to a = YES/NO question (aka a =E2=80=9Cbit=E2=80=9D), it makes sense to measure = information in bits (although trits or any other higher order concept = could be used as long as the system accounted for fractions thereofJ) = (and sets of bits (aka bytes or really octets) because of ancient = computer arcitecturesJ). [SM2] I agree, but prefer this to be inherent in the term used, = and "gigs" did not carry any of that information for me, but again I had = not encountered the AT&T campaign... > Since we have pretty much settled on the SI second as the accepted = unit of time (and multiples thereof e.g. msec, usec, nsec, etc.), it = makes sense to measure information flow in bits/sec or some multiples = thereof such as Gbps, Mbps, Kbps, etc. and their byte (really octet) = versions GBps, MBps, KBps, etc.. Not sure why BNetzA mandates ONLY one = of these, but whatever =E2=80=A6 J [SM2] Again I speculate that this is to allow easy comparison = even by consumers that are not "fluent" in interpreting SI-prefixes and = that might e.g. not know by heart whether Mb is larger or smaller than = Gb, let alone why mB is not equal to Mb... this is a transparency = measure foremost aimed at all end-customers (business contract do not = fall under that regulation as far as I know). > As for capacity, remember capacity is not something that is measured. = It is a fundamental property (an information rate!) of a communication = channel which has no other attributes such as minimal, average, or = maximal (unless one is talking about time-varying channels and is = wanting to characterize the capacity of the channel over time, but = that=E2=80=99s another story). [SM] On a shared medium (and let's face it head on sooner or = later "internet-access" will become a shared medium) the capacity share = each user can relay on is rarely static, most often ISPs oversubscribe = links and use traffic shapers to limit the maximum capacity share a user = can use, but that share is not guaranteed to be available. BNetzA went = as far as defining three different data rates with different expected = (temporal) availability as well as a (rather complicated) method how = end-users can confirm whether ISPs actually deliver the promised rates. > As such, comparing volume and capacity is comparing apples and = oranges; one is a size of something (e.g. number of megabytes) and the = other is a rate (e.g. MBps) so I am not sure what =E2=80=9CVolume or = capacity=E2=80=9D really means. [SM] The term Gigs unlike e.g. Mb/s or Mbps (for Megabits per = second) does not intuitively define whether time is taken into account, = and over here mobile contracts typically come with a "high-speed Volume" = after the consumption of which mobile links fall back to truly atrocious = rates like 32Kbps, for these kind of contracts ISPs tend to primarily = market the Volume (mostly in GB) and only mention the maximal data rates = as secondary information. > I suspect the concept you may be looking for is =E2=80=9Cachievable = rate=E2=80=9D rather than =E2=80=9Ccapacity=E2=80=9D. [SM2] Actually I always try to first calculate the theoretical = upper limit of my links (which I then dub the link's "capacity") and I = compare the actual measured rates with the theoretical limit... This = works well enough for me, since the consumer links I use typically are = dominated by a predictable traffic shaper on the ISP side... > Achievable rate IS something that is measureable, and varies with = load when channels are shared, etc.. Loosely speaking, achievable rate = is always less than or equal to the capacity of a channel.=20 [SM2] Yepp, that is why I try to calculate a capacity estimate = (and calculate the resulting throughput on different levels). Regards Sebastian > =20 > HNY, > =20 > RR > =20 > --Sebastian > =20 > >=20 > > RR > >=20 > > --dave > >=20 > > On 1/4/23 18:54, Bruce Perens via Starlink wrote: > >> On the other hand, we would like to be comprehensible to normal = users, especially when we want them to press their providers to deal = with bufferbloat. Differences like speed and rate would go right over = their heads. > >> =20 > >> On Wed, Jan 4, 2023 at 1:16 PM Ulrich Speidel via Starlink = wrote: > >>> The use of the term "speed" in communications used to be = restricted to the speed of light (or whatever propagation speed one = happened to be dealing with. Everything else was a "rate". Maybe I'm = old-fashioned but I think talking about "speed tests" muddies the waters = rather a lot. > >>> =20 > >>> --=20 > >>> ****************************************************************=20= > >>> Dr. Ulrich Speidel > >>>=20 > >>> Department of Computer Science=20 > >>>=20 > >>> Room 303S.594 > >>> Ph: (+64-9)-373-7599 ext. 85282=20 > >>>=20 > >>> The University of Auckland > >>> u.speidel@auckland.ac.nz > >>> http://www.cs.auckland.ac.nz/~ulrich/ > >>> ****************************************************************=20= > >>> From: Starlink on behalf = of rjmcmahon via Starlink > >>> Sent: Thursday, January 5, 2023 9:02 AM > >>> To: jf@jonathanfoulkes.com > >>> Cc: Cake List ; IETF IPPM WG = ; libreqos ; Dave Taht = via Starlink ; Rpm = ; bloat > >>> Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's = christmas present > >>> =20 > >>> Curious to why people keep calling capacity tests speed tests? A = semi at=20 > >>> 55 mph isn't faster than a porsche at 141 mph because its load = volume is=20 > >>> larger. > >>>=20 > >>> Bob > >>> > HNY Dave and all the rest, > >>> >=20 > >>> > Great to see yet another capacity test add latency metrics to = the > >>> > results. This one looks like a good start. > >>> >=20 > >>> > Results from my Windstream DOCSIS 3.1 line (3.1 on download = only, up > >>> > is 3.0) Gigabit down / 35Mbps up provisioning. Using an IQrouter = Pro > >>> > (an i5 x86) with Cake set for 710/31 as this ISP can=E2=80=99t = deliver > >>> > reliable low-latency unless you shave a good bit off the = targets. My > >>> > local loop is pretty congested. > >>> >=20 > >>> > Here=E2=80=99s the latest Cloudflare test: > >>> >=20 > >>> >=20 > >>> >=20 > >>> >=20 > >>> > And an Ookla test run just afterward: > >>> >=20 > >>> >=20 > >>> >=20 > >>> >=20 > >>> > They are definitely both in the ballpark and correspond to other = tests > >>> > run from the router itself or my (wired) MacBook Pro. > >>> >=20 > >>> > Cheers, > >>> >=20 > >>> > Jonathan > >>> >=20 > >>> >=20 > >>> >> On Jan 4, 2023, at 12:26 PM, Dave Taht via Rpm=20 > >>> >> wrote: > >>> >>=20 > >>> >> Please try the new, the shiny, the really wonderful test here: > >>> >> https://speed.cloudflare.com/ > >>> >>=20 > >>> >> I would really appreciate some independent verification of > >>> >> measurements using this tool. In my brief experiments it = appears - as > >>> >> all the commercial tools to date - to dramatically understate = the > >>> >> bufferbloat, on my LTE, (and my starlink terminal is out being > >>> >> hacked^H^H^H^H^H^Hworked on, so I can't measure that) > >>> >>=20 > >>> >> My test of their test reports 223ms 5G latency under load , = where > >>> >> flent reports over 2seconds. See comparison attached. > >>> >>=20 > >>> >> My guess is that this otherwise lovely new tool, like too many, > >>> >> doesn't run for long enough. Admittedly, most web objects = (their > >>> >> target market) are small, and so long as they remain small and = not > >>> >> heavily pipelined this test is a very good start... but I'm = pretty > >>> >> sure cloudflare is used for bigger uploads and downloads than = that. > >>> >> There's no way to change the test to run longer either. > >>> >>=20 > >>> >> I'd love to get some results from other networks (compared as = usual to > >>> >> flent), especially ones with cake on it. I'd love to know if = they > >>> >> measured more minimum rtts that can be obtained with fq_codel = or cake, > >>> >> correctly. > >>> >>=20 > >>> >> Love Always, > >>> >> The Grinch > >>> >>=20 > >>> >> -- > >>> >> This song goes out to all the folk that thought Stadia would = work: > >>> >> = https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665= 607352320-FXtz > >>> >> Dave T=C3=A4ht CEO, TekLibre, LLC > >>> >> = ________________= _______________________________ > >>> >> Rpm mailing list > >>> >> Rpm@lists.bufferbloat.net > >>> >> https://lists.bufferbloat.net/listinfo/rpm > >>> >=20 > >>> >=20 > >>> > _______________________________________________ > >>> > Rpm mailing list > >>> > Rpm@lists.bufferbloat.net > >>> > https://lists.bufferbloat.net/listinfo/rpm > >>> _______________________________________________ > >>> 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 > >>=20 > >> =20 > >> --=20 > >> Bruce Perens K6BP > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Starlink mailing list > >> Starlink@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/starlink > > --=20 > > David Collier-Brown, | Always do right. This will gratify > > System Programmer and Author | some people and astonish the rest > > dave.collier-brown@indexexchange.com | -- Mark Twain > > =20 > > CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, = including any and all attachments, contains confidential information = intended only for the person(s) to whom it is addressed. Any = dissemination, distribution, copying or disclosure is strictly = prohibited and is not a waiver of confidentiality. If you have received = this telecommunication in error, please notify the sender immediately by = return electronic mail and delete the message from your inbox and = deleted items folders. This telecommunication does not constitute an = express or implied agreement to conduct transactions by electronic = means, nor does it constitute a contract offer, a contract amendment or = an acceptance of a contract offer. Contract terms contained in this = telecommunication are subject to legal review and the completion of = formal documentation and are not binding until same is confirmed in = writing and has been signed by an authorized signatory. > >=20 > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink