Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
Sebastian Moeller <moeller0@gmx.de> Sat, 31 October 2020 14:55 UTC
Return-Path: <moeller0@gmx.de>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7145F3A0C8F; Sat, 31 Oct 2020 07:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.548
X-Spam-Level:
X-Spam-Status: No, score=-1.548 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 p3pgJkvI0BcV; Sat, 31 Oct 2020 07:55:04 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424C53A0C8E; Sat, 31 Oct 2020 07:55:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604156057; bh=m9LpsCNdzeKYZNriu3Z9ws5G9ip+6uIexvvkHdozotI=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=dpmR2+W/4lqOy6F2Jr+0fYifb9y+F30rhceglNs85eWwhxZquyju1VQnQQkT7jAl/ FiHazVZirZK+HQs/1kwUEq69ZZ66b46MzjP62THfLTNQa1z+5P6MXsIelvj598YKZA Ba7ET/x3rBCQYXg1E4Zmvx1sXpNjaH7xwV9fyVcI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [134.76.241.253] ([134.76.241.253]) by web-mail.gmx.net (3c-app-gmx-bs36.server.lan [172.19.170.88]) (via HTTP); Sat, 31 Oct 2020 15:54:17 +0100
MIME-Version: 1.0
Message-ID: <trinity-63e79f62-2574-4f86-8988-08a4e0cac056-1604156057179@3c-app-gmx-bs36>
From: Sebastian Moeller <moeller0@gmx.de>
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: tsvwg IETF list <tsvwg@ietf.org>, iccrg IRTF list <iccrg@irtf.org>, TCP Prague List <tcpPrague@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>
Content-Type: text/html; charset="UTF-8"
Date: Sat, 31 Oct 2020 15:54:17 +0100
Importance: normal
Sensitivity: Normal
In-Reply-To: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net>
References: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:BiejEYDwIkaRC8AbzJkA7vtY3m71C5RBW/UITmRdlU5x5vuw9mnkkRc0rMz5a635fw6v9 3uAcNJa/gaOCTaoQqV+VgXnQyaddMWObST5RuUkJWPBbzX3oYATRKWNBWqRVXBsiYqpDCU/cfC6Y id7YF0LksKnHmYF8AN6q+tgmOZ0Tun+UdPQ2wwLhotdUoW/SXk1h4uVYK4TD3qUANevrekhmsWcT 5CPLNAR5Tm+vKjzVGYorvq84tKl/zvpp9upuK6dDP1u+qKyXci6qYWr1d2fBkwRbSRtzm66A1B4A GE=
X-UI-Out-Filterresults: notjunk:1;V03:K0:oiQVmQRfIFg=:iTdJammkkGD5nl1b2PGu6+ WfGepWY3vrBVuH6l8seMBT4NraPUfMdduMt5HhzFOpnKgT72B6/yvAbB7Z3Dk8MKoZ0H6DJs8 O31r+RpjFoTtsBMJOEZ+3lAJQyNhxAV22/C390keZEIGh0Z3SKohNr/xBh4XMD2bh7l0/CDu0 a4v4lsvdDJn2x79OerZi68yc0vyTpOTaL/hd0f79fiZDYYBJakLsH6mG7rF0oqVeiVF1QCeWS 3IxjiSLEo++02wug8HYGmyT6/cLfnlhMOcv6EPJwspI1Jk04lXHcOL4rzz5k6c02EuWj8zLwI CRACSljjhNB/gHgPaBeVWO4oNPLOpFSUFFbbqc4QAZtwBj4fqCWOL1mmnBxLHFWaYSwIyOkXV 8zDZfZS6LjyiIfLEvax0kzHQa7pRLqhGBzJTl6EVOd/+Si1al+e4xiMnFZgA6S0ZlHvCX1DMS o1qCNsoPbT6CQyC8okc5uXJeiGsiojHeRHHswa5JGXvmpaZIYJN7KVK2m80tXjW7TeCBxdim6 wv8997In5pdmAdoPibbetkNFtChdjw8MrqeS7H+ChXl7ZsLpAGN69gCPzeJTu6C4OQCRbE66y rsDZJPY2cxx/M=
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/LS_w5kSfcm7QStEp6T-c-rFYgVE>
Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2020 14:55:07 -0000
Von: "Bob Briscoe" <ietf@bobbriscoe.net>
An: "tsvwg IETF list" <tsvwg@ietf.org>
Cc: "iccrg IRTF list" <iccrg@irtf.org>, "TCP Prague List" <tcpPrague@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>
Betreff: [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text
The co-authors of ECN L4S ID have been reviewing the correctness of the normative 'Prague' requirements.
See https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3" target="_blank" rel="nofollow">https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3
This is the second of 2 emails, about 2 of the requirements that we think ought to be reworded a little.
If you agree with the rationale, but think the new wording still doesn't fully capture the requirement, pls suggest sthg better.
If you disagree with the rationale, pls discuss.
4.3. Prerequisite Congestion Response ... CURRENT: o A scalable congestion control MUST react to ECN marking from a non-L4S but ECN-capable bottleneck in a way that will coexist with a TCP Reno congestion control [https://tools.ietf.org/html/rfc5681" target="_blank" title='"TCP Congestion Control"' rel="nofollow">RFC5681] (see https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#appendix-A.1.4" target="_blank" rel="nofollow">Appendix A.1.4 for rationale). Note that a scalable congestion control is not expected to change to setting ECT(0) while it falls back to coexist with Reno.
o A scalable congestion control MUST implement monitoring in order
to detect a likely non-L4S but ECN-capable AQM at the bottleneck.
On detection of a likely ECN-capable bottleneck it SHOULD be
capable (dependent on configuration) of automatically adapting its
congestion response to coexist with TCP Reno congestion controls
[RFC5681] (see Appendix A.1.4 for rationale and a referenced
algorithm).
Note that a scalable congestion control is not expected to change
to setting ECT(0) while it falls back to coexist with Reno.
RATIONALE:
1/ The requirement as currently written says what an omniscient sender MUST do. So there's an implied requirement that a sender MUST be omniscient, which is of course impossible.
3/ This includes the possibility that the operator of the host knows that the network it serves has not deployed any single queue classic ECN AQM (e.g. in a CDN case they're doing out of band testing, or they've asked the ISP). So we've included the possibility of fall-back being disabled by configuration.
4/ Nonetheless, as has been pointed out on the list, there is still a possibility that there is a Classic ECN AQM somewhere else on the path (to continue the CDN example, perhaps beyond the ISP in a home network). The 'MUST monitor' requirement still stands to ensure the operator doesn't miss these cases.
5/ Then, if the server operators have disabled fall-back for their deployment, they can reconsider their policy or at least do more focused testing if they are frequently detecting a single-queue Classic ECN AQM.
Items 3-5 are the "react via management" model that I've talked about on the list, given the unfairness doesn't amount to starvation, and it is possible that the prevalence of the problem is very low.
Finally, after the bullet list of requirements in section 4.3, (which are prerequisites for setting the ECT1 codepoint), we propose to add the following requirement, as suggested on the tsvwg list:
To participate in the L4S experiment, a scalable congestion control MUST
be capable of being replaced by a Classic congestion control (by
application and by administrative control). A Classic congestion control
will not tag its packets with the ECT(1) codepoint.
Cheers
Bob
-- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/" target="_blank" rel="nofollow">http://bobbriscoe.net/
- [tcpPrague] ecn-l4s-id: Proposed Changed to Norma… Bob Briscoe
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Christian Huitema
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tcpPrague] ecn-l4s-id: Proposed Changed to N… Christian Huitema
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Sebastian Moeller
- [tcpPrague] L4S and BBR (was: [iccrg] ecn-l4s-id:… Bob Briscoe
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Jonathan Morton
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Christian Huitema
- Re: [tcpPrague] L4S and BBR (was: [iccrg] ecn-l4s… Christian Huitema
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Gorry Fairhurst
- [tcpPrague] Realistic Queue delay targets Rodney W. Grimes
- Re: [tcpPrague] [tsvwg] L4S and BBR (was: [iccrg]… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tcpPrague] L4S and QUIC Bob Briscoe
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Christian Huitema
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Jonathan Morton
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Greg White
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… Christian Huitema
- Re: [tcpPrague] [iccrg] Realistic Queue delay tar… Ingemar Johansson S
- Re: [tcpPrague] [tsvwg] [iccrg] Realistic Queue d… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] [iccrg] Realistic Queue d… Ingemar Johansson S
- Re: [tcpPrague] [tsvwg] [iccrg] Realistic Queue d… Sebastian Moeller
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Chan… De Schepper, Koen (Nokia - BE/Antwerp)