Re: [tsvwg] ECT(1): Plan for Vancouver

[Sebastian Moeller <[e-mail]>]

Hi Greg,

I find your description to be slightly off as well...

more below in-line


> On Mar 8, 2020, at 08:35, Greg White <[e-mail]> wrote:
> 
> On 3/5/20, 3:47 AM, "tsvwg on behalf of Jonathan Morton" <[e-mail] on behalf of [e-mail]> wrote:
> 
> [snip]
> 
>    In that sense, even if a precise threshold for unfairness cannot be agreed upon, there is clearly a qualitative difference between a system which imposes a 15-fold reduction of available throughput on existing traffic, versus one which accepts a 2-fold reduction of throughput to itself, when deployed in a shared environment without FQ.  I think when shown that way, consensus that one is acceptable but the other is not would be straightforward to achieve.
> 
>     - Jonathan Morton
> 
> 
> [GW] I hope that there isn't anyone reading this mailing list who believes that the above is an accurate characterization of the debate between L4S and SCE.   To provide some balance to the above, here is (in my opinion) a more accurate characterization.  
> 
> The SCE proposal penalizes any sender that adopts it (2-fold reduction in throughput with no improvement in latency) in many cases, and gives a benefit that is nearly on par with the L4S benefit (this is still to be shown, but it is theoretically possible) when FQ is used in the bottleneck.  Based on this, why would a sender ever adopt SCE?  Why would the IETF ever want to consider using this last codepoint for that purpose?

	[SM] Because from the IETF's perspective, the important issue should to be how to reliably, robustly and safely enable 1/p congestion control over the wider internet. IMHO that is where tsvw comes in, the claimed (and hyped up*) latency improvements that L4S promises seem more a commercially relevant questions.
	IMHO SCE offers a relative clean, backward-compatible and hence safe way to deploy 1/p-type congestion control that leaves basically all doors open for future improvements, for example in latency-under-load increase. Put differently SCE sets out to tackle one specific important thorny problem and solves it in a clean and minimally invasive way with minimal side-effects, and hence should be considered by the IETF.



*) Hyped-up, because the state of the art today are ~5-10ms latency-under-load increase not 100s of millisecond, sure 1 < 5, but I fail to see any use-case that both will qualitatively suffer significantly by going from 1ms to 5ms additional queueing delay, that is a reasonable to use the wider bet-effort internet as transport medium. THat is not to say that going from 5 to 1 would ne be a good thing, but lest keep benefits and associated costs in a realistic perspective here.



> 
> In comparison, L4S provides a benefit to the adopter (better throughput and lower latency) and no significant penalty to others in the majority of cases (including FQ) and only results in the significant penalty to older systems in some (highly?) unlikely cases if RFC3168 fallback is not implemented.

	[SM] Today, in all realistic current conditions, no ECN-based AQM, both will behave exactly identical, so in other words there is exactly ZERO benefit for the adopter of any of the two ECT(1) definitions. Both proposals, as I was able to get Koen to commit to, aim for per-flow fairness* even though Bob explicitly disagrees**, and both can signal 1/p-type CC response. So far so similar. The biggest difference I can see, is that L4S with its flawed dualQ AQM has a somewhat working implementation of a method how to translate 1/p type responses into lower queueing latency, while SCE currently does not. But dualQ could easily modified to a) use DSCPs for queue separation and b) to use SCE-type signaling for the LL-queue. 
Low-latency queueing and 1/p-type congestion signaling really are two orthogonal issues, that best are tackled independently. L4S demonstrates that coupling them is not the best idea by such questionable engineering like the TCP Pragues hack to work around the dual queue coupled AQM's poor  sharing behaviour at low RTTs. Mind you, that hack is not to account for some undesirable property of code/gear already widely deployed and used in the field, but rather to two components that still have not left really the lab. (Not only that, but the 15ms hack has not landed in the official TCP Prague repository at https://github.com/L4STeam/linux, and according to Koen is not intended to make it into TCP Prague at least in the current form).


Best Regards
	Sebastian




*) Even though it starts to look, that the only robust guarantee that L4S is willing to give is one of "non-starvation" while at the same time aiming to make it appear as if it was delivering equitable sharing between flows of 1/p and 1/sqrt(p). 
	And yes, under sufficiently narrow conditions L4S can deliver roughly equitable sharing, but alas, it fails to do so for the shorter and shorter content-to-end-users paths that get more and more common; the shorter the path the more it gives L4S flows an undeserved and unexpected advantage. 
	This would all be less irritating if equitable sharing between flows would be a pie-in-the-sky objective that nobody ever had achieved. But given the real world existence and deployment of bi-directional FQ-AQMs that pretty much solve the biggest part of the L4S agenda (getting latency under-load-increase down from >= 100ms into the single digit millisecond range) it seems like a waste of engineering resources by the L4S team to having worked hard to re-invent the wheel (pseudo FQ without the guarantees that make FQ a decent "good enough" solution in the first place) instead of adding their good ideas, like getting 1/p congestion control in the field and potentially using paced chirping to help improving the "slow start phase". Sure everybody can decide where to spend her/his time 


**) At the end of https://mailarchive.ietf.org/arch/msg/tsvwg/1kVZWJRm0TBqDYC4wLN00zS3viQ/ Bob wrote
"The main reason the early L4S proponents sunk years into developing the dualQ coupled AQM was to provide a way to do low latency without FQ."

@L4S team, please get your messaging straight, what is it "aiming for equitable sharing between all flows" aka FQ or "low latency without FQ", both seem mutually exclusive.

	By now, I am prone to believe Bob's narrative over Koen's, as it is way more consistent with a number of otherwise hard to explain design decisions that disadvantage non-LL traffic for the benefit of LL-traffic, like the 15ms latency reference target for the non-LL-queue's PIE instance. 




> 
> -Greg
>