From: "Holland, Jake" <jholland@akamai.com>
To: Pete Heist <pete@heistp.net>, Steven Blake <slblake@petri-meat.com>
Cc: ECN-Sane <ecn-sane@lists.bufferbloat.net>
Subject: Re: [Ecn-sane] IETF 110 quick summary
Date: Tue, 9 Mar 2021 19:51:25 +0000 [thread overview]
Message-ID: <50EBED98-7DCB-4EA0-9188-D396931F890F@akamai.com> (raw)
In-Reply-To: <5044a75f097ab4c737a59c084e863ff89e97741c.camel@heistp.net>
On 3/9/21, 10:13 AM, "Pete Heist" <pete@heistp.net> wrote:
> On the one hand, the argument is that 3168 is *not* widely deployed
> when it comes to safety with existing AQMs, and on the other hand, it
> *is* widely deployed when it comes to selection of the identifier. I
> think this finally needs bringing up, maybe tomorrow.
I think they rephrased section B.2 to match up with this.
Although B.5 probably does need some editorial work, I think the
technical explanation is mostly the same as what's covered in B.2,
so bringing this up probably has limited utility.
I won't deny that there's some weird shifting of the purported
reasoning behind stable conclusions, but I'll suggest that IMHO
you're better off keeping the focus on the real crux of the issue,
which I think is correctly articulated as harm to bystanders by
deploying a new codepoint assignment for ECT(1) without first proving
it can be used effectively without harm by most traffic under the
prior meaning of that codepoint.
(I'm less sure about the tunnels, which seem to be considered both
so common that FQ can't address their latency and also ignorable wrt
harm from sharing classic 3168 and TCP Prague traffic. Raising
this point might at least bring them around on the idea that tunnels
could be split by flows when it's useful, but probably also has
limited utility overall.)
> We had a conversation late last year around instead making a
> discontinuous upgrade to ECN/SCE by redefining ECT(0) to be the
> identifier, and I spent some time thinking about it. It's not without
> issues, but I wouldn't mind hearing other's thoughts on it before I
> pollute it with mine.
They did at least update the draft to speak to this point in
l4s-id B.3. I think the biggest objection on their side was that it's
not a good classifier with chained aqms, and this problem gets worse
as deployment increases.
I still kinda like it as the least harmful, mostly only helpful
option (assuming endpoints who negotiate support will also do better
RACK-like support for reordering and switches will stop trying to do
it). While it doesn't provide a great classifier, it at least
provides a crappy one that doesn't hurt that much when you're wrong.
-Jake
next prev parent reply other threads:[~2021-03-09 19:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 23:47 Pete Heist
2021-03-08 23:57 ` Dave Taht
2021-03-09 2:13 ` Holland, Jake
2021-03-09 4:06 ` Steven Blake
2021-03-09 9:57 ` Pete Heist
2021-03-09 13:53 ` Jonathan Morton
2021-03-09 14:27 ` Sebastian Moeller
2021-03-09 14:35 ` Dave Taht
2021-03-09 17:31 ` Steven Blake
2021-03-09 17:50 ` Steven Blake
2021-03-09 18:07 ` Rodney W. Grimes
2021-03-09 18:13 ` Pete Heist
2021-03-09 19:51 ` Holland, Jake [this message]
2021-03-09 20:53 ` Pete Heist
2021-03-09 18:44 ` Holland, Jake
2021-03-09 19:09 ` Jonathan Morton
2021-03-09 19:27 ` Holland, Jake
2021-03-09 19:42 ` Jonathan Morton
2021-03-09 8:43 ` Pete Heist
2021-03-09 15:57 ` Holland, Jake
2021-03-09 11:06 ` Jonathan Morton
2021-03-09 8:21 ` Pete Heist
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=50EBED98-7DCB-4EA0-9188-D396931F890F@akamai.com \
--to=jholland@akamai.com \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=pete@heistp.net \
--cc=slblake@petri-meat.com \
/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