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

Sebastian Moeller <moeller0@gmx.de> Mon, 11 November 2019 00:58 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0DF12001A for <tsvwg@ietfa.amsl.com>; Sun, 10 Nov 2019 16:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBC_3hqbBY6r for <tsvwg@ietfa.amsl.com>; Sun, 10 Nov 2019 16:58:06 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AD81200E5 for <tsvwg@ietf.org>; Sun, 10 Nov 2019 16:58:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573433882; bh=5ZG+oPLKlxGbf+FYVbmaqWEsjSw3tQlX1FlZMPeoJkM=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=D1Fpzh3YKMpqHWkwWzPyn446N5S54LRPt+HmyE3/0UQ8ykKg+uY66AyYaCthFHba8 3QKNmb1B+93ULLBvPjTcSb2neJxg2XSBjgciQoqlttkzZMvhjJSWgTIeWabYEII4t6 thcaiA7e+Y2+s+Obvr43cz7vMQEp+fAy/tjBmlSQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.6.95.82]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCsPy-1icjTG228u-008utb; Mon, 11 Nov 2019 01:58:02 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <VI1PR07MB59814B85B14219896F655D10E0740@VI1PR07MB5981.eurprd07.prod.outlook.com>
Date: Mon, 11 Nov 2019 01:58:01 +0100
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B059C370-F449-4D67-811D-2BE60770EACE@gmx.de>
References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <B58A5572-510E-42C7-8181-42A0BE298393@gmail.com> <D2E12331-F504-4D5F-B8E7-A1A5E98DDF7E@cablelabs.com> <2275E6A5-C8F8-477F-A24A-3E6168917DDF@gmail.com> <55F724CD-6E74-40D9-8416-D1918C2008DD@cablelabs.com> <BBE7C7A9-0222-4D84-BF27-8D5CAE2F995E@gmail.com> <6f189711-ffa0-90f4-fd16-3464ba4df3ce@mti-systems.com> <4A706B11-3239-4DAC-BE85-0B4BFF2D8FF8@heistp.net> <8B28ECE4-FF4B-4BB2-ACBE-80B30708F97E@cablelabs.com> <AAEA9AC2-B8A1-4837-A7C9-8EEA21A7C523@gmx.de> <D5D560CB-BC47-45BE-811E-E73E2D4909E3@cablelabs.com> <3332A911-3AA0-4986-9AA9-B97266A3337F@heistp.net> <VI1PR07MB598169BE81401DF2B4FD2CF2E07B0@VI1PR07MB5981.eurprd07.prod.outlook.com> <A95F62C3-7162-4E9A-98AD-F3C81019A512@gmx.de> <VI1PR07MB598181251C44DEE20A133CE5E0740@VI1PR07MB5981.eurprd07.prod.outlook.com> <A7A248AD-CC4F-4244-8FC7-532DB45AF2BD@gmx.de> <VI1PR07MB59814B85B14219896F655D10E0740@VI1PR07MB5981.eurprd07.prod.outlook.com>
To: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:jlaeVEaJ/0r0QLRp+MmiO4MCbRBGE8BGtgy8/QziAEdL+zf36Pw G+jjKCX4HxKvz0QPsEf/sFoNbn4mKJ4szWP0X9xSOnSZF6FYYyu3QGCReUbhtCNmGxq79fm CiPCmFXQFxjJ6j+UQYZXSMFmg/pQYATmbg5OWRYcldcd3ehtMTPKwK66qhVFr1JgFf93+tQ ZHwSGVWUcg7Mbm2PWcKkg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:h2CsdfD/RvM=:Kf7bFVmWaH5llvuSgdRoag Dvij4Af7JDtnl+eIK51t9hd4Iv/ERnc6kgIsV9cXGi5vgtKfx+1SmvcqDzxdyNiv+VQsQWBvJ 5jsiTtldr71hZd1GPv0I3osb2hfcSGxS/RkwTABksDcv/0peixWlvvkSVZ+pwcLeyeV/a0ZDx tDBPfT6lMGEAM8VWT636g8qqZvC2R4cSOeCkTE7OlFWwpfV46q8g5pxNalOR3l0kdsCwURNk3 vMb7ioLjQa1G34I4APDq2nAiTyOUnVq2cYqOJ0UsBm7608mz23oi1zJ0V2bYUEqz9MH1fs8mk FlW7B8Ic/TTPJ3lMEU0QYxUPqpCOFj6ccq81HBzlSUEfKO46oM24AdP6zLk60+Cm+doFpyNcV V4GHfByPcMPtIp1P7QJEh2lM+7nr/cYhABa5j26dhsvSdaMoXzBhBLsofnT5CrEaUK3yyib+B M1kUFB8XQYi+2Yxg7Om+bT4e55kTuWsB/Z2fwQhWb3OgK3yDahGMRNimGd1ATN3PWoK7L9ndj BfXPRdeVZU2Syi+i3pxGTtzV2xSM8lAwHUhH+czbSEYbuBN/xMweOJB6kWjzsNk9CGf3UprSK CsAmdOx42x0ivKnQ40oj9WZLu2BrPKlwMT26ZGm49qj7S/RL5/QEeZljOqRx6IysKWgGLk2on 0ulOB8Wam93bcYmhrFnozJ6u8w9Skf/B63ZK6D5XCx8aYPFbalakT46UuVf1hNOxCtHECJecW H9cMxtPtKQLm5Mq1kLK+QYq6z2susaCasdJlkEXxTUh3/mV+q1QlKdpeAslzpTMws9+dQxJF0 iCg21Api3jd27hcWjVFGVXA7BEYywewOND2RLkHCNJse6FwjYjkjZvh4c/RUt0DMbvJcSknVz QaUyXDf4ueJEe+/9bpfnJ2135Zl4cN66KBo9kXtRZOpNdiCb3phcNFHmCiorHR30UuoE9eCiq mz1yyFPQOD77b5wOnwXDTy5BXey4lcfLUfIJjPoE861rpRQ1yfTLx5dwy3JjoxqRsW1CAyTbO d8xzikLuC8Z3FmV6YwWSLulcNTcqfjVdJe5Kmu2YKcPZJ2nWXYAIfXysGpvi1JOCdQPAHmcrt P8xw8+zzJ8jwD+UBxvvh1SljZ6YzS3QaqABnE1k1ci46MObLiGXV70T6CbkGDZZHbmiIu7oXv MLqZi1PCDSro3+gzl2JYFJa3qLf3mlSRunefbY1SDUZlc1phFWKN+nYDsN4ZLVMLXfetwanUt ZwQ9vlEYde+eiejZOmsDRUlV8BugNV1NY0r9Q+fkVscuG9gHsFP8XUXREFP8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/VTZEuy0iOpRdeWKWw6D9GEftmb0>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 00:58:09 -0000

Hi Oliver,


> On Nov 11, 2019, at 01:47, Tilmans, Olivier (Nokia - BE/Antwerp) <olivier.tilmans@nokia-bell-labs.com> 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