Re: [tcpm] A possible simplification for AccECN servers

[Jonathan Morton <[e-mail]>]

> On 11 Dec, 2019, at 8:07 pm, Matt Mathis <[e-mail]> wrote:

> Content providers who are using some version of DCTCP are constrained to use the same switch markings for all flows.  It is inconceivable that anybody would do 3168 in such an environment, however DCTCP and AccECN are likely to work well enough to fly.

Content providers SHOULD NOT be using DCTCP on the open Internet.  That is the environment with which I am chiefly concerned.

If they want to screw up their internal environments, that's no skin off my nose.

> I think you underestimate how quickly server side 3168 will evaporate once AccECN is far enough along, especially if we are explicit about discouraging distros from shipping it on by default, so the only server side 3168 is by people who are engaged in the research.   Remember, by default content providers must stay up to date with upstream bug fixes.

In other words, you are actively advocating for the deprecation of RFC-3168, just as it is gaining traction and actively being deployed in the real world.  You may expect me to object to that at every opportunity, given the work I've put into ECN-related technologies in the past several years, and the clear advantages that RFC-3168 shows for general Internet traffic.  I think certain industry members would also object on a similar basis.

If I may be cynical for a moment, I also note that coexistence between AccECN/L4S and SCE was a topic discussed at and around IETF-106.  This is one of the cornerstones of potentially allowing the L4S and SCE experiments to run in parallel, and we in the SCE team have been careful to ensure that we can coexist with AccECN/L4S endpoints, on the assumption that both schemes would retain RFC-3168 compliance as a fallback position.  This notion that dropping RFC-3168 support would become the norm appears, to us, to be explicitly designed to damage SCE's prospects.  I sincerely hope that is not actually the case, but given appearances I would ask for a clarification of that point.

The existing text in AccECN mandates falling back both halves of the connection to RFC-3168 mode if either end supports it but not AccECN, and the other end supports AccECN.  I supported moving AccECN forward (as EXP) with that language in place.  I would feel obliged to withdraw that support if the text were changed to make RFC-3168 support any less than a SHOULD at the server end and a MUST at the client end - noting that the definition of SHOULD is that a pretty solid justification has to be made for not following the point.

 - Jonathan Morton