Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Eugene Y Chang <eugene.chang@ieee.org>
To: Jim Forster <jim@connectivitycap.com>
Cc: Eugene Y Chang <eugene.chang@ieee.org>,
	David Lang <david@lang.hm>,
	Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
	Colin_Higbie <CHigbie1@Higbie.name>
Subject: Re: [Starlink] Itʼs the Latency, FCC
Date: Tue, 30 Apr 2024 17:59:24 -1000	[thread overview]
Message-ID: <F6BF9FB9-1DA4-445E-ABF2-D35AB146EA56@ieee.org> (raw)
In-Reply-To: <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com>


[-- Attachment #1.1: Type: text/plain, Size: 3431 bytes --]

I’m 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 “so dramatic” 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’t 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,
> ‘m
> Agreed that the technical problem is largely solved with cake & codel.
> 
> Also that demos are good. How to do one for this problem>
> 
>   — 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’t 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’d 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’t 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 “graceful” 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.
> 


[-- Attachment #1.2: Type: text/html, Size: 11530 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-05-01  3:59 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` [Starlink] It’s " Colin_Higbie
2024-04-30 19:04   ` Eugene Y Chang
2024-05-01  0:36     ` David Lang
2024-05-01  1:30       ` [Starlink] Itʼs " Eugene Y Chang
2024-05-01  1:52         ` Jim Forster
2024-05-01  3:59           ` Eugene Y Chang [this message]
2024-05-01  4:12             ` David Lang
2024-05-01 10:15               ` Frantisek Borsik
2024-05-01 18:51               ` Eugene Y Chang
2024-05-01 19:18                 ` David Lang
2024-05-01 21:11                   ` Frantisek Borsik
2024-05-01 22:10                     ` Eugene Y Chang
2024-05-01 21:12                   ` Eugene Y Chang
2024-05-01 21:27                     ` Sebastian Moeller
2024-05-01 22:19                       ` Eugene Y Chang
2024-05-06 11:25                         ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
2024-05-06 12:11                           ` Dave Collier-Brown
2024-05-07  0:43                             ` Eugene Y Chang
2024-05-07 12:05                               ` Dave Collier-Brown
     [not found]                           ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
2024-05-06 19:47                             ` Rich Brown
2024-05-07  0:38                           ` Eugene Y Chang
2024-05-07 10:50                             ` Rich Brown
2024-05-08  1:48                           ` Dave Taht
2024-05-08  7:58                             ` Frantisek Borsik
2024-05-08  8:01                               ` Frantisek Borsik
2024-05-08 18:29                             ` Eugene Y Chang
2024-06-04 18:19                             ` Stuart Cheshire
2024-06-04 20:06                               ` Sauli Kiviranta
2024-06-04 20:58                                 ` Eugene Y Chang
2024-06-05 11:36                                   ` Alexandre Petrescu
2024-06-05 13:08                                     ` Aidan Van Dyk
2024-06-05 13:28                                       ` Alexandre Petrescu
2024-06-05 13:40                                         ` Gert Doering
2024-06-05 13:43                                           ` Alexandre Petrescu
2024-06-05 14:16                                             ` David Lang
2024-06-05 15:10                                               ` Sebastian Moeller
2024-06-05 16:21                                           ` Alexandre Petrescu
2024-06-05 19:17                                     ` Eugene Y Chang
2024-06-04 23:03                               ` Rich Brown
2024-06-04 23:36                                 ` [Starlink] Consumer Reportes (was: The "reasons" that bufferbloat isn't a problem) David Collier-Brown
2024-06-06 17:51                                 ` [Starlink] The "reasons" that bufferbloat isn't a problem Stuart Cheshire
2024-06-07  2:28                                   ` Dave Taht
2024-06-07  5:36                                     ` Sebastian Moeller
2024-06-07  7:51                                       ` Gert Doering
2024-05-02 19:17         ` [Starlink] Itʼs the Latency, FCC Michael Richardson
2024-05-02  9:09     ` [Starlink] It’s " Alexandre Petrescu
2024-05-02  9:28       ` Ulrich Speidel
2024-04-30 20:05   ` Sebastian Moeller
2024-05-02  9:21     ` Alexandre Petrescu
     [not found] <mailman.2785.1714507537.1074.starlink@lists.bufferbloat.net>
2024-04-30 20:48 ` Colin  Higbie
2024-05-01  0:51   ` David Lang
2024-05-01  2:46     ` [Starlink] Itʼs " Colin_Higbie
2024-05-01  3:18       ` David Lang
2024-05-01  3:38         ` Colin_Higbie
2024-05-01  3:51           ` David Lang
2024-05-01  4:16             ` Colin_Higbie
2024-05-01  7:40               ` David Lang
2024-05-01 15:13                 ` Colin_Higbie
2024-05-01  3:54       ` James Forster
     [not found] <mailman.11.1710518402.17089.starlink@lists.bufferbloat.net>
2024-03-15 18:32 ` [Starlink] It’s " Colin  Higbie
2024-03-15 18:41   ` Colin_Higbie
2024-03-15 19:53     ` Spencer Sevilla
2024-03-15 23:07       ` David Lang
2024-03-16 18:45         ` [Starlink] Itʼs " Colin_Higbie
2024-03-16 19:09           ` Sebastian Moeller
2024-03-16 19:26             ` Colin_Higbie
2024-03-16 19:45               ` Sebastian Moeller
2024-03-16 23:05           ` David Lang
2024-04-30  0:39   ` [Starlink] It’s " David Lang
2024-04-30  1:30     ` [Starlink] Itʼs " Colin_Higbie
2024-04-30  2:16       ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F6BF9FB9-1DA4-445E-ABF2-D35AB146EA56@ieee.org \
    --to=eugene.chang@ieee.org \
    --cc=CHigbie1@Higbie.name \
    --cc=david@lang.hm \
    --cc=jim@connectivitycap.com \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox