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

[Ben Greear <greearb@candelatech.com>]

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.

It is a long grind of tricky code and careful and widely varied testing
to make progress in this area.

Thanks,
Ben

> 
>> Date: Fri, 23 Dec 2022 19:00:56 -0500 (EST)
>> 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
>> Message-ID: <1671840056.20758968@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@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.
>>>
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com