Re: [tsvwg] L4S expected sharing behavior between L4S'd two queues at longer RTT if the L4S transport protocol gains higher RTT independence

[Sebastian Moeller <[e-mail]>]

Dear All,

I have a question I want to pose about interactions between the dual queue coupled AQM's sharing behavior.

We currently see an RTT dependent bandwidth bias to the advantage of the LL queue from ~5:1 at short RTTs to ~3:1 at ~10 ms RTT to mostly equitable sharing at 80ms RTT.
Some of us including me are uneasy with introducing such a sharing system in the wild, but overlall, people on this list do not seem overly concerned about this behavior, supposedly because short RTTs are not that common for the expected roll-out? (I disagree with that view, given how many important traffic sources have been moving closer and closer to the endusers, like CDNs and the talk about moving even computational services closer to the edge ("mini datacenter in the base station" not sure whether that is more than a phantasy)).
But one of L4S's goals is also to reduce the bandwidth dependence on RTT for L4S flows, so that L4S flows compete more evenly for bandwidth with each other in the LL queue in spite of differing RTTs.

So here is my question, what is going to be the effect of such decreased RTT-dependence of L4S flows in regards to sharing behavior with flows in non-LL queue at higher RTTs?
Put differently, will decreased RTT-dependence of L4S flows make the sharing between the two queues more or less unequal at short and long RTTs?

My hypothesis is, that if a long RTT L4S flow can better compete with short RTT L4S flows, it will also do so against equal RTT non-L4S flows, so I expect that unless RTT-dependence is reduced for all flows independent of class, this otherwise positive change to L4S's recommended CC behavior will cause even more interference with the existing internet. I hope I am wrong, and would like to ask what the L4S' teams assessement of that issue is, and that there might even be data demonstrating that my concerns are unfounded.

Thanks
	Sebastian