From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bosmailout07.eigbox.net (bosmailout07.eigbox.net [66.96.184.7]) (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 AE2323B29D; Wed, 4 Jan 2023 23:25:28 -0500 (EST) Received: from [10.20.15.5] (helo=bosmailscan05.eigbox.net) by bosmailout07.eigbox.net with esmtp (Exim) id 1pDHom-0002kW-86; Wed, 04 Jan 2023 23:25:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alum.mit.edu; s=dkim; h=Sender:Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:Cc:To:From:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0oegLws0gwIGfQnxBuwK6T5OGluFReCcBShiZ3r/7xE=; b=vFZNlVDVZ9ob+7NAY2qY1JDfMX dhQ8eWQzf55bM6KTYCBhB38Kum0R+glLiD9bDywVIrUavrxshxmSnTsRbWd3zN9KbEjfhfLQ9+E1c IhjfcuhQzurlX/mZho+cWoZlei++0FO/urtEP5N2nbiBJRTbJhFje1SwhPCNxZImS1LQzH3bprFoz RFm7BsqO5YeiupgCIw+bBQQk4zf83cPLuvWMN+MimazdeEfgRT42w1s+aTCn4NrUF9cr/Hgw4eiQz b14MfobrbXhTQU0MDQXKGIR1UAY4WWoMoSsp0EPEBUgZmtLkPVav00D0GqyQlm183bhHHC+WKHBHK vaL0CO3w==; Received: from [10.115.3.32] (helo=bosimpout12) by bosmailscan05.eigbox.net with esmtp (Exim) id 1pDHol-0002nb-T1; Wed, 04 Jan 2023 23:25:27 -0500 Received: from bosauthsmtp19.yourhostingaccount.com ([10.20.18.19]) by bosimpout12 with id 4sRQ2900A0QhFXN01sRTGX; Wed, 04 Jan 2023 23:25:27 -0500 X-Authority-Analysis: v=2.3 cv=d4VuNSrE c=1 sm=1 tr=0 a=9UqFsMnAB6EOkiq4MrOclQ==:117 a=nIEF4cAZMyOU5h9mcfI6lg==:17 a=RvmDmJFTN0MA:10 a=6ulraYUaiNAA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=kurRqvosAAAA:8 a=sqLpaOU98Sibaej4QDEA:9 a=CjuIK1q_8ugA:10 a=SSmOFEACAAAA:8 a=mfzmceUD9aQHwcEKoncA:9 a=cCWrsjBgupgKbIaN:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=kbxRQ_lfPIoQnHsAj2-A:22 Received: from c-67-180-86-211.hsd1.ca.comcast.net ([67.180.86.211]:58466 helo=SRA6) by bosauthsmtp19.eigbox.net with esmtpa (Exim) id 1pDHoi-00033a-30; Wed, 04 Jan 2023 23:25:24 -0500 Reply-To: From: "Dick Roy" To: , "'Dave Taht'" Cc: "'IETF IPPM WG'" , "'libreqos'" , "'Cake List'" , "'Rpm'" , "'bloat'" References: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com> In-Reply-To: <845161E4-474C-44A9-92D4-1702748A3DA1@jonathanfoulkes.com> Date: Wed, 4 Jan 2023 20:25:14 -0800 Organization: SRA Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E8_01D9207A.ACF13C50" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AdkgcaeiPghvVlbWRwSWq3zsa9MO0QASVTcA X-MimeOLE: Produced By Microsoft MimeOLE X-EN-UserInfo: f809475445fb8041985048e338e1a001:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: dickroy@intellicommunications.com Sender: "Dick Roy" X-EN-OrigIP: 67.180.86.211 X-EN-OrigHost: c-67-180-86-211.hsd1.ca.comcast.net X-Mailman-Approved-At: Sat, 07 Jan 2023 19:37:32 -0500 Subject: Re: [Bloat] [Starlink] [Rpm] the grinch meets cloudflare's christmas present X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2023 04:25:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04E8_01D9207A.ACF13C50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HNY to all! Seems to me that we often get distracted by nomenclature needlessly. Perhaps it's time to agree on the lexicon that should be used going forward so as to avoid such distractions. Perhaps a place to start is "the technical facts": 1) "capacity" is a property of a link (or links) that specifies the theoretically achievable maximum error-free transmission rate of data/information through a noisy channel (or channels, the multidimensiaonl version of the capacity theorem). Yes, it's much more complicated than that in general, however the basic principle is easy to understand. "You can only get so much water through a hose of size X with an applied pressure of magnitude Y.") 2) "maximum achievable throughput/data-rate" of a channel is the maximum rate (always <= channel capacity) at which information can be exchanged in the channel as implemented (under all conditions). 3) achieved/measured "data rate" is the measured/estimated rate of information transmission (always <= maximum achievable rate" for that channel) in a channel under a given set of conditions. 4) "latency" is the amount of time it takes information to get from a source to its destination (there may be multiple destinations each with different latencies :-)). Latency may (or may not) include the unavoidable consequence of the laws of physics that state information can not travel faster than the "speed" of light (actually the "speed" in whatever medium and by whatever mode the information is actually being transported)! Tin cans and strings have a transmission speed that depends critically on how hard each person at the end of the "link" are pulling on their cans! :-) The point is that when included, information transmission times from source to destination set a lower bound on the "latency" of that link/channel. 5) . (feel free to add more :-) My two cents! RR -----Original Message----- From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of jf--- via Starlink Sent: Wednesday, January 4, 2023 11:20 AM To: Dave Taht Cc: Dave Taht via Starlink; IETF IPPM WG; libreqos; Cake List; Rpm; bloat Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas present HNY Dave and all the rest, Great to see yet another capacity test add latency metrics to the results. This one looks like a good start. 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't deliver reliable low-latency unless you shave a good bit off the targets. My local loop is pretty congested. Here's the latest Cloudflare test: ------=_NextPart_000_04E8_01D9207A.ACF13C50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HNY to all!

 

Seems to me that we often get distracted by nomenclature = needlessly.  Perhaps it’s time to agree on the lexicon that should be used going = forward so as to avoid such distractions.

 

Perhaps a place to start is “the technical = facts”:

 

1)    = “capacity” is a property of a link (or links) that specifies the theoretically = achievable maximum error-free transmission rate of data/information through a noisy channel (or channels, the multidimensiaonl version of the capacity = theorem).  Yes, it’s much more complicated than that in general, however the basic principle is easy to understand. “You can only get so much water = through a hose of size X with an applied pressure of magnitude = Y.”)

2)    = “maximum achievable throughput/data-rate” of a channel is the maximum rate = (always <=3D channel capacity) at which information can be exchanged in the = channel as implemented (under all conditions).

3)    = achieved/measured “data rate” is the measured/estimated rate of information = transmission (always <=3D maximum achievable rate” for that channel) in a = channel under a given set of conditions.

4)    = “latency” is the amount of time it takes information to get from a source to its destination (there may be multiple destinations each with different = latencies J).  Latency may (or may not) include the unavoidable consequence of the laws of = physics that state information can not travel faster than the = “speed” of light (actually the “speed” in whatever medium and by = whatever mode the information is actually being transported)! Tin cans and strings = have a transmission speed that depends critically on how hard each person at = the end of the “link” are pulling on their cans! J The point is that when = included, information transmission times from source to destination set a lower bound on the = “latency” of that link/channel.

5)    = … (feel free to add more J

 

My two cents!

RR

 

-----Original Message-----
From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf = Of jf--- via Starlink
Sent: Wednesday, January 4, 2023 11:20 AM
To: Dave Taht
Cc: Dave Taht via Starlink; IETF IPPM WG; libreqos; Cake List; Rpm; = bloat
Subject: Re: [Starlink] [Rpm] the grinch meets cloudflare's christmas = present

 

HNY Dave and all the rest,

 

Great to see yet another capacity test add latency metrics to = the results. This one looks like a good start.

 

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’t deliver reliable = low-latency unless you shave a good bit off the targets. My local loop is pretty = congested.

 

Here’s the latest Cloudflare = test:

 

------=_NextPart_000_04E8_01D9207A.ACF13C50--