Re: [Ecn-sane] IETF 110 quick summary

[Pete Heist <pete@heistp.net>]

On Tue, 2021-03-09 at 19:51 +0000, Holland, Jake wrote:
> 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.

Ok, I'll trust that. I think they mainly meant there that they didn't
want Apple devices polluting their green field L queue.

> 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.)

These are good points. It's true that when we've tried to present
arguments in teh past that waiver from these fundamental safety issues,
they've almost never landed and end up being better left unsaid, or
just written on the list.

> > 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.

By now I think of that idea as B.Jake. While I understood their loss of
classification argument, it's a definite improvement on flow
starvation. :)

> -Jake
> 
>