From: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
To: Dave Taht <dave.taht@gmail.com>, Jonathan Morton <chromatix99@gmail.com>
Cc: ECN-Sane <ecn-sane@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] [Bloat] sce materials from ietf
Date: Fri, 29 Nov 2019 23:10:01 +0000 (UTC) [thread overview]
Message-ID: <297503679.4519449.1575069001960@mail.yahoo.com> (raw)
In-Reply-To: <63E9C0E4-C913-4B2F-8AFC-64E12489BC65@gmail.com>
On Friday, November 29, 2019, 9:51:21 PM GMT, Jonathan Morton <chromatix99@gmail.com> wrote:
> Second, I gained a couple of key insights that I think will help to solve SCE's remaining shortcomings. If we can apply them successfully by
> Vancouver, we'll be able to stand up and say not only that SCE meets *all* of the Prague Requirements, while L4S is currently missing two of them,
> but that we've also solved the single-queue problem. I'm deliberately leaving the technical details vague until we've done some testing, but I will say
> that the name we've come up with is amusing.
I don't see what you gain by going after the Prague requirements. They're internal requirements for a TCP that would fulfill the L4S goals if classified into the L4S side of a DualQ AQM: 'Packet Identification' means that the L4S AQM can identify L4S supporting flows. This seems like a distraction from your main pitch to me. It would seem better to compare against the actual goals of L4S (AFAICT, low latency at the 99th percentile, in the presence of Reno-compatible flows, with some fairness requirement which I increasingly don't understand).
Alex
next prev parent reply other threads:[~2019-11-29 23:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-29 20:08 [Ecn-sane] " Dave Taht
2019-11-29 21:20 ` [Ecn-sane] [Bloat] " Jonathan Morton
2019-11-29 23:10 ` alex.burr [this message]
2019-11-30 1:39 ` Jonathan Morton
2019-11-30 7:27 ` Sebastian Moeller
2019-11-30 14:32 ` Jonathan Morton
2019-11-30 15:42 ` Sebastian Moeller
2019-11-30 17:11 ` Jonathan Morton
2019-12-02 5:38 ` Dave Taht
2019-12-02 7:54 ` Sebastian Moeller
2019-12-02 9:57 ` Pete Heist
2019-11-30 22:17 ` Carsten Bormann
2019-11-30 22:23 ` Jonathan Morton
2019-12-01 16:35 ` Sebastian Moeller
2019-12-01 16:54 ` Jonathan Morton
2019-12-01 19:03 ` Sebastian Moeller
2019-12-01 19:27 ` Jonathan Morton
2019-12-01 19:32 ` Sebastian Moeller
2019-12-01 20:30 ` Jonathan Morton
2019-12-01 17:30 ` Rodney W. Grimes
2019-12-01 19:17 ` Sebastian Moeller
2019-12-02 5:10 ` Dave Taht
2019-12-02 7:18 ` Sebastian Moeller
2019-11-29 22:55 ` [Ecn-sane] " Rodney W. Grimes
2019-11-29 22:58 ` Rodney W. Grimes
2019-11-30 2:37 ` Dave Taht
2019-11-30 3:10 ` Rodney W. Grimes
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/ecn-sane.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=297503679.4519449.1575069001960@mail.yahoo.com \
--to=alex.burr@ealdwulf.org.uk \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dave.taht@gmail.com \
--cc=ecn-sane@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