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" <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast
Message-ID: <[email protected]>
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: [email protected]
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
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Starlink mailing list
[email protected]
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
[email protected] | -- 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.
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
