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

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

[David P. Reed]

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
****************************************

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

[David Fernández]

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.

> 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.
>>
>

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

[Ben Greear]

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

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

[Dave Collier-Brown]

Since the speed of light is relatively fixed, I wonder if we could come
up with a memorable equation for how much buggering one needs for a
given RTT?

Preferably as memorable as E=MC^2

B <= C / RTT ? (:-))

--dave

On 1/2/23 13:44, Ben Greear via Starlink 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.
>
> 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
>>
>
>
--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com |              -- Mark Twain


CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

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

[Sebastian Moeller]

> On Jan 2, 2023, at 19:44, Ben Greear via Starlink <starlink@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.
> 
> It is a long grind of tricky code and careful and widely varied testing
> to make progress in this area.

Also the (maximum) buffer size becomes far less relevant if the buffer is properly managed...

Over-sized and under-managed, that is the problematic combination.

That said, part of the challenge is that throughput is easy to measure and is actively marketed and consumers have learned to look for these numbers.
So manufacturers increasing throughput by enlarging buffers is at least understandable in our market economy.
This is why it is important to educate end-users and supply easy tools to allow them to effortlessly measure the effect of over-buffering on interactivity.

Regards
	Sebastian



> 
> 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
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

[David Fernández]

Well, as an end-user, I would expect that the communication system is
just properly engineered, not having to check if it is or not properly
built.

Only advanced users would be using monitoring tools to assess the
quality of what they are getting.

It is somehow like pretending people to analyze the tap water at home
to check its quality. Of course, if it is easier, more and more people
will do it, but usually people just get a feeling of how things work,
most of them are not going to measure anything quantitatively, even if
it is super-easy.

Then, there is the so called brand or reputation factor. Getting a
reputation of good service is important not only for Starlink, but the
whole SATCOM sector. SATCOM is considered the last resource,
expensive, lagging and to be used when nothing else is available. If
it succeeds in not getting bankrupt and keeping a good service, as
perceived by users, Starlink could be changing that.

Regards,

David

2023-01-02 20:00 GMT+01:00, Sebastian Moeller <moeller0@gmx.de>:
>
>
>> On Jan 2, 2023, at 19:44, Ben Greear via Starlink
>> <starlink@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.
>>
>> It is a long grind of tricky code and careful and widely varied testing
>> to make progress in this area.
>
> Also the (maximum) buffer size becomes far less relevant if the buffer is
> properly managed...
>
> Over-sized and under-managed, that is the problematic combination.
>
> That said, part of the challenge is that throughput is easy to measure and
> is actively marketed and consumers have learned to look for these numbers.
> So manufacturers increasing throughput by enlarging buffers is at least
> understandable in our market economy.
> This is why it is important to educate end-users and supply easy tools to
> allow them to effortlessly measure the effect of over-buffering on
> interactivity.
>
> Regards
> 	Sebastian
>
>
>
>>
>> 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
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>
>

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

[Sebastian Moeller]

Hi David,

On 3 January 2023 08:44:39 CET, "David Fernández via Starlink" <starlink@lists.bufferbloat.net> wrote:
>Well, as an end-user, I would expect that the communication system is
>just properly engineered, not having to check if it is or not properly
>built.

[SM] That would indeed be great, however there really are competing interpretations on what 'properly engineered' entails. E.g. the throughput-fixated view that results often in oversized buffers and a more balanced view that wants decent throughput with acceptable responsiveness (for varying values of 'decent' and 'acceptable') as well as likely a completely responsiveness-fixated perspective. How should your gear manufacturer know which to engineer for? ATM most gear is marketed for 'top-speed' (throughput) and mostly marketed like that. To be explicit, I consider such an almost exclusive throughput focus to be sub-optimal and even misguided, but I understand where manufacturers are coming from.

>
>Only advanced users would be using monitoring tools to assess the
>quality of what they are getting.

[SM] At least in the EU the situation with internet access link quality (delivering the contracted rates) got bad enough to prod the EU into releasing a transparency regulation (regulation 2015/2122 IIRC) that included a call for national regulators to implement official speed test sites so end-users can fairly measure their achieved throughput. This is not aimed at advanced users, but all users.

>
>It is somehow like pretending people to analyze the tap water at home
>to check its quality. 

[SM] I am not sure that is a helpful analogy for internet access or network gear. Also at least over here water supply is heavily regulated and controlled and mostly in communal ownership (all of which I consider good things), but that might be a peculiarity of where I live. 

> Of course, if it is easier, more and more people
>will do it, but usually people just get a feeling of how things work,
>most of them are not going to measure anything quantitatively, even if
>it is super-easy.

[SM] That I agree with, however inside our market economies the most promising way to change what manufacturers are delivering is by changing what customers ask for. That includes big customers like ISPs but also end-users that might not buy big-iron routers but mere 'plastic' CPE.

>
>Then, there is the so called brand or reputation factor. Getting a
>reputation of good service is important not only for Starlink, but the
>whole SATCOM sector. SATCOM is considered the last resource,
>expensive, lagging and to be used when nothing else is available. If
>it succeeds in not getting bankrupt and keeping a good service, as
>perceived by users, Starlink could be changing that.

[SM] Well starlink's biggest advantage is in being the first affordable low earth orbit network (IIRC iridium was earlier and allowed normal end users to transfer data but at a prohibitive price) so they usher in the new generation of SATCOM. I agree that if they play their hand well, thay could establish themselves as the dominant player in that segment for years to come (assuming their so farr 'vapour-competitors' will ever built usable constellations, other wise starlink will stay dominant by default).

But I mostly agree with your sentiment, it would be nice if networking gear was designed and configured for good responsiveness by default.

Regards
         Sebastian


>
>Regards,
>
>David
>
>2023-01-02 20:00 GMT+01:00, Sebastian Moeller <moeller0@gmx.de>:
>>
>>
>>> On Jan 2, 2023, at 19:44, Ben Greear via Starlink
>>> <starlink@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.
>>>
>>> It is a long grind of tricky code and careful and widely varied testing
>>> to make progress in this area.
>>
>> Also the (maximum) buffer size becomes far less relevant if the buffer is
>> properly managed...
>>
>> Over-sized and under-managed, that is the problematic combination.
>>
>> That said, part of the challenge is that throughput is easy to measure and
>> is actively marketed and consumers have learned to look for these numbers.
>> So manufacturers increasing throughput by enlarging buffers is at least
>> understandable in our market economy.
>> This is why it is important to educate end-users and supply easy tools to
>> allow them to effortlessly measure the effect of over-buffering on
>> interactivity.
>>
>> Regards
>> 	Sebastian
>>
>>
>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>
>>
>_______________________________________________
>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.

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 7588 bytes --]

On Mon, Jan 2, 2023 at 10:44 AM Ben Greear via Starlink
<starlink@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@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
>
> _______________________________________________
> Starlink mailing list
> Starlink@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

[-- Attachment #2: 2ghz.png --]
[-- Type: image/png, Size: 75270 bytes --]

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

[David Fernández]

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@gmail.com>:
> On Mon, Jan 2, 2023 at 10:44 AM Ben Greear via Starlink
> <starlink@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@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
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@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
>

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

[David Fernández]

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?

> 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
>

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

[Sebastian Moeller]

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 then 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.

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

[David Fernández]

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.
>