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

["Black, David" <David.Black@dell.com>]

Jake,

> 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.

Based on the L4S slides in today's meeting and related discussion, the L4S folks are starting to deal with this concern.

I share your technical view that this concern is not safe to ignore.

Thanks, --David

> -----Original Message-----
> From: Holland, Jake <jholland@akamai.com>
> Sent: Friday, July 26, 2019 12:16 PM
> To: Black, David; Sebastian Moeller; Bob Briscoe
> Cc: De Schepper, Koen (Nokia - BE/Antwerp); ecn-sane@lists.bufferbloat.net;
> tsvwg@ietf.org; Dave Taht
> Subject: Re: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
> 
> 
> [EXTERNAL EMAIL]
> 
> On 2019-07-26, 10:13, "Black, David" <David.Black@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
>