From: Sebastian Moeller <moeller0@gmx.de>
To: Stuart Cheshire <cheshire@apple.com>
Cc: bloat <bloat@lists.bufferbloat.net>, rpm@lists.bufferbloat.net
Subject: Re: [Rpm] [Bloat] Apple WWDC 2022 presentation on L4S now available
Date: Thu, 9 Jun 2022 20:30:21 +0200 [thread overview]
Message-ID: <A1FA7E6F-2200-4C01-9B92-7A406C1E6976@gmx.de> (raw)
In-Reply-To: <FBD63902-9DF0-4867-AB42-2D196D04854D@apple.com>
Nice informative video!
But:
"Comparing classic queuing versus L4S shows that there is a massive reduction in round trip time with L4S.
This is the primary reason for the dramatic improvement in my screen-sharing experience."
Seems unhelpful to me. As far as I can tell what is compared here is an oversized FIFO (multiple seconds in a local Network queueing delay) with L4S' L-queue. This hence demonstrates that AQM is better than no AQM, but seems interprets the result as argument for L4S' being a good AQM. It would be highly interesting to see how the same traffic would behave if "classic queuing" was any other AQM. Or even the "C-queue" of L4S which (while not an optimized AQM*) should also push the latency from painful multiple seconds into the dozens of milliseconds range that would be fully acceptable (and might not even be noticed). Or even just an FQ scheduler without AQM...
The other issue is that currently no L4S AQM are deployed, so I miss the "deploy L4S AQM at your network nodes" advice that seems essential for L4S actually helping**.
I understand that this video is not intended as a contribution to the academic discussion about relative merits of different AQM approaches, but still ...
Regards
Sebastian
*) After all it needs to be bad enough to make the L-queue shine in comparison, hence the surprisingly high reference target delays for e.g. DualQ's C-queue PIE implementation, with its actively misleading justification from misinterpreted/misunderstood latency data**...
**) scraped from a blog post intended to show-case how the RIPE ATLAS network can be used for real experiments, and not a peer reviewed study of typical RTTs between endusers and "the internet".
> On Jun 9, 2022, at 18:18, Stuart Cheshire via Bloat <bloat@lists.bufferbloat.net> wrote:
>
> Our colleague Vidhi Goel recorded an excellent Apple developer conference video “Reduce networking delays for a more responsive app”, which talks about bufferbloat and L4S.
>
> <https://developer.apple.com/videos/play/wwdc2022/10078/>
>
> Stuart Cheshire
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
prev parent reply other threads:[~2022-06-09 18:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 16:18 [Rpm] " Stuart Cheshire
2022-06-09 18:30 ` Sebastian Moeller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/rpm.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A1FA7E6F-2200-4C01-9B92-7A406C1E6976@gmx.de \
--to=moeller0@gmx.de \
--cc=bloat@lists.bufferbloat.net \
--cc=cheshire@apple.com \
--cc=rpm@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox