[Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs

[Holland, Jake]

On 2019-07-26, 10:13, "Black, David" <David.Black at dell.com> wrote:
>> The first option seems highly undesirable to me, as a) (TCP-friendly) single queue
>> RFC3168 AQM are standards compliant and will be for the foreseeable future, so
>> ms making them ineffective seems like a no-go to me (could someone clarify
>> what the IETF's official stance is on this matter, please?),
>
> The IETF expects that all relevant technical concerns such as this one will be raised by participants and will be carefully considered by the WG in determining what to do.
>    
> That was the technical answer, now for the official [officious? :-) ] answer ... the current L4S drafts do not modify RFC 3168 beyond the modifications already made by RFC 8311.  If anyone believes that to be incorrect, i.e., believes at least one of the L4S drafts has to further modify RFC 3168, please bring that up with a specific reference to the text in "RFC 3168 as modified by RFC 8311" that needs further modification.

I'll try pointing to some specific citations.  I think there may be
others along these lines, and would love to see a more complete
enumeration, but in the interest of a timely response, thought I'd
send one of the first I saw.

I'm not sure how I could recommend updating RFC 3168 to address this
point, but I do believe it's an incompatibility between the L4S
proposal and RFC 3168.


From https://tools.ietf.org/html/rfc8311#section-2.1
2.1.  Effective Congestion Control is Required

   Congestion control remains an important aspect of the Internet
   architecture [RFC2914].  Any Experimental RFC in the IETF document
   stream that takes advantage of this memo's updates to any RFC is
   required to discuss the congestion control implications of the
   experiment(s) in order to provide assurance that deployment of the
   experiment(s) does not pose a congestion-based threat to the
   operation of the Internet.


From https://tools.ietf.org/html/rfc2914#section-3.2
3.2.  Fairness
...
   It is convenient to divide flows into three classes: (1) TCP-
   compatible flows, (2) unresponsive flows, i.e., flows that do not
   slow down when congestion occurs, and (3) flows that are responsive
   but are not TCP-compatible.  The last two classes contain more
   aggressive flows that pose significant threats to Internet
   performance, as we discuss below.


I believe under this nomenclature, L4S in a queue with RFC3168-style
marking at a bottleneck should be classified as a flow that is
responsive but not TCP-compatible, and therefore poses a significant
threat to internet performance within this context.

I'm not sure how best to describe this discrepancy, but I think it's
fair to call it an incompatibility between a RFC3168-style marking
queue and L4S.

I didn't see this explicitly discussed in the L4S drafts as an
incompatibility that proposes to deploy a threat to flows in RFC3168
queues, but to me it seems required by RFC 8311 (and possibly in
conflict with the advice from section 4 of BCP 197, recommending the
use of ECN in deployed AQM devices).

On the contrary, I think we saw this described on the list as a non-
problem because most of the live RFC 3168 queues that we know about
are FQ (with the implication that this is sufficient to protect against
the non-TCP-compatible flows, except where there's a hash collision).

To me it seems unsafe to deploy this experiment without deprecating
the BCP 197 advice, and the root cause is its interaction with RFC
3168 marking.

Something like a requirement for a controlled environment would
address this problem, to me, and of course perhaps I'm on the rough
side of the consensus, but I think worth calling out the issue for
open discussion.

Best regards,
Jake