[Ecn-sane] IETF 110 quick summary

[Holland, Jake]

On 3/9/21, 10:13 AM, "Pete Heist" <pete at 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