Subject: [tsvwg] planning to close L4S issue #21

From: Wesley Eddy <[email-masked]>
Date: Thu, 4 Jun 2020 16:25:22 -0400

I think that issue #16 and #17 (which are on L4S interactions with 3168 
ECN and FQ AQMs) are more specific and cover the same concern as issue 
#21 ("CE codepoint semantics").

I am planning to close issue #21 as a duplicate, but wanted to run this 
by the WG first to make sure I haven't missed something.

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Fri, 5 Jun 2020 06:30:07 -0700 (PDT)

> by the WG first to make sure I haven't missed something.

IMHO, it would be better to solve the problems in the issues rather
than try to close the issues as duplicates of each other.  If you
solve the problem in #16 and #17 it may very well include solving
the problem in #21 and you could then close them all.

Attempts to just "close" issues because they seem similiar
is a road rittled with pot holes.  Good engineering would dictate
that you solve problems, not simply delete them from your objective
list because you think they are the same as another problem.

It appears to me that your trying to make the work load look
less by deleting the list of items that need to be solved,
this does not in anyway reduce the work that shall need to
be completed in order for L4S to be a viable solution.

-- 
Rod Grimes                                                 [email-masked]

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 5 Jun 2020 10:20:23 -0400

> the problem in #21 and you could then close them all.

Let's try again ... I'm asking if people agree at this point that #16 
and #17 cover the concern of #21 completely.  I thought this might be 
the case, and am checking that with the group.  As you might remember, 
we created this issues list to help detangle the discussions and focus 
on specific things that had come up.  We knew from the outset that there 
was some overlap and linkages between them that needed to be explored, 
and that's been happening.

If there's a specific aspect of #21 that justifies keeping it separate, 
that's what I'm hoping someone will bring up.  This is without any 
regard to engineering philosophy or workload optics. I don't care either 
way, but am trying to update the issues list and don't see currently 
that there's anything specific to do about this one beyond #16 and #17.  
Hopefully this is more clear.

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 5 Jun 2020 19:57:20 +0300

> On 5 Jun, 2020, at 5:20 pm, Wesley Eddy <[email-masked]> wrote:
> 
> If there's a specific aspect of #21 that justifies keeping it separate, that's what I'm hoping someone will bring up.  This is without any regard to engineering philosophy or workload optics.

Referring back to notes I took for the Montreal meeting, which IIRC was where these issues were first drawn up, each issue corresponds roughly to a line item on some slides provided by the Chairs, then referred to by a letter code.  I recall standing up and talking specifically about a linked group of four such points:

F: RFC-8311 does not in itself modify RFC-3168 to permit the redefinitions of ECT(1) and CE that L4S demands.  Instead it refers to a requirement for specific IETF approval before that may be done, specifically with respect to Congestion Response Differences.  This is essentially issue #21.

No such approval with respect to CE has been given to date, as far as I know.  Even if we accept the recent decision to go forward with development of ECT(1) as an input (which, incidentally, I do not), that cannot be taken as an explicit confirmation that the alternate response to CE proposed by L4S is also accepted.  By contrast the modified Multiplicative Decrease response specified by RFC-8511 *has* been officially approved, by publication in an RFC, on the grounds that it is sufficiently compatible with existing practice.

G: Incremental deployment requires compatibility with RFC-3168 AQMs, which (still) has not been demonstrated satisfactorily.  We had serious theoretical concerns which we had been able to validate by experiment, partly at the Montreal Hackathon.  Of course we have refined those results further since then.  I think this may refer to issue #22.

A: This was essentially issue #16.

B: This was essentially issue #17.

It is clear that there's a lot of common ground between the above four points, which is why I addressed them together in a single narrative at Montreal.  It might have been sensible to combine them into a single issue for tracking at that time, but I think the points that were substantiated at that meeting were just mechanically transcribed into the issue tracker.

Philosophically you could regard issue #16 (at least) as subordinate to #21, in that the latter essentially causes the former.  Solve #21 by adopting a different, non-ambiguous signalling mechanism for the high-fidelity congestion signal, and it seems likely (especially given our practical evidence to that effect) that issue #16 will also be solved.

Alternatively, we could regard #16 as the essential problem that must be solved, and #21 as the most likely culprit.  This would make #21 the more specific issue, and #16 the more general one, the reverse of what was suggested.

 - Jonathan Morton