Re: [tsvwg] L4S drafts: Next Steps

[Jonathan Morton <[e-mail]>]

> On 10 Dec, 2020, at 12:28 am, Black, David <[e-mail]> wrote:
> 
> Reminder of the goal for [1] (Rework the “Prague Requirements” into the following two entities ...):

>      >> Success of this exercise will be judged by the WG reaching “rough consensus” that multiple transport protocol implementations
>      >> currently meet and/or are reasonably expected to be able to meet the normative requirements (a).

> If the L4S folks believe that this has already been done, then it’s time to start bringing forward the multiple transport protocols that demonstrate success of that exercise. 

To amplify this point, I would like to emphasise that neither TCP Prague, nor DCTCP, nor the modified version of SCReAM meet the following requirement, presently documented as a MUST:

   o  A scalable congestion control MUST implement monitoring in order
      to detect a likely non-L4S but ECN-capable AQM at the bottleneck.
      On detection of a likely ECN-capable bottleneck it SHOULD be
      capable (dependent on configuration) of automatically adapting its
      congestion response to coexist with TCP Reno congestion controls
      [RFC5681] (see Appendix A.1.4 for rationale and a referenced
      algorithm).

SCReAM, last I checked, has no code to implement the detection heuristic.  Neither does DCTCP.  TCP Prague has it implemented, but disabled by default, and when enabled the cited algorithm proved to not be reliable enough to satisfy a MUST requirement.  That strongly suggests that you have some work to do in this area.

Let me be clear: coexistence with RFC-3168 infrastructure and conventional AIMD traffic is mandatory, not optional, if an Internet-wide experiment is contemplated.

 - Jonathan Morton