[tsvwg] L4S and the RACK requirement

[Wesley Eddy <[e-mail]>]

In discussion among the TSVWG chairs, we are concerned about lack of 
consensus on the requirement currently in L4S ID draft ( 
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-05 ) regarding 
the need for RACK-like behavior in a transport that uses the L4S queue.

The statement in the draft is:

     A scalable congestion control MUST detect loss by counting in units 
of time, which is scalable, and MUST NOT count in units of packets (as 
in the 3 DupACK rule of traditional TCP), which is not scalable (see 
Appendix A.1.7 for rationale).

By saying this, it seems to rule out DCTCP and some other existing code 
that might be used with L4S (and DCTCP discussed in the draft as an 
example scalable transport, even though it violates this rule (?)).  
This seems like a bit of a problem for making L4S usable.  I guess maybe 
TCP Prague code fixes this, but isn't as widely available yet?

The discussion in the appendix is good at explaining what I think the 
real goal is here, which is to enable major reduction in latency from 
link-layer (or other underlying transport network) re-ordering buffers.  
We want that in order to meet the low latency goals, which makes total 
sense.

So, my question is whether the "MUST" is really more appropriately 
turned into a "SHOULD" guidance?  Given that we expect reordering to be 
possible (and maybe normal) over hops supporting L4S, then the 
congestion control algorithm SHOULD have mechanisms that allow it to 
perform robustly.  If it doesn't, it only hurts itself, not any other 
traffic, so there seems to be no real reason to say "MUST" (someone 
violating it doesn't break the Internet or cause interop issues, etc).  
As I understand it, this would allow the examples like DCTCP to be 
relevant for use with L4S as well.

Does Bob or anyone else have thoughts on this?