[tsvwg] L4S and the detection of RFC3168 AQMs

["[e-mail]" <[e-mail]>]

Hi all,

 At present the DUALQ draft leaves it to implementers to decide if traffic in the classic queue (IE, ECT(0) traffic that uses currently standard congestion controllers) should be dropped or marked (except, apparently, when an ECT(0) packet for some reason turns up in the L queue?). Perhaps it would be wise to specify that during the experiment, deployments of L4S AQMs (whether DUALQ or the other alternatives mentioned in draft-ietf-tsvwg-l4s-arch) SHOULD NOT (or maybe even MUST NOT) mark ECT(0) traffic, and only drop. This would be to preserve the fact that, as currently, those RFC3168 AQMs which are unaware of L4S, can be identified by the fact that they mark ECT(0) packets with CE. If L4S AQMs are required not to mark ECT(0) as CE, then if an endpoint (or other monitoring method) sees a CE mark on an otherwise ECT(0) flow, then it knows with more or less 100% confidence that an RFC3168-only AQM is on the path.

Presumably this is safe, since L4S nodes are required to be able to support Not-ECT traffic, and ECT(0) traffic is required to be able to cope with drop.

 At present the only definitive way for endpoints identify an RFC3168 AQM in use, is to observe CE marks on an ECT(0) marked flow.
Bob's paper [1] gives various other methods, but this seems to be a research project at present. If any of these approaches were found to be reliable, then the above requirement could be relaxed fairly easily; the reverse is not so easy.

There are, as is probably obvious, a number of reasons for wanting to identify RFC3168 AQMS:
 - Current efforts to gather statistics on the number of RFC3168 AQMs which might encounter problems when L4S traffic passes through them.
 - The the ops draft (sec 3.1)  envisages that CDN operators should test for the presence of RFC3168 AQMs, but doesn't yet specify how this should be achieved
 - Within a L4S transport protocol, in order to fall back to RFC3168 behavior

All of these would presumably be assisted by being able to classify observed ECT(0)->CE transitions unambiguously being the result of an L4S-unaware node.

Unless I'm missing something it seems very much worth considering to restrict L4S marking behavior of ECT(0) for the time being?

I am not sure which drafts would need updating; DUALQ at least, but presumably the ops draft and maybe L4S-arch.

regards,

Alex

[1] https://arxiv.org/pdf/1911.00710.pdf