From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 EE4CB3CB37 for ; Wed, 1 May 2024 14:51:28 -0400 (EDT) Received: by mail-pl1-x62f.google.com with SMTP id d9443c01a7336-1eab699fcddso56081345ad.0 for ; Wed, 01 May 2024 11:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; t=1714589488; x=1715194288; 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=bg8PvNjVdRUKC4/bHK6J9s/nMVP1hl9/+soRa2Plw/4=; b=c/TMS6xef9eNWpbM9P2urHgXf2mianmR54GjD42d8Mm+bPFNPbYNZISI3z+NbUFC9j VUSy01/0K2dvaOImj2gaCYYmPI8jUG2yDGT0sJ3zfrPbuPW/q4jMeYXkskOqs2eWZM9r KpG0x+H39U2GPvdj9OP+igHeVBHaW2343oEEg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714589488; x=1715194288; 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=bg8PvNjVdRUKC4/bHK6J9s/nMVP1hl9/+soRa2Plw/4=; b=XGYVzDI1nDqqHcWlZHCYZEz7nKoXiR809r7uCbiBHTqLN/CbFg9dMjyWPowZ+vV7Nk qF8m5dcvBP44D+1de/qLQHulNPTZYf99pzSZfAFO7rcOJisu5wXoOSh5NSksWHE/P6oV W5O3YG3iauk/id/vHAeOD5cH+XOlEN9sw3QkwgPs5rzWeFxTZf3Zosi/qePrJiV1xCwU RBTg7K2T+6JX9nGE09BDRl4JhP60IT+h9qM2nDujahQmwXl07ZwaKZLT8R73/mJ2hXxR XPeNMjJclHqOWIqq/LqCTJulE0P/3wj9oB+l6nn3QjY3M6P0kLVeixs61IjWiNJpfJqI GopQ== X-Forwarded-Encrypted: i=1; AJvYcCWbjWcZV4F/OUiMqPpKViDN8YZEp3ksh79lyE32KWhZg1zuBeRLH7hJ19y3nENQ6LYiWAXdwvihWeqcc1VG0r1/InSfY6mkShdSqwj7tzs= X-Gm-Message-State: AOJu0YzgoQJTg28ipQ4c6ae7Y1SxNiVChtUgvlE4MXpl2UHHJYVQS+7w uPhuR5DkRcuu7Iv/6TQNNLQbZxACm240EkR5JHkMOlpYwTja0hSmJeHhxgJisw== X-Google-Smtp-Source: AGHT+IF0HgUKD78C4Gm3IeNL2ThMwDOLMNmhRfN0UCxVdzDxm88TriorMqVJnU7nJH85qZyEOEKitA== X-Received: by 2002:a17:902:e88d:b0:1eb:ac3c:d174 with SMTP id w13-20020a170902e88d00b001ebac3cd174mr4196449plg.2.1714589487646; Wed, 01 May 2024 11:51: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 f3-20020a170902684300b001eb2eac7012sm9566191pln.138.2024.05.01.11.51.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2024 11:51:27 -0700 (PDT) From: Eugene Y Chang Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D46F0497-61B3-4E9A-B5CC-3B30F66F08C0"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Wed, 1 May 2024 08:51:22 -1000 In-Reply-To: <13rq2389-9012-p95n-s494-q3pp070s497n@ynat.uz> Cc: Eugene Y Chang , Jim Forster , Dave Taht via Starlink , Colin_Higbie To: David Lang 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> 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 18:51:29 -0000 --Apple-Mail=_D46F0497-61B3-4E9A-B5CC-3B30F66F08C0 Content-Type: multipart/alternative; boundary="Apple-Mail=_00CDF62D-B8E3-4E0F-8640-7289261E711C" --Apple-Mail=_00CDF62D-B8E3-4E0F-8640-7289261E711C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks David, > On Apr 30, 2024, at 6:12 PM, David Lang wrote: >=20 > On Tue, 30 Apr 2024, Eugene Y Chang wrote: >=20 >> 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. >>=20 >> 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. >=20 > I did not see a very big improvement on a 4/.5 dsl link, but there was = improvement. Would a user feel the improvement with a 10 minute session: shopping on Amazon? using Salesforce? working with a shared Google doc? >=20 > if you put openwrt on the customer router and configure cake with the = targeted bandwith at ~80% of line speed, you will usually see a drastic = improvement for just about any connection. Are you saying some of the benefits can be realized with just upgrading = the subscriber=E2=80=99s router? This makes adoption harder because the = subscriber will lose the ISP=E2=80=99s support for any connectivity = issues. If a demo impresses the subscribers, the ISP still needs to = embrace this change; otherwise the ISP will wash their hands of any = subscriber problems. >=20 > If you can put fq_codel on both ends of the link, you can usually skip = capping the bandwidth. This is good if this means the benefits can be achieved with just the = CPE. This also limits the changes to subscribers that care. >=20 > unfortunantly, it's not possible to just add this to the ISPs existing = hardware without having the source for the firmware there (and if they = have their queues in ASICs it's impossible to change them. Is this just an alternative to having the change at the CPE? Yes this is harder for routers in the network. >=20 > If you can point at the dramatic decrease in latency, with no = bandwidth losses, that Starlink has achieved on existing hardware, that = may help. This is good to know for the engineers. This adds confusion with the = subscribers. >=20 > There are a number of ISPs around the world that have implemented = active queue management and report very good results from doing so. Can we get these ISPs to publically report how they have achieved great = latency reduction? We can help them get credit for caring about their subscribers. It = would/could be a (short term) competitive advantage. Of course their competitors will (might) adopt these changes and = eliminate the advantage, BUT the subscribers will retain glow of the = initial marketing for a much longer time. >=20 > But showing that their existing hardware can do it when their upstream = vendor doesn't support it is going to be hard. Is the upstream vendor a network provider or a computing center? Getting good latency from the subscriber, through the access network to = the edge computing center and CDNs would be great. The CDNs would = harvest the benefits. The other computing configurations would have make = the change to be competitive. We wouild have done our part at pushing the next round of adoption. Gene >=20 > David Lang >=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> Should we have a conference call to discuss this? >>=20 >>=20 >> Gene >> ---------------------------------------------- >> Eugene Chang >> IEEE Life Senior Member >>=20 >>=20 >>=20 >>> 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. --Apple-Mail=_00CDF62D-B8E3-4E0F-8640-7289261E711C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks David, 


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

On Tue, 30 Apr 2024, Eugene Y Chang wrote:

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.

I did not see = a very big improvement on a 4/.5 dsl link, but there was = improvement.

Would = a user feel the improvement with a 10 minute session:
  • shopping on Amazon?
  • using Salesforce?
  • working with a shared = Google doc?


if you put openwrt on the customer router and configure cake = with the targeted bandwith at ~80% of line speed, you will usually see a = drastic improvement for just about any connection.

Are = you saying some of the benefits can be realized with just upgrading the = subscriber=E2=80=99s router? This makes adoption harder because the = subscriber will lose the ISP=E2=80=99s support for any connectivity = issues. If a demo impresses the subscribers, the ISP still needs to = embrace this change; otherwise the ISP will wash their hands of any = subscriber problems.



If you can = put fq_codel on both ends of the link, you can usually skip capping the = bandwidth.

This is = good if this means the benefits can be achieved with just the CPE. This = also limits the changes to subscribers that care.

unfortunantly, = it's not possible to just add this to the ISPs existing hardware without = having the source for the firmware there (and if they have their queues = in ASICs it's impossible to change them.

Is this just an alternative to having the change = at the CPE?
Yes this is harder for routers in the = network.


If you can = point at the dramatic decrease in latency, with no bandwidth losses, = that Starlink has achieved on existing hardware, that may = help.

This = is good to know for the engineers. This adds confusion with the = subscribers. 


There are a number of ISPs around the world that have = implemented active queue management and report very good results from = doing so.

Can = we get these ISPs to publically report how they have achieved great = latency reduction?
We can help them get credit for caring = about their subscribers. It would/could be a (short term) competitive = advantage.
Of course their competitors will (might) adopt = these changes and eliminate the advantage, BUT the subscribers will = retain glow of the initial marketing for a much longer = time.



But showing that their existing hardware can do it when their = upstream vendor doesn't support it is going to be hard.

Is the = upstream vendor a network provider or a computing = center?
Getting good latency from the subscriber, through the = access network to the edge computing center and CDNs would be great. The = CDNs would harvest the benefits. The other computing configurations = would have make the change to be competitive.

We wouild have done our part at pushing the next = round of adoption.

Gene


David = Lang


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 <mailto: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=_00CDF62D-B8E3-4E0F-8640-7289261E711C-- --Apple-Mail=_D46F0497-61B3-4E9A-B5CC-3B30F66F08C0 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/8FiYdKmAFAmYyjysACgkQv0/8FiYd KmAj5Q/+KhUANdwwv4cpWX7QHj2DJXfiYcHkZ4LIyc5RrXOxzr+MhesJXO5eP7K3 8Hsan6ZrDbVV1dOCGjl+ZGQyI9NY+k/f0qlfMqTCw81LttkXVVQaQCPOkSVp6vtH Fmpl/NOFilKVPZemGEwGem7I0+nXwT/TCmHyd2HdQWHaUfR9xnOTD8xVUfzBx4+O zGABVbrhtHuse6zo1JXklYCwb0Pr6gknVetowyaOU6+IOkwvRxTY6Kq7S/xmvmjc 8Lhfamco3CNoACMZh426hYvZ+IsoYbjm5qmLGlgWVfFX8W2fUA/5E3WFxVH58EOi 68q4MyuK4BWME69Aiz4TTzhgjM7swHKW5aT5kqhVw1DfpfqX1MCXUxoztx5f++mq 2GY2ifx1OTen2QHYYiEXxOqznG4UHEpoX4nRyNbWzEfU11RKnz+iB1KI/syV1B/p Ssae6QJsklYZmbJ4cPQKh8I9ZK1a8Sc2Ee/a0mAGlZium5bzHWlNm0tnvWNp9OLh L2Wu249GrNxY/kNGmZiR3Q5qaG01PFtRNQmCigGUIQFXNVsqWp5AfcsiXcqHvwt8 kjb7KhWKZcq2cLVVWi5z582Tpo7bsiynWLXP9kvub8agajZ1jd36+XRAj2UhN/qk t6MY2NdYPcgDWQYAPmn7RaOgb+yAhgBA9dSIv8WIcpH/h2BvSoA= =/85p -----END PGP SIGNATURE----- --Apple-Mail=_D46F0497-61B3-4E9A-B5CC-3B30F66F08C0--