From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 F07973B29D for ; Tue, 30 Apr 2024 23:59:28 -0400 (EDT) Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2b3374e08cfso44154a91.2 for ; Tue, 30 Apr 2024 20:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; t=1714535968; x=1715140768; 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=R8Eme8vMbZc8FRP8MhiCKkLkOjNs0yDzuPJuAnJeSe4=; b=afnUV/x1SgOUIhS1TiNIjawHj/K1c+LI6UuA3cjmFf/+c36vmO40utJTS6Z8I5DX0O K0KrQ9BSdoZPy5xYM9Qq8wIOHrdjQMn6AEjy3nAaD2CWIvsG57BfqBpE+6iIdD6TiBtW 7VM0TrTPiNxID3d+671fQpq/EF4TxoBJLYqn8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714535968; x=1715140768; 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=R8Eme8vMbZc8FRP8MhiCKkLkOjNs0yDzuPJuAnJeSe4=; b=jWg21xKtze5lJifeDLqnL/vHSq6bZBGy+vIUhShqeexcicbhvNmfYpn75g2q51ez6y QzBasAnxkzj6ICNBJ9pHNs/MESZm9YdHRDsoAh2/LugWAqVkwJsHKhibXYEPA8ZCd8Jx 82Zki5C0RhVMW9IQhqlGX+QxvqTuXun67I0jBAQcOQHabvttYYYGzwD7XrD8oe/Tb8hX aVIjb2yB8v1X4aBKxvt2STVW3pweL6FcSrQzON0KGP0DqA8kPu3wFavb/06D1Bbh7gvS ye4dcj5wC7lSKJ+pi9ISXJqOjUkkIafohnfCi+B/1SMFr9pb64YsFTF2tO/ApKAu8Z1h UIwg== X-Forwarded-Encrypted: i=1; AJvYcCXuPRgukyfmGl7PyN8NBmYK5xms9mnSn/IWRc0TiAjF/0mN8IojdKSV0LM6lm6o17u3UD7lOUGmHy845Yt3XxAeEOJ8lT5rzjDGRLR5ya8= X-Gm-Message-State: AOJu0Yz4k0weJiDWGs5m2SN1iEHynMwiAIf/LncCMv7dXSXBlDDIOoMS Zu38ZBTYrjUPfTzwU8oR+mEFBNe1mMZEwOJbwH7f+jx75V22gAADZbkmBiBwAw== X-Google-Smtp-Source: AGHT+IH/TagM5H+3aiBlq10xsIWTEY4aCuR0BSm5BI57EJv/VCN//+9B5Rq4sTt5yGIuDNhA4p4tfQ== X-Received: by 2002:a17:90b:1289:b0:2b1:817d:982b with SMTP id fw9-20020a17090b128900b002b1817d982bmr1415297pjb.14.1714535967747; Tue, 30 Apr 2024 20:59:27 -0700 (PDT) Received: from smtpclient.apple (dhcp-72-253-194-45.hawaiiantel.net. [72.253.194.45]) by smtp.gmail.com with ESMTPSA id si17-20020a17090b529100b002abb4500e97sm423526pjb.41.2024.04.30.20.59.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2024 20:59:27 -0700 (PDT) From: Eugene Y Chang Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_BFB3E81B-603E-4588-BDA6-571800536BA9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Tue, 30 Apr 2024 17:59:24 -1000 In-Reply-To: <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com> Cc: Eugene Y Chang , David Lang , Dave Taht via Starlink , Colin_Higbie To: Jim Forster References: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org> <79C02ABB-B2A6-4B4D-98F4-6540D3F96EBB@ieee.org> <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) 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:59:29 -0000 --Apple-Mail=_BFB3E81B-603E-4588-BDA6-571800536BA9 Content-Type: multipart/alternative; boundary="Apple-Mail=_37A3E1E1-ADF7-4799-B866-1F112513F792" --Apple-Mail=_37A3E1E1-ADF7-4799-B866-1F112513F792 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not completely up to speed on the gory details. Please humor = me. I am pretty good on the technical marketing magic. What is the minimum configuration of an ISP infrastructure where we can = show an A/B (before and after) test? It can be a simplified scenario. The simpler, the better. We can talk = through the issues of how minimal is adequate. Of course and ISP = engineer will argue against simplicity. We will want to show the human visible impact and not debate good or not = so good measurements. If we get the business and community subscribers = on our side, we win. Note: Stage 1 is to show we have a pure software fix (that can work on their = hardware). The fix is =E2=80=9Cso dramatic=E2=80=9D that subscribers can = experience it without debating measurements. Stage 2 discusses why the ISP should demand that their equipment vendors = add this software. (The software could already be available, but the ISP = doesn=E2=80=99t think it is worth the trouble to enable it.) Nothing = will happen unless we stay engaged. We need to keep the subscribers = engaged, too. Should we have a conference call to discuss this? Gene ---------------------------------------------- Eugene Chang IEEE Life Senior Member > On Apr 30, 2024, at 3:52 PM, Jim Forster = wrote: >=20 > Gene, David, > =E2=80=98m > Agreed that the technical problem is largely solved with cake & codel. >=20 > Also that demos are good. How to do one for this problem> >=20 > =E2=80=94 Jim >=20 >> 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)? >> 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. >=20 --Apple-Mail=_37A3E1E1-ADF7-4799-B866-1F112513F792 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m not completely up to speed on the gory details. Please humor me. I = am pretty good on the technical marketing magic.

What is the minimum configuration of an = ISP infrastructure where we can show an A/B (before and after) = test?
It can be a simplified scenario. The simpler, = the better. We can talk through the issues of how minimal is adequate. = Of course and ISP engineer will argue against = simplicity. 

We will want to show the human visible impact and not debate = good or not so good measurements. If we get the business and community = subscribers on our side, we win.

Note:
Stage 1 is = to show we have a pure software fix (that can work on their hardware). = The fix is =E2=80=9Cso dramatic=E2=80=9D that subscribers can experience = it without debating measurements.
Stage 2 discusses = why the ISP should demand that their equipment vendors add this = software. (The software could already be available, but the ISP = doesn=E2=80=99t think it is worth the trouble to enable it.) Nothing = will happen unless we stay engaged. We need to keep the subscribers = engaged, too.

Should we have a conference call to discuss this?


Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member



On Apr 30, 2024, at 3:52 PM, Jim Forster <jim@connectivitycap.com> wrote:

Gene, David,
=E2=80=98m 
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=_37A3E1E1-ADF7-4799-B866-1F112513F792-- --Apple-Mail=_BFB3E81B-603E-4588-BDA6-571800536BA9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEERPTGiBqcibajhTSsv0/8FiYdKmAFAmYxvhwACgkQv0/8FiYd KmDebQ//Xc9BqjdgSj4ZnTsYmBT/8XYIVA17RdASHwi5crzwpdK+KwUrIPsgXGUe ul5LoaduaFMQVhfdW2g8F1hcNblbklCaxBYeWy/t1DKZ2Nb4JLheYAadFFQaDHKS +KTk/57NfEtPLVZvaGKhyygya6urlPQhSQRonEHuCK+IBq65MnzNb+APIWDJs+TU Jnf7FDkl47un3mQBKVQnucT494QW0IYCcgp1lsaN4WWoGIeU68AQC4mF6Y3KVYxv ckq3aCBm/xvhKYUBlLLbe7ETDC98/RSTeab8evbQUNt5dclFqMb1XiMwLduDmJqk vJ2ZKSWodnDFpVTAGUnK8vQ2Eta9l+2GvXZFFLuTQ4BBrXLpunQdp5oQYC3Inxmv xNOl/FBm9ayC1HWkvCAYVHson9QnCwpGSCCkGU/yeKKRi8HnSKZ+9YrSct/O42Vq VG9q81uCLl00/7mrLLGZyJFbA0b7YoWvWar4DH18WfpQc8RPlVGEev5HoeRb76hM 4j741M3dRPqc4XwezBkWkAqitNasxwYb3Xzhc9HsJPz/CXdIv3J2qIsQhqtH/kTM YAOQ50em3bMR8lWDeih/f0ErhH0LbbRSjefoeA3MKS/OXL5OrVfbHVYg1pIXHpox gPksOxYpi6rBWYZ1PMbWvNuSExPMr1xkgpBr8lssxWlDyPo5RxI= =61Kr -----END PGP SIGNATURE----- --Apple-Mail=_BFB3E81B-603E-4588-BDA6-571800536BA9--