Re: [tsvwg] MUST detect problems with legacy queue [was: Re: start of WGLC on L4S drafts]
Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> Tue, 09 November 2021 15:53 UTC
Return-Path: <mirja.kuehlewind@ericsson.com>
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 D8CFF3A08AE for <tsvwg@ietfa.amsl.com>; Tue, 9 Nov 2021 07:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 bYoXeASUx3vk for <tsvwg@ietfa.amsl.com>; Tue, 9 Nov 2021 07:53:16 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::623]) (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 583BE3A089B for <tsvwg@ietf.org>; Tue, 9 Nov 2021 07:53:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MjxJGYd5J4gMq4iRSxV7QG2gipQGHlLRTk6vlLs6TMQfZXjxOriGs28d3faZ2GTOmSna1Hi/aOnwZIAtOIlc+6TN3dG00I6PjeatGmqE9e0h/yFs0BlIwkQCfNO20ZVUY4beRlZqZ6Z026PaMeyqnX2OhAxzketVlVX0+fYc8i6zzkq8a73dBxq+BReP47NmUjIMs4goR2qIbtt4EmxGpsHPd3TGNW73xl/SEpu3VH0cxdC9lIBVyRBAs0H6YqPn+2xUFGak3Bth+mh5EEuWZwTWegQeLbPvNKGakH5YSBz2/Lz04F6sNZy0YVP7c3C8h2Joz9GfK8uzeR9/3olWTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EFuyei71nxvSdLnXwxSsUte92vcUiZmjJKM9kPd3rUc=; b=YIqLciQm2Pafd40seuHRBAhcWry14TjvL80WGxvQ95g4veHy7/WWIi9mdM8zv//a3cKfLdH9hpxVXP0mgV5Q5e5vWaaYF7aH5KUzywr07YtqzJup0vOXJ75jM94zx7n/XOiy77FLb5WU+kzssJQe5lw3bpnbgjc9sotldi/MdFM/y9n+LGxQYmQZrR7WS+nnYIiRY5wxlUJJfoUtwszWg3m4GUuIR+9Zgq3q7Eds1VTmcSdL6bXTd7+zdcxTyBPlMTlnLT190uyn3RffA5QIvx4djfwKaU1wpvKymLimeqorUiX1zHhkEYzB7vOl5gAooRupJUE253F+Uv+x1ZwwoA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EFuyei71nxvSdLnXwxSsUte92vcUiZmjJKM9kPd3rUc=; b=ukfmMX1VRQSDZUek1Iq8cVuMtFG1j0zNlrr1E8kUrCiMzaU9IVw53JFtUgsr7FOOXKq0b0fj+z5MQMvnehpBnLWw9g7UaLFP0GvWs2j385AEayzNYDgBJp6/Od7/OQ0GKzOBy85ktHS1gksQ83NVJgfnLVrKL2mVjSJ2QIXwKTo=
Received: from PAXPR07MB7806.eurprd07.prod.outlook.com (2603:10a6:102:13a::19) by PA4PR07MB7440.eurprd07.prod.outlook.com (2603:10a6:102:cd::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.12; Tue, 9 Nov 2021 15:53:08 +0000
Received: from PAXPR07MB7806.eurprd07.prod.outlook.com ([fe80::6df2:1bf8:5d67:26fc]) by PAXPR07MB7806.eurprd07.prod.outlook.com ([fe80::6df2:1bf8:5d67:26fc%4]) with mapi id 15.20.4690.015; Tue, 9 Nov 2021 15:53:08 +0000
From: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, "Holland, Jake" <jholland=40akamai.com@dmarc.ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: MUST detect problems with legacy queue [was: Re: [tsvwg] start of WGLC on L4S drafts]
Thread-Index: AQHX1WiwldKYNzgaKUyjlGggCX13eav7Sz4AgAAGA4CAABh3gA==
Date: Tue, 09 Nov 2021 15:53:08 +0000
Message-ID: <D2B6A004-E89F-4F4E-B806-42ADD3CF71F9@ericsson.com>
References: <42956573-2D32-4E09-91BF-B3B907B94AA7@ericsson.com> <08cc0a8c-824c-db10-3374-beecfaf6db60@bobbriscoe.net> <dff5acaf-4c0f-a628-e7e0-a9e8b8943ed2@bobbriscoe.net>
In-Reply-To: <dff5acaf-4c0f-a628-e7e0-a9e8b8943ed2@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.48.21041102
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 619b7d06-7a8d-452f-f011-08d9a39906b2
x-ms-traffictypediagnostic: PA4PR07MB7440:
x-microsoft-antispam-prvs: <PA4PR07MB744080FAFE54CA0122A296D7F4929@PA4PR07MB7440.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4+Yp2nNt2ph6XqWWQsXlQY6UorXy+VkJPzODYSpriiAesYC1OmD5N/gN2zfhJl6ujTj083b9CTPgGpxFoCtdNjEaml/u480OaJqqvhceZQfzsmVGP4R/qIu38o+FDtmluAksonZ1Q2i2xyCHa62awpjyMra6vc6cQuSNyU9mVzfEik+liulTw0fdemvEdbPzX0UN++z4Sklzt0bARd65T2zTK0785tzm1QtGN3ZrhLMYM+MkpLjRDZEKaCE2kvhAfjTKEJWszWQ9WcZxHojWJ5+CO9+4iVSxMcV55r4YiR4Vq8ZwktCQ9z3b13VlrSsSQlujqmnwqXcfQoGjYf7h6iqts0IkR7ZEy8Q2QyQSzGMkXfhuDwyHS1wB+wQdA7X610IFg7yrIgmFipQHYZE7YOdM+Yj0Jxl+Bd2z4s7/rUezZdjy+hxxy6m7MCcgU7Mj3hDctbw/CuLs9LONawCeUaLXQ9MVGUpVxIXIZ6QKWJiDbMTfuyJ/Q8CPvmP2OXuj5eCm913QcUJ8d8BChi7LgnqTxsIjF9SfGqSPXQObHJ4jSA+JOgYOiVLyLB9m+7Sg/sWrUj8r6C6cvH9tMRDA8wjBHW2VbekpNC2VFfICK9NLArsndZdsuvh20pbwTEs5ixKahDRAlnnwwWFsKT1zgCrePNJa1B5iD0bBZPqZt9YkyUYTR2S8u9cUn7ctBqX2bbRyOVXZ+YhhL7WVmPJsQEiaVlgtmqgrjw4L7rJao1J1qTQv16y3VMo6lRTvxhGjf/FqEBf6s1xFA828WnNpB+uByHjJOhgERQR5rx+DrGKYJOrXVbLnraVqhnf1HeTXMEnjma9fta97inMBl61wVSYehOD5DyS4/Se9/POKXgQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PAXPR07MB7806.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(4326008)(66946007)(83380400001)(2616005)(508600001)(122000001)(66446008)(64756008)(66556008)(66476007)(33656002)(186003)(36756003)(110136005)(66574015)(91956017)(76116006)(316002)(966005)(6486002)(8936002)(86362001)(82960400001)(38100700002)(53546011)(2906002)(71200400001)(6506007)(8676002)(30864003)(44832011)(6512007)(38070700005)(45980500001)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: gol6VCuM2b+EdUvWKv8w8h2mHhEttJVzt4yl46WD8aYx1wh6aKhD7T4FrlgrHWL8ZijYC+gHSbWXpvMlm63G1qd22Qby1FQLpycPC7FNXFL73cN/zV51Df9eLS3SKMeV7Ux0PsSlx+UH2PIDTLNpi0jMd37zi/BUHEIHPhIsRMka2ZpfLuHUuZDxNhNvGImgUAHp0mLH82mYozvj3T4jLBHzkUdZD9QsHsRCHJhO5JBrS1q8U6vhYP7xzAWx7NikOySkWQ5dOWXFbOdwhuy2qI6pRrIXEtITYCNg5EImNcWzVyVvT/2DAURWH3EGgDJQn3UxeAhcW8OUtYSIJUn5ab/o3Go/qQgLez6sOK6AlE3Znvgmi29x0+JPLEB7DZMH5FZAfy47UJIH1Vm8725NwH2EpUf4e0O9jtX8I/LQhV/1rUR/3ySYc0zQNXR0D74+7rjx15hwiGtWjI4AIW3wwxihghrNAKGcWWVTQT0G5c81qwqkCjw5dnThWlwN8SvuDjnOC4ObtloJ8PHfaYK2hG3OaKx7fICRrEnzWI16Ft5V0vGre1NFAXTTZuMXcushwk6bkZ2DwlC1mCopLcDkcaWYj9pWDGcfFk63TXdh+AmTpf3/Phz5HzpBS6zsgQ2nIDSsCXFO+miyoKdSvihIfr4v5gbryFFsOhQFD8uq3j67gjo5UZBtfxWCP3FU2f+6gAF2BnCkk9Mpnh2pKG76GsBVGqb5oSosjQDVQNGOcqeuIBO7AB7NccV/IdA3VzHL+yitkloR+q/MgU0cea8uTq5riztZMVnCCWxaDmZe/xE3eBeDcLsDa/TvvRn0K2MwRN+2Shx/mXFgjaPCHZ6Z29a8RGCVtrP6hx3pk1jccJ2FgDUCdKbBy3TZBzj96ps7+mpabUnTM/Wqg0C34bcqXZdaCWCYPEPL2AYD1U8g1DOtIqSo6PAcw/SiEh+AMFSLdGCWaFMjxkbPhPaIkBUQLXUrQg3znxU4ycRKBa1WMDRqU7Bbk7qgdi1gStHNwzF9x/fiixS0SxdhknBfYZU4ANmqqH39bpuPCsYHXvD9hRmP7QSrMlUFTeNRk+ESHaLtoz90akSPQ4n9W4xAIaInbWjW0UBwcy4SVjDuG3K/xqBqHsSXcclc3xn0/zwCR8DDyot2G05qWQm/XGka5R+b+AJ+expWJH3s5lTDpH0a2To79Q12W/JEhHwxdL462cwKpnqPkbN3nM1bw/qLXgqLykCbv19a6YM42Xk9FidU2p+d7/lf1tx+8dtp8NK79Q1h3fmxicrjcfh6sct6AJASQqUifTDtdl0DFSfOjAwEzDlkdcFWpoj8y46ccmCNebEzRaRN7Krai2rXK5kvIwuY1cU+N0NAZh8D1ZzrONaDB4Ab8q1mpvNxeit9jn2LLUsvNjQDdlJhmYmTnr+l1ERnJ7B6/PLf0ccU7310bquLBe7OL3akflo8nLzGW68NUc/n0Hvjd2JHVBXmFmg2yt9g36TTC4Z0cAhXSLIW2wK2sf9mrssJU+C0lEhrfHVE9KSPUvqr+A7BQWAUdnKV9a4rEl/dajeGfPM0Kajyn45e4L/yfQzHKcutMnlaXm9+hdcLVVS76GdyJWTAvBnB4L+SlBQM7zjDAkMan5djhejP/nUzJfp9aZegPH+p4oGnTPdxl3iT47xJdEliI7o+XoAzwS1TVIIKFggK7Y0iiFdZ7yk7hlAyh/xW98OM0Cp0tUdBInWanwXs4/w+h2izXh0uaM3w+7K1Vd6RcADruVd77XA=
Content-Type: text/plain; charset="utf-8"
Content-ID: <8D6FDE2DD3321249BCAD5321D2BE573C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PAXPR07MB7806.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 619b7d06-7a8d-452f-f011-08d9a39906b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2021 15:53:08.6553 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tNCf40WbHhi+zbtKN78xV4LPrSanAP64yY78YESicyflOppdtkLgzKiPBzTCllNLtTm7N0PRwVu+kuNlDgs63etDgOVGyUUTHpeuoKWE8P8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR07MB7440
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/f7ULnf2KvjtqRUVg7KCSVLbZNtk>
Subject: Re: [tsvwg] MUST detect problems with legacy queue [was: Re: start of WGLC on L4S drafts]
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: Tue, 09 Nov 2021 15:53:22 -0000
Hi Bob, From Jake's initial review, I believe this is what we are talking about: >> o In uncontrolled environments, monitoring MUST be >> implemented to >> support detection of problems with an ECN-capable AQM at >> the path >> bottleneck that appears not to support L4S and might be in a >> shared queue. Such monitoring SHOULD be applied to live >> traffic >> that is using Scalable congestion control. Alternatively, >> monitoring need not be applied to live traffic, if >> monitoring has >> been arranged to cover the paths that live traffic takes >> through >> uncontrolled environments. >> >> The current text requires monitoring, but only gives a single >> SHOULD for >> live traffic, plus non-normatively permits one alternative. >> This allows >> operators to monitor but not cut off (so this requirement as >> currently >> written would be satisfied by write-only logging for instance, >> with the >> SHOULD easily dismissable with an "implementation complexity" >> hand-wave >> while still following the spec). I'm saying I don't see any need for a chance. If you read the whole part in the draft, there are a couple of MUST here, which is fine but probably doesn't necessarily help in practice. It just says what you must do when you detect a problem. So, as you say below this is conditioned on problems being detected and you can't have a MUST requirement on detecting all problems anyway... Mirja On 09.11.21, 16:25, "Bob Briscoe" <ietf@bobbriscoe.net> wrote: [Adding to my previous post] On 09/11/2021 15:04, Bob Briscoe wrote: > Mirja, > > On 09/11/2021 12:52, Mirja Kuehlewind wrote: >> Hi Jake, hi Bob, >> >> On this specific point I would like to disagree. I don't think it is >> possible at all to have a MUST requirement here. Congestion control >> is a sender-side only implementation and any single endpoint can >> decide to just use non-friendly congestion control anytime with any >> marking and any AQM; maybe even for good reason in some cases. If you >> e.g. look at section 3.1 in RFC8085 you won't find a MUST there for >> good reasons. Requiring a MUST here without clear instructions what >> exactly do to and when is similarly not useful. > > [BB] To be clear, I think you're saying you disagree with the MUST in > the draft, and the MUST Jake is proposing in its place. > If so, this isn't a particularly constructive intervention. Is there > something you'd prefer instead? > > Speaking for the text in the draft, the final MUST only applies in the > case where scalable CC is already implemented. It is not saying CC > MUST be implemented unless it already has been. Then the MUST comes > into play, but conditioned on problems being detected. [BB2] Also note that the whole list of bullets are conditions for setting ECT(1), so this is not for 'any marking'. > > Finally, it refers to Appx A.1.5 and l4sops which give a lot of > examples of alternative things that can be done. In particular, Appx > A.1.5 gives an offline test that should be able to detect 'problems' > very simply (see table 2 in that appendix). > > > Bob > >> >> Mirja >> >> >> On 08.11.21, 15:54, "tsvwg on behalf of Holland, Jake" >> <tsvwg-bounces@ietf.org on behalf of >> jholland=40akamai.com@dmarc.ietf.org> wrote: >> >> Hi Bob, >> >> Thanks for your response. For the most part I'm satisfied, but with >> regard to the responses to points #2 and #3, I'll top-post my >> remaining >> problem and ask that you suggest something appropriate to >> address it. >> >> The current text, as far as I can tell, does not *require* any >> attempt >> to detect problems due to "legacy queue" issues (only "SHOULD" >> language >> here, I think?), and then makes the safety response of failing >> over to >> classic CC conditional on "detecting problems". Certainly if >> there is >> a "MUST" or "SHALL" requirement, it's hard for me to nail down >> exactly >> where. >> >> As has been discussed, without some quite complex detection >> efforts, >> detection of problems is a major challenge with this technology, >> and >> thus the current text overall seems too weak to me on this point. >> >> IMO, the docs need to make it clear that sending with this >> technology >> comes with a mandatory duty to look for and respond to likely >> problems >> caused to other senders due to the non-backward-compatible >> signaling >> response. >> >> Best, >> Jake >> >> >> From: Bob Briscoe <ietf@bobbriscoe.net> >> Date: Sun,2021-11-07 at 8:40 AM >> To: "Holland, Jake" <jholland@akamai.com>, Wesley Eddy >> <wes@mti-systems.com>, "tsvwg@ietf.org" <tsvwg@ietf.org> >> Subject: Re: [tsvwg] start of WGLC on L4S drafts >> >> Jake, >> >> Thank you for your new reviews. Pls see [BB] inline... >> On 21/08/2021 21:11, Holland, Jake wrote: >> Overall: >> The documents are in much better shape than the last time I >> reviewed >> them, thanks for all the improvements. >> >> I'm reviewing l4s-id and l4s-arch but didn't have time to get to >> dualq-aqm yet. But I wanted to make sure these got posted, and >> might not have more time before the deadline. >> >> ---- >> >> draft-ietf-tsvwg-ecn-l4s-id-19: >> There's a few major issues. These really should be fixed before >> sending it to the IESG, IMO, but with these fixed I'd be happy to >> see it shipped. >> >> Major: >> >> 1. This should be proposed standard, not experimental. >> >> [snip] >> >> [BB] See separate thread. >> >> >> >> >> 2. This text from Section 4.3 should be strengthened to recommend >> detection of paths that might be classic-marking L4S traffic >> (shared >> queue or not): >> >> o In uncontrolled environments, monitoring MUST be >> implemented to >> support detection of problems with an ECN-capable AQM at >> the path >> bottleneck that appears not to support L4S and might be in a >> shared queue. >> >> Even in fq, the standing queue that will be built by a scalable >> cc with >> classic marking is contrary to "1-2ms latency at 99th >> percentile" goal >> of L4S, even leaving aside the harm to colliding flows (though >> of course >> the harm to colliding flows, including from hash collisions in >> fq, is >> also another reason to make this change). >> >> [BB] If we make this requirement so that monitoring MUST report >> all Classic ECN AQMs, operators could just have a sea of data that >> doesn't say whether there are any of the single-queue AQMs out there >> - much more likley to be a potential problem than FQ AQMs. The key >> word in this requirement is 'problems'. >> >> Also note that the word 'might' in 'might be in a shared queue' >> allows for the case of a flow-queue that is exhibiting problems at >> the time it is monitored (e.g. during real time monitoring when >> within a VPN). BTW, we created a matrix of cases, and checked all the >> possible cases when we wordsmithed this requirement. >> >> Also, detecting a flow-queue that is ECN marking but appears to >> exceed expected L4S delay is already in the flow's self-interest. So >> I wouldn't worry about trying to legislate over-precisely about this >> case. For instance, of the two OS developers that I have had detailed >> conversations with about this, both are working on the basis that >> it's worth taking sthg like the max of the responses to increasing >> delay and to ECN marks, which will automatically lead to a >> Classic-like response in an FQ-CoDel queue, as well as in other cases >> like suddenly reduced capacity. >> >> >> >> 3. This text from Section 4.3 should be strengthened to require >> that >> sending L4S traffic in uncontrolled environments does not happen >> when >> classic marking of L4S traffic is detected for a shared queue, >> and at >> least recommend that it not happen even for fq: >> >> o In uncontrolled environments, monitoring MUST be >> implemented to >> support detection of problems with an ECN-capable AQM at >> the path >> bottleneck that appears not to support L4S and might be in a >> shared queue. Such monitoring SHOULD be applied to live >> traffic >> that is using Scalable congestion control. Alternatively, >> monitoring need not be applied to live traffic, if >> monitoring has >> been arranged to cover the paths that live traffic takes >> through >> uncontrolled environments. >> >> The current text requires monitoring, but only gives a single >> SHOULD for >> live traffic, plus non-normatively permits one alternative. >> This allows >> operators to monitor but not cut off (so this requirement as >> currently >> written would be satisfied by write-only logging for instance, >> with the >> SHOULD easily dismissable with an "implementation complexity" >> hand-wave >> while still following the spec). >> >> Suggested alternative, feel free to edit: >> >> o In uncontrolled environments, L4S traffic MUST NOT be sent >> without >> monitoring to detect marking of L4S traffic by non-L4S >> bottlenecks. >> This monitoring can for example be performed on live >> traffic, or >> can rely on monitoring that covers the paths live traffic >> takes >> through uncontrolled environments. Where non-L4S >> bottlenecks are >> observed marking L4S traffic, L4S sending MUST be disabled >> if the >> bottleneck is a shared queue, and SHOULD be disabled if it >> is FQ. >> >> [BB] Aside: Your middle sentence has (intentionally?) lost the >> 'SHOULD' preference for monitoring live, rather than out of band. >> >> I think the next para in the draft (not given in your quote) >> with its mandatory final sentence is stronger than your alternative. >> The detection function SHOULD be capable of making the >> congestion >> control adapt its ECN-marking response to coexist safely with >> Classic congestion controls such as standard Reno >> [https://protect2.fireeye.com/v1/url?k=6db358e7-32286186-6db3187c-86d8a30ca42b-f55753dc038cca88&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5681__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-uFrhRnEc%24], >> as >> required by >> [https://protect2.fireeye.com/v1/url?k=0c7104e6-53ea3d87-0c71447d-86d8a30ca42b-16e14b6a81d3b652&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5033__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-uqCDg5WI%24]. >> Alternatively, if adaptation is not >> implemented and problems with such an AQM are detected, the >> scalable congestion control MUST be replaced by a Classic >> congestion control. >> The differences are: >> * Replacement is a 'MUST' not a 'SHOULD', but conditional on >> 'problems' >> * It doesn't distinguish between shared queue and FQ. >> >> We didn't think it was reasonable to give the sender a >> requirement that depends on what type of queue it encounters, because >> the sender doesn't know the type for sure. That's why we made this >> conditional on 'problems' instead. The last sentence of this passage >> from the referenced Appendix A.1.5 explains why: >> CDN servers placed within an access ISP's >> network can be considered as a single controlled environment, >> but any >> onward networks served by the access network, including all the >> attached customer networks, would be unlikely to fall under >> the same >> degree of coordinated control. Monitoring is expressed as a >> 'MUST' >> for these uncontrolled segments of paths (e.g. beyond the >> access ISP >> in a home network), because there is a possibility that there >> might >> be a shared queue Classic ECN AQM in that segment. >> Nonetheless, the >> intent is to only require occasional monitoring of these >> uncontrolled >> regions, and not to burden CDN operators if monitoring never >> uncovers >> any potential problems, given it is anyway in the CDN's own >> interests >> not to degrade the service of its own customers. >> >> In summary I think your suggestion of conditioning on the type >> of queue is likely to be infeasible and therefore prone to being >> ignored. >> This is not easy but, on balance, I don't think I've seen >> anything here that is tighter than the existing wording. >> >> >> >> >> >> 4. Although l4s-arch claims that l4s-id satisfies the RFC 4774 >> requirements, it's hard to tell whether it does so. Specifically: >> >> 4.a. From section 7 of RFC 4774: >> Specifications of alternate ECN semantics must clearly state >> how they >> address the issues raised in this document, particularly the >> issues >> discussed in Section 2. >> >> I don't see how issues 2 and 3 from section 2 are covered in >> l4s-id. >> >From section 4 of RFC 4774: >> (2) How does the possible presence of old routers affect the >> performance of the alternate-ECN connections? >> >> (3) How does the possible presence of old routers affect the >> coexistence of the alternate-ECN traffic with competing >> traffic >> on the path? >> >> When alternate semantics are defined for the ECN field, it is >> necessary to ensure that there are no problems caused by old >> routers >> along the path that don't understand the alternate ECN >> semantics. >> >> 4.b. Section 4 goes on to describe 3 options for how alternate ECN >> semantics should be treated. I don't see a claim in the L4S docs >> specifying which of the 3 options the L4S spec for alternate ECN >> semantics >> matches, but it implicitly appears to be trying to say it's >> option 3 >> (unsafe) and asserting that the detection and adaptive response >> satisfies >> the requirement for isolation on option 3, I think? >> >> Maybe there are sections in l4s-id that intend to cover these >> points, >> and there just needs to be text listing what they are, but I >> don't think >> the link is obvious enough to satisfy the "clearly state" >> requirement >> from RFC 4774. So it would be very helpful to add a list of >> references >> to sections that are intended to address these RFC 4774 >> requirements. >> >> [BB] After guidance from the chairs, the co-authors have been >> working offlist on a fairly lengthy new subsection in ecn-l4s-id >> about where the RFC4774 requirements are and are not satisfied, and >> how that is to be dealt with. Rather than pasting it all here (it's >> long) you should see it later today once the secretariat allow the >> draft through (or otherwise when the servers re-open in the morning). >> And I'm sure the chairs will give everyone time to read it over, and >> review it. >> >> >> >> >> >> >> Nits: >> - the list in section 7.1 has a weird formatting problem for the >> sub- >> list: >> >> o Did use of L4S over the Internet result in improvements to >> the >> following metrics: >> >> o >> >> * queue delay (mean and 99th percentile) under various >> loads; >> >> [BB] Thx - (had already noticed this one myself as well). >> >> Continued... >> >> >> >> >> ---- >> >> draft-ietf-tsvwg-l4s-arch-10: >> Summary: Almost ready >> >> +1 to Gorry's comments here, especially regarding the use of >> "all traffic": >> https://protect2.fireeye.com/v1/url?k=be40b88e-e1db81ef-be40f815-86d8a30ca42b-dd7f03a662adb7a4&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftsvwg%2FvMMsQpXs65lk1E7NpV5RlmpyqdI%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-ul4tJbII%24 >> >> [BB] Accepted - see response to Gorry/Alex. >> >> >> >> >> Minor: >> 1. l4s-arch section 1: >> It has been demonstrated that, once access network bit rates >> reach >> levels now common in the developed world, increasing capacity >> offers >> diminishing returns if latency (delay) is not addressed. >> - This needs a reference. >> >> [BB] I've added: >> [Dukkipati15] >> Dukkipati, N. and N. McKeown, "Why Flow-Completion >> Time is >> the Right Metric for Congestion Control", ACM CCR >> 36(1):59--62, January 2006, >> https://protect2.fireeye.com/v1/url?k=fc8ad747-a311ee26-fc8a97dc-86d8a30ca42b-a533c17baf3c8b08&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdl.acm.org%2Fdoi%2F10.1145%2F1111322.1111336__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-un5qa5gw%24. >> [Rajiullah15] >> Rajiullah, M., "Towards a Low Latency Internet: >> Understanding and Solutions", Masters Thesis; >> Karlstad >> Uni, Dept of Maths & CS 2015:41, 2015, >> https://protect2.fireeye.com/v1/url?k=101b88f1-4f80b190-101bc86a-86d8a30ca42b-ce03fb0dd8daec7c&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.diva-portal.org%2Fsmash%2Fget%2Fdiva2%3A846109%2FFULLTEXT01.pdf__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-ud1apytw%24. >> >> >> >> Editorial: >> 1. l4s-arch 4.2 section a: >> - This is a confusing wall of text. I think it would be better to >> give a much briefer summary here with a reference. Exposition >> like "the obvious part" and "the less obvious part" are a minus >> here--I don't think the obviousness claims made here generalize >> well. >> >> [BB] When it only referenced the DualQ draft and only gave a >> short summary, we were asked to summarize more fully how the DualQ >> works here (sigh!). >> >> So we've kept the explanation here, but de-confused and >> de-walled it a bit: >> * Removed the 'obvious/non-obvious' wording. >> * Within the largest block: Introduced sub-bullets for the two >> parts of the semi-permeable membrane, each starting "Latency >> isolation:" and "Bandwidth pooling:". Then continued the part about >> the scheduler with 2 further bullets, again starting each with "for >> latency isolation" and "for bandwidth pooling". >> * Cut out some redundancy. >> * I considered shifting out the last para of the DualQ bullet, >> which is about the DualQ document, but I decided there was no better >> place for it. >> >> It's not brilliant, but I think it's better. >> >> >> >> >> 2. All the uses of underlining for emphasis are a minus. The >> places where it seems necessary or useful are a good hint that >> the text on its own is not adequately capturing the intended >> meaning. >> Leaning on this kind of toned emphasis makes assumptions about >> connotations that don't hold very well even for native English >> speakers and break down entirely for non-native speakers, so they >> are generally out of place in a technical document that will need >> to be correctly interpreted by an international audience with >> many >> non-native speakers, IMO. >> >> [BB] I agree, use of emphasis is excessive. I've taken out >> /some/ but not /all/ ;) >> >> The ones left are: >> * "on /average/" (because the comparison with the other P99 is 3 >> lines of dense numbers away) >> * "without the /need/ for per-flow operations" (to help the >> reader not to just run over the word without thinking) >> * "without /requiring/ inspection" (---ditto---) >> >> Hopefully, this is now down to a non-irritating level for those >> who don't like it, and now conforms to the guidance from the only >> source I could quickly find on international technical writing style: >> "Do not use italics for >> • mere emphasis. (Italics are acceptable if emphasis might >> otherwise be lost; in general, however, use syntax to provide >> emphasis.)" >> American Psychological Association (APA, 2009, pp. 104-106) >> via >> https://protect2.fireeye.com/v1/url?k=260dfd17-7996c476-260dbd8c-86d8a30ca42b-3095d8d339ccbe6a&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwriting.stackexchange.com%2Fquestions%2F10750%2Fwhen-should-i-use-italics-in-scientific-writing__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-uHTBTecE%24 >> >> (BTW, underscores in ASCII can mean either italics or >> underlining. In the HTML rendering, these words come out in italics - >> which was the intention) >> >> >> >> >> ---- >> >> I'm going to be too pressed for time to do a more detailed review, >> but I wanted to get the above comments in. >> >> As a final aside, I'd like to see this happen. The only goal I'm >> pursuing at this point wrt this work is avoiding preventable harm >> from pushing this out in a way that's likely to cause confusion >> when and if problems are encountered in production. (In >> particular, >> I have given up on efforts to improve the signaling design, since >> the authors have rejected all such suggestions and this work needs >> to get moved out of the wg one way or another.) >> >> [BB] On signalling design, I'd like to point out that it's not >> just the authors - the chairs have judged that the WG wants to go >> this way. >> >> Whatever, thank you - for your reviews, and for your continuing >> perseverance and diligence. >> >> Cheers >> >> Bob >> >> >> >> >> Best, >> Jake >> >> >> On 07-29, 9:18 AM, "Wesley Eddy" mailto:wes@mti-systems.com wrote: >> >> This message is starting a combined working group last call on 3 >> of the >> L4S drafts: >> >> - Architecture: >> https://protect2.fireeye.com/v1/url?k=3063a6c7-6ff89fa6-3063e65c-86d8a30ca42b-319e9c6b471639ac&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-l4s-arch%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-u3NnimRI%24 >> >> - DualQ: >> https://protect2.fireeye.com/v1/url?k=ab12b9ad-f48980cc-ab12f936-86d8a30ca42b-c10cc0b05d165a11&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-aqm-dualq-coupled%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-uscUhkHw%24 >> >> - ECN ID: >> https://protect2.fireeye.com/v1/url?k=f903ac8e-a69895ef-f903ec15-86d8a30ca42b-f06e5013138576bf&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-ecn-l4s-id%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-usmeCGjo%24 >> >> The WGLC will last through 4 weeks from today, and then we'll >> see what >> to do next. Please submit any comments you have on these to the >> TSVWG >> list in that timeframe. >> >> The chairs are considering a possible virtual interim following the >> close in order to work through feedback received. >> >> The work on the L4S operational guidance draft is continuing in >> parallel, but that draft is not being last called yet. >> >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe >> https://protect2.fireeye.com/v1/url?k=4a7b07a9-15e03ec8-4a7b4732-86d8a30ca42b-a9e8cb7bfcd026df&q=1&e=ece40b18-e6b1-45e4-b56c-a064507e4aaf&u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fbobbriscoe.net%2F__%3B%21%21GjvTz_vk%21Hnqqz6_j8SIdAfFyCkZ-d1cMB2kGbO96HKTk-QSU1VUYsO2YkIK23b-ucdq-oCs%24 >> >> > -- ________________________________________________________________ Bob Briscoe https://protect2.fireeye.com/v1/url?k=360a053d-69913c5c-360a45a6-86d8a30ca42b-f145f589d5df5449&q=1&e=569ef2be-2313-4399-a122-b60f8b4253cf&u=http%3A%2F%2Fbobbriscoe.net%2F
- [tsvwg] MUST detect problems with legacy queue [w… Mirja Kuehlewind
- Re: [tsvwg] MUST detect problems with legacy queu… Bob Briscoe
- Re: [tsvwg] MUST detect problems with legacy queu… Bob Briscoe
- Re: [tsvwg] MUST detect problems with legacy queu… Mirja Kuehlewind