[tcpPrague] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

[Bob Briscoe <[e-mail]>]

Folks,

The co-authors of ECN L4S ID have been reviewing the correctness of the 
normative 'Prague' requirements.
     See 
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3
This is the second of 2 emails, about 2 of the requirements that we 
think ought to be reworded a little.

If you agree with the rationale, but think the new wording still doesn't 
fully capture the requirement, pls suggest sthg better.
If you disagree with the rationale, pls discuss.

4.3.  Prerequisite Congestion Response
...
CURRENT:

    o  A scalable congestion control MUST react to ECN marking from a
       non-L4S but ECN-capable bottleneck in a way that will coexist with
       a TCP Reno congestion control [RFC5681  <https://tools.ietf.org/html/rfc5681>] (seeAppendix A.1.4  <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#appendix-A.1.4>  for
       rationale).

       Note that a scalable congestion control is not expected to change
       to setting ECT(0) while it falls back to coexist with Reno.
  

PROPOSED:
    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).

       Note that a scalable congestion control is not expected to change
       to setting ECT(0) while it falls back to coexist with Reno.

RATIONALE:
1/ The requirement as currently written says what an omniscient sender 
MUST do. So there's an implied requirement that a sender MUST be 
omniscient, which is of course impossible.
2/ The requirement needs to be recast to require a sender to aim to be 
as knowledgeable as possible. Then, what it does as a result needs to 
take into account the a priori likelihood of there being a non-L4S 
bottleneck present.
3/ This includes the possibility that the operator of the host knows 
that the network it serves has not deployed any single queue classic ECN 
AQM (e.g. in a CDN case they're doing out of band testing, or they've 
asked the ISP). So we've included the possibility of fall-back being 
disabled by configuration.
4/ Nonetheless, as has been pointed out on the list, there is still a 
possibility that there is a Classic ECN AQM somewhere else on the path 
(to continue the CDN example, perhaps beyond the ISP in a home network). 
The 'MUST monitor' requirement still stands to ensure the operator 
doesn't miss these cases.
5/ Then, if the server operators have disabled fall-back for their 
deployment, they can reconsider their policy or at least do more focused 
testing if they are frequently detecting a single-queue Classic ECN AQM.

Items 3-5 are the "react via management" model that I've talked about on 
the list, given the unfairness doesn't amount to starvation, and it is 
possible that the prevalence of the problem is very low.


Finally, after the bullet list of requirements in section 4.3, (which 
are prerequisites for setting the ECT1 codepoint), we propose to add the 
following requirement, as suggested on the tsvwg list:

       To participate in the L4S experiment, a scalable congestion 
control MUST
       be capable of being replaced by a Classic congestion control (by
       application and by administrative control). A Classic congestion 
control
       will not tag its packets with the ECT(1) codepoint.

Cheers


Bob


-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/