Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

[Sebastian Moeller <[e-mail]>]

Hi Oliver,


> On Nov 11, 2019, at 01:47, Tilmans, Olivier (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
>>> This is similar to DCTCP forcing the use/negociation of ECN, regardless of
>> the actual
>>> sysctl value, as it cannot provide its service without it (in other words,
>> becomes
>>> plains reno).
>> 
>> 	[SM] Sorry, that does not compute to me, if at all it points at a bug
>> in dctcp that would merit fixing. In essence dctcp aims a specific niche
>> where this can be toerated, but since yi aim for replacing all current CCs,
>> you need to play by the rules. TCP Prague with ECN disabled should behave
>> like Reno, it should IMHO accept that a systems admin sets policy and needs
>> to respect the tools used for that purpose.
> 
> Forcing to initiate the negotiation of (Acc)ECN (i.e., sending a SYN with
> ECE/CWR(/NS) set) does not imply that said negotiation succeeds (e.g., if
> the remote endpoint does not implement/allow it).
> If the handshake fails, then the CC has an explicit trigger that it should
> fallback to something else (at the moment, both become plain new reno).

	I am not a gate keeper for any of this (I guess you are lucky), but if you are telling me that to disable ECN use in TCP prague I need to intercept and mangle SYN packets, because you decided to ignore one toggle commonly used to disable/enable ECN on a host you will not make me happy. I assume that this assessment will be shared by a noticeable fractions of system administrators. But I guess the challenge is going to be to get this into the mainline kernel.

Best Regards
	Sebastian

> 
> 
> Best,
> Olivier