From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 850B93CB44 for ; Tue, 30 Apr 2024 23:18:52 -0400 (EDT) Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-de54b28c3b7so7094965276.1 for ; Tue, 30 Apr 2024 20:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=connectivitycap.com; s=google; t=1714533532; x=1715138332; darn=lists.bufferbloat.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=8et7DxWdTIqGQBwMyP86WHlGquqZXwd6m1K3W4ldHMY=; b=eE8xkakF3kZW3JrfMBFfvsOV1QMkbriOZvio2Xkg/GR5swoEYZnla8G8NwET6p1tbf bfTQrkxVBzIROZzHU0XBSOorc1UVABmPBIMZ/dsAL0nQEF0M1xkxSKISV09LsAEJ+wRX YqKbXq6XhhcxGe/dal9g8WhUoWL+11NgtGPi5kCKX/dWwEU4mENZKtAR5MfnVTqz2Oq/ LnDNqAbRbIor7KietaH9Y9bBjs8gmf7sFi71n4SL1HVvdJ79DLwrnvCjRBDja1j34Zg6 J4lVVJhaHihNz3Nle/NgwsaojOIvbmBUI/LJuC23uRCqy5Uxxeul8/1gMxAJEgtCa7A3 dr8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714533532; x=1715138332; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8et7DxWdTIqGQBwMyP86WHlGquqZXwd6m1K3W4ldHMY=; b=vXheFVDj9yTx7tDn0w4jvav8NT58Lf2kWhA904YM3AFJAwUFKw1nMB6m1moIsLNxIJ HxTH+kYQFuHE5XtI337KB4fz/bqfO4dXVzOr58Nz4yQo7bBqO4rNgzuJy5lhePrzlk58 PAZUZT5besezMpJGM1qozzMnkO77ZI+cb/AYMsGFOG9YwGHsykd/VrBG7E7OPcAtdwl2 i5eYOss5Dzx/ZleI2dfoKXSR5L+KssGE1AfYJ205PQhSmhQEtvx+Yq1cB7k9ey8vYsnn UuMw/SrW/mUQPk4Qgkqp6ssuaFhmlMYwSRaBZSsASILKfbG3yM+2NWNymIFAPnXFKVz5 5GHQ== X-Forwarded-Encrypted: i=1; AJvYcCWA7hk0O6QRz8WVuHDIUUgHdZTb7UxpfQPfBYPv6fYv8KJJzXyneOjnRVNVK/w5lgyXYyImzzAcM8MrQJpFOuVBn9X48AqYoyZgveD5omk= X-Gm-Message-State: AOJu0YyPg53j+7GKv46VfuxnvGtFPhz8ifZVw/ShtxF64UFp64vyoj0W v52SYJJ8t8S0ando4GUXw1UAxiGkgzQFAPO789q3v8GTPtDzXACOmD5S4GTqRZs= X-Google-Smtp-Source: AGHT+IHZh+pq1lgtN9U99UHfxv0z0qrOr/TetRf1laIIGsTvDkDHNQondEIkezONWe4BQaReOb8XUQ== X-Received: by 2002:a25:d003:0:b0:de5:990d:11bc with SMTP id h3-20020a25d003000000b00de5990d11bcmr1585775ybg.54.1714533531635; Tue, 30 Apr 2024 20:18:51 -0700 (PDT) Received: from smtpclient.apple ([2607:fb90:93a0:c490:5826:2ea3:5a65:d3f3]) by smtp.gmail.com with ESMTPSA id j8-20020ac85508000000b0043490cc5254sm11944535qtq.32.2024.04.30.20.18.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2024 20:18:51 -0700 (PDT) From: Jim Forster Message-Id: <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_027D4DF1-8019-4401-8C55-B48F637AB55D" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Date: Wed, 1 May 2024 04:52:27 +0300 In-Reply-To: <79C02ABB-B2A6-4B4D-98F4-6540D3F96EBB@ieee.org> Cc: David Lang , Dave Taht via Starlink , Colin_Higbie To: Eugene Y Chang References: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org> <79C02ABB-B2A6-4B4D-98F4-6540D3F96EBB@ieee.org> X-Mailer: Apple Mail (2.3774.500.171.1.1) Subject: Re: [Starlink] =?utf-8?q?It=CA=BCs_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: Wed, 01 May 2024 03:18:52 -0000 --Apple-Mail=_027D4DF1-8019-4401-8C55-B48F637AB55D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gene, David, Agreed that the technical problem is largely solved with cake & codel. Also that demos are good. How to do one for this problem> =E2=80=94 Jim > The bandwidth mantra has been used for so long that a technical = discussion cannot unseat the mantra. > Some technical parties use the mantra to sell more, faster, = ineffective service. Gullible customers accept that they would be happy = if they could afford even more speed. >=20 > Shouldn=E2=80=99t we create a demo to show the solution? > To show is more effective than to debate. It is impossible to explain = to some people. > Has anyone tried to create a demo (to unseat the bandwidth mantra)?=20 > Is an effective demo too complicated to create? > I=E2=80=99d be glad to participate in defining a demo and publicity = campaign. >=20 > Gene >=20 >=20 >> On Apr 30, 2024, at 2:36 PM, David Lang > wrote: >>=20 >> On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote: >>=20 >>> 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=E2=80=99t shed light on the following = scenarios. >>>=20 >>> While watching stream content, activating controls needed to switch = content sometimes (often?) have long pauses. I attribute that to buffer = bloat and high latency. >>>=20 >>> 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.) >>>=20 >>> How can we deliver graceful performance to both persons in a = household? >>> Is seeking graceful performance too complicated to improve? >>> (I said =E2=80=9Cgraceful=E2=80=9D to allow technical flexibility.) >>=20 >> it's largely a solved problem from a technical point of view. = fq_codel and cake solve this. >>=20 >> The solution is just not deployed widely, instead people argue that = more bandwidth is needed instead. --Apple-Mail=_027D4DF1-8019-4401-8C55-B48F637AB55D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Gene, David,

Agreed that the = technical problem is largely solved with cake & = codel.

Also that demos are good. How to do one = for this problem>

  =E2=80=94 = Jim

The bandwidth mantra has = been used for so long that a technical discussion cannot unseat the = mantra.
Some technical parties use the mantra to sell = more, faster, ineffective service. Gullible customers accept that they = would be happy if they could afford even more = speed.

Shouldn=E2=80=99t we create a demo to = show the solution?
To show is more effective than to debate. = It is impossible to explain to some people.
Has anyone tried = to create a demo (to unseat the bandwidth mantra)? 
Is an = effective demo too complicated to create?
I=E2=80=99d be glad = to participate in defining a demo and publicity = campaign.

Gene


On Apr 30, = 2024, at 2:36 PM, David Lang <david@lang.hm> wrote:

On Tue, 30 Apr 2024, = Eugene Y Chang via Starlink wrote:

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=E2=80=99t 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 =E2=80=9Cgraceful=E2=80=9D to allow technical = flexibility.)

it's largely a solved problem from a = technical point of view. fq_codel and cake solve this.

The = solution is just not deployed widely, instead people argue that more = bandwidth is needed = instead.

= --Apple-Mail=_027D4DF1-8019-4401-8C55-B48F637AB55D--