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

["David Fernández" <davidfdzp@gmail.com>]

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 <moeller0@gmx.de>:
> Hi,
>
> See [SM] below.
>
> On 21 December 2022 08:37:27 CET, "David Fernández via Starlink"
> <starlink@lists.bufferbloat.net> 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 <rjmcmahon@rjmcmahon.com>
>>> To: Sebastian Moeller <moeller0@gmx.de>
>>> Cc: rjmcmahon via Make-wifi-fast
>>> 	<make-wifi-fast@lists.bufferbloat.net>, Dave Täht
>>> 	<dave.taht@gmail.com>, Rpm <rpm@lists.bufferbloat.net>, libreqos
>>> 	<libreqos@lists.bufferbloat.net>, Dave Taht via Starlink
>>> 	<starlink@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>
>>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast
>>> 	2016 &	crusader
>>> Message-ID: <4e8ee21b1a69fba9c61366f6055fbc13@rjmcmahon.com>
>>> 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.
>