Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: "David P. Reed" <dpreed@deepplum.com>
To: starlink-request@lists.bufferbloat.net
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast
Date: Fri, 23 Dec 2022 19:00:56 -0500 (EST)	[thread overview]
Message-ID: <1671840056.20758968@mobile.rackspace.com> (raw)

Sorry for front posting. The L2 and L3 
are following the "end to end argument". The function of the L2 network is to not queue more than absolutely necessary.
The function at L3 is to respond to congestion signals by reducing input to a fair shareof available capacity, quickly, cooperating with other L3 protocols.

This is understood by clueful L2 and L3 folks.

Clueless vendors dominate the L2 vendor space. Sadly. They refuse to stop over buffering.


Date: Fri, 23 Dec 2022 16:02:03 +0100
: David Fernández 
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast

Hi,

Sorry, maybe I did not craft the subject correctly. I am receiving the
daily digest of the list, not individual messages.

I have seen before that the L2 engineers (Wi-Fi, DVB...) and the
Internet engineers (L3) are trying to solve the same issue (QoS,
congestion control) without being aware of what each other are doing
and not even getting coordinated. I am afraid that nowadays we have
even the application layer engineers doing their own stuff (DASH,
CDNs...).

Some time ago, I worked in a project about cross-layer optimization
techniques for SATCOM systems, where one of the issues was to try to
optimize transport layer performance with L2 info. I was just a mere
observer of what academy people in the consortium where proposing.

That was quite long ago:
https://artes.esa.int/projects/ipfriendly-crosslayer-optimization-adaptive-satellite-systems

Today I came across this:
https://www.elektormagazine.com/news/white-paper-why-wi-fi-6-goes-hand-in-hand-with-cellular-to-enable-the-hyper-connected-enterprise-future

"the performance uplift of Wi-Fi 6 over Wi-Fi 5 is substantial and
more than sufficient to support innovative use cases such as automated
guided vehicles, industrial robots and many other applications."

This sound like Wi-Fi 6 will support low latency and will have a good
QoS support. Maybe...

Regards,

David

2022-12-21 8:54 GMT+01:00, Sebastian Moeller :
> Hi,
>
> See [SM] below.
>
> On 21 December 2022 08:37:27 CET, "David Fernández via Starlink"
>  wrote:
>>What about this?
>>https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-wmm-programs
>>
>>Isn't this Wi-Fi MM (Multimedia) supposed to solve Wi-Fi QoS issues?
>
>         [SM] In home network reality it failed to do so. I would guess
> partly because the admission control component is optional and as far as I
> can tell not available in the usual WiFi routers and APs. A free for all
> priority system that in addition diminishes the total achievable throughput
> when the higher priority tiers are used introduces at least as much QoS
> issues a it solves IMHO. This might be different for 'enterprise WiFi gear'
> but I have no experience with that...
>
> Regard
>       Sebastian
>
> P.S.: This feels like you might responded to a different thread than the
> iperf2 one we are in right now?
>
>
>
>>
>>> Date: Thu, 08 Dec 2022 11:04:13 -0800
>>> From: rjmcmahon 
>>> To: Sebastian Moeller 
>>> Cc: rjmcmahon via Make-wifi-fast
>>> 	, Dave Täht
>>> 	, Rpm , libreqos
>>> 	
, Dave Taht via Starlink
>>> 	, bloat 
>>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast
>>> 	2016 &	crusader
>>> Message-ID: 
>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>>
>>> Thanks for the well-written response Sebastian. I need to think more
>>> about the load vs no load OWD differentials and maybe offer that as an
>>> integrated test. Thanks for bringing it up (again.) I do think a
>>> low-duty cycle bounceback test to the AP could be interesting too.
>>>
>>> I don't know of any projects working on iperf 2 & containers but it has
>>> been suggested as useful.
>>>
>>> Bob
>>>
>>_______________________________________________
>>Starlink mailing list
>>Starlink@lists.bufferbloat.net
>>https://lists.bufferbloat.net/listinfo/starlink
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>


------------------------------

Subject: Digest Footer

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


------------------------------

End of Starlink Digest, Vol 21, Issue 14
****************************************



             reply	other threads:[~2022-12-24  0:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-24  0:00 David P. Reed [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-01-02 17:35 David Fernández
2023-01-02 18:44 ` Ben Greear
2023-01-02 18:57   ` Dave Collier-Brown
2023-01-02 19:00   ` Sebastian Moeller
2023-01-03  7:44     ` David Fernández
2023-01-03  8:18       ` Sebastian Moeller
2023-01-02 19:14   ` Dave Taht
2023-01-03  9:00     ` David Fernández
2022-12-21  7:37 David Fernández
2022-12-21  7:54 ` Sebastian Moeller
2022-12-23 15:02   ` David Fernández

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=1671840056.20758968@mobile.rackspace.com \
    --to=dpreed@deepplum.com \
    --cc=starlink-request@lists.bufferbloat.net \
    --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