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

[Black, David]

Inline comment on "IETF's official stance":

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

Thanks, --David

> -----Original Message-----
> From: Sebastian Moeller <moeller0 at gmx.de>
> Sent: Friday, July 26, 2019 6:20 AM
> To: Bob Briscoe
> Cc: Black, David; ecn-sane at lists.bufferbloat.net; tsvwg at ietf.org; Dave Taht; De
> Schepper, Koen (Nokia - BE/Antwerp)
> Subject: [Ecn-sane] [tsvwg] Compatibility with singlw queue RFC3168 AQMs
> 
> 
> [EXTERNAL EMAIL]
> 
> Dear Bob,
> 
> we have been going through the consequences and side effects of re-defining
> the meaning of a CE-mark for L4S-flows and using ECT(1) as a flllow-classifying
> heuristic.
> One of the side-effects is that  a single queue ecn-enabled AQM will CE-marl L4S
> packets, expecting a strong reduction in sending rate, while the L4S endpoints
> will only respond to that signal with a mild rate-reduction. One of the
> consequences of this behaviour is that L4S flows will crowd out RFC3168 and
> non-ECN flows, because these flows half their rates on drop or CE-mark
> (approximately) making congestion go away with the end result that the L4S
> flows gain an undesired advantage, at least that is my interpretation of the
> discussion so far.
> Now there are two options to deal with this issue, one is to declare it
> insignificant and just ignore it, or to make L4S endpoints detect that condition
> and revert back to RFC3168 behaviour.
> 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?), b) I would expect most
> of such AQMs to be instantiated close to/at the consu,er's edge of the internet,
> making it really hard to ameasure their prevalence.
> In short, I believe the only sane way forward is to teach L4S endpoints to to the
> right thing under such conditions, I believe this would not be too onerous an ask,
> given that the configuration is easy to set up for testing and development and a
> number of ideas have already been theoretically discussed here. As far as I can
> see these ideas mostly riff on the idea that such anAQM will, under congesation
> conditions, increase each ftraversing flow's RTT and that should be quickly and
> robustly detectable. I would love to learn more about these ideas and the state
> of development and testing.
> 
> Best Regards & many thanks in advance
> 	Sebastian Moeller