[Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast

Tue Jan 3 04:00:37 EST 2023

When you say that we have proven that TCP's congestion controls can
scale to the moon and back, do you refer to the results gathered about
the Callisto system tests in the Artemis I Orion capsule?

Regards,

David

2023-01-02 20:14 GMT+01:00, Dave Taht <dave.taht at gmail.com>:
> On Mon, Jan 2, 2023 at 10:44 AM Ben Greear via Starlink
> <starlink at lists.bufferbloat.net> wrote:
>>
>> On 1/2/23 9:35 AM, David Fernández via Starlink wrote:
>> > Just wondering how comes that buffering is not standardized. Wondering
>> > why buffer sizes are left to implementation decisions of possibly
>> > clueless vendors, which devices can worsen the performance of the
>> > network.
>>
>> There is no perfect answer, and every configuration has some trade-off.
>
> Too many off-the-shelf things are still bigger than a BDP by a factor of
> 4-100.
>
> My christmas present to myself was a new chromebook, with all the
> shiny stuff in it like 2.5gbit ethernet and wifi6. I felt it would be
> "Better". It must be better, right?
>
> (it's an acer chromebook 516GE for the record)
>
> My prior chromebook (drowned, unfortunately), had had our fq-codel-for
> wifi stuff in it and performed well at all rates and distances.
>
> This box, at 2 feet from the AP, at 2ghz, has 2.5s of latency built
> into it. One of the many things that makes me crazy about chromebooks
> is that they are so safe you are locked in a container 2 hops away
> from the internet, unable to use lspci to see what hardware you have,
> or any means into the "google" side of your own box. I worry about the
> packets coming out of that side, a lot....
>
> The 5ghz side is full of 100+ms of jitter at all rates for no reason I
> can determine. Could be the AP, could be the chromebook. There's a
> blog entry pending...
>
>> It is a long grind of tricky code and careful and widely varied testing
>> to make progress in this area.
>
> If we could merely cut things off at +250ms extra latency in the e2e
> transports and/or device drivers, it would be a better world, and a
> lot closer to a good, if not perfect, answer. A flag day would be
> nice. I'd prefer +60ms.
>
> On the other hand, we have now successfully proven that TCP's
> congestion controls can scale to the moon and back!
>
>>
>> Thanks,
>> Ben
>>
>> >
>> >> Date: Fri, 23 Dec 2022 19:00:56 -0500 (EST)
>> >> From: "David P. Reed" <dpreed at deepplum.com>
>> >> To: starlink-request at lists.bufferbloat.net
>> >> Cc: starlink at lists.bufferbloat.net
>> >> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast
>> >> Message-ID: <1671840056.20758968 at mobile.rackspace.com>
>> >> Content-Type: text/plain;charset=UTF-8
>> >>
>> >> 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 share of 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 at 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 at lists.bufferbloat.net
>> >>>> https://lists.bufferbloat.net/listinfo/starlink
>> >>>
>> >>> --
>> >>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> >>>
>> >>
>> > _______________________________________________
>> > Starlink mailing list
>> > Starlink at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/starlink
>> >
>>
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>
>
> --
> This song goes out to all the folk that thought Stadia would work:
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> Dave Täht CEO, TekLibre, LLC
>