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

[Sebastian Moeller]

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