Re: [tsvwg] Review: draft-ietf-tsvwg-ecn-encap-guidelines-14.txt
Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Tue, 09 March 2021 09:36 UTC
Return-Path: <ingemar.s.johansson@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 082B13A18AC for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 01:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 TqZcFzaYCPHD for <tsvwg@ietfa.amsl.com>; Tue, 9 Mar 2021 01:36:31 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140087.outbound.protection.outlook.com [40.107.14.87]) (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 60D563A188F for <tsvwg@ietf.org>; Tue, 9 Mar 2021 01:36:31 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eCifWdqIVXg++mGkYt4UQAlqVvMaduQ2A7ZgEmpFzKOTAVX6B50jFsdHusUA2cIsy+F3eevT+X5ArOwy2SoQwF6acmDX6zLJ73hsu9JGqLx0Ug9HADvtaWqGwU3CzdzXcPuCnKeAddVFJFkFha0TY7kW8kf8XM50r40A+UYpUSLEp64FPxbiuk3HmHL+j3v5H+TTRvqIC/X2TAy4NdtCnISaKgALezV0y2pTIYQR3p5/nZkQNIbKptjsvaD4sidhfcxWhFWrfzDFmOYHgcrLtzJsIvX06NQg+bV4blYjF+SoqkzDKSpKjYFBtGLThhP8BE2YMrpHq6ncULA3htub4w==
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-SenderADCheck; bh=+gsQTWiUnhyOCFoABeJz5yqzSJnvPh289GTSRC7j8eo=; b=STo5QgKV6DM30YbUL4uOa/DIRZAS2LuHkc+XWxkyflCtCXD2H62t76eYVD5MMDOx0wMjijvKqmRf7lnr0IE+RO8lXiA52sttTToHIvOD8nwZF5e7c34IsTG8eAkH84Ysc7wzPzemdt3tr1rnqFSVXc+zag/QT02B6MOf8PndF8DWerk2kDFsYVYaUV6Q+wRxl3qclWdEVzJQ5Le20wwEdGXg05lm1/HU28d6mO52Uny+j8hwCFRw+SPUoNuu0TIse+gipmbD8toaEJ+1d6352fNrbl0zdUNkCCC604iY83o9W7wDArQhP6AjszxLkONGS9zeP+H+YEaE0pKSlZ6PYA==
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=+gsQTWiUnhyOCFoABeJz5yqzSJnvPh289GTSRC7j8eo=; b=qlXWjzLMe+jZAKiv5JsGm4unxGFcIkrC8mUC1Jdc9Fi4s6AXMxaY7ogO/PI+ANTf2EjBfS+26DSoPGxRa1aQQ4YjbKM8H0W/b6zajqh+JPFRn3TNHq52eDYHYWgOpRA+KN9NZeJ7qKinZc+OrtV86Vvh9SHWhaMpBHVPB8vwjpE=
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com (2603:10a6:3:6c::8) by HE1PR07MB4346.eurprd07.prod.outlook.com (2603:10a6:7:97::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.15; Tue, 9 Mar 2021 09:36:19 +0000
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::a087:95cb:e76b:d57]) by HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::a087:95cb:e76b:d57%10]) with mapi id 15.20.3912.027; Tue, 9 Mar 2021 09:36:19 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, "kjohn@futurewei.com" <kjohn@futurewei.com>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Thread-Topic: Review: draft-ietf-tsvwg-ecn-encap-guidelines-14.txt
Thread-Index: AdbUg4hlJUVmE6i0SXi93Is9bhk4Fg/ituSAAC4DPQA=
Date: Tue, 09 Mar 2021 09:36:19 +0000
Message-ID: <HE1PR0701MB22995236643670DD73972B5BC2929@HE1PR0701MB2299.eurprd07.prod.outlook.com>
References: <HE1PR0701MB22991CAB0164CFE7EC06D80EC2C40@HE1PR0701MB2299.eurprd07.prod.outlook.com> <41307003-a48b-3e10-f12d-c75910b6b536@bobbriscoe.net>
In-Reply-To: <41307003-a48b-3e10-f12d-c75910b6b536@bobbriscoe.net>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0ced6d69-4ad5-4858-5c9b-08d8e2decb26
x-ms-traffictypediagnostic: HE1PR07MB4346:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB43467CA43D5CDC036EEC1BBFC2929@HE1PR07MB4346.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +3VRKYlkwsCvDLiMZ7iFGZ9VXSeYOL26xu/4hbdpDtwWtPJbywci1o8Y/R7tyaUP1i0cVV60290qleO6HoHqIx+Yq4/MY4xM15CqGSg0UJ/MhmXl0z3KPaJiiw9stKo5kz4i1whdU1g/3ITw5tz3IzaEO0bzVHHh7B14u7gwBi5tsN5u/4FQKrnNR/i988hQIcULU3FIQJNCf3xc1yKpqXTV5fOmpufPOVyQXu+7Cgd87B/mP2QSmaL6D3woGtl3vgkE5FhjZ9QQTPrQbiuF13LLSBBUIdkFLd2soR2Duonh+r3hRevESy6aAr8gokFatyRcTqUHoI017eVZBE4jdUklK+r2dKSRav17A1pJ2RIyuyYgf7hgJhBIyIEFcKTJSXE8h8/IkyOvDNrL7ubzc9ASss3CmCGSwJ7nT9bTw0HSnTs/eTRzzHYU8O5IZwQI/wa/QjRqbwVqLUVcQEbW8tCpYfQkuFIfizlN1n68lEOnuzI6isS+Cg32osWMU8H35h/MMNKCvFmP+yeXr9UxR/iHu4bvkeRTqw5JH/TGCT8MllRkqVWmU1aQoc3FoOurfWEZkeoHxo4y9X4FLIIwD2T2SvYwyik9j7felQRYijY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2299.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(366004)(376002)(396003)(346002)(7696005)(99936003)(66556008)(54906003)(66446008)(5660300002)(9686003)(166002)(64756008)(66476007)(6506007)(83380400001)(66946007)(76116006)(53546011)(55016002)(86362001)(66616009)(33656002)(478600001)(966005)(186003)(316002)(52536014)(71200400001)(8676002)(8936002)(2906002)(4326008)(107886003)(26005)(6916009)(9326002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 33tcxqIl7+iOmogaH9TXn72H0UujHiB02X4XCxK5Kw9qVnh3rs7JVkKSet3duoy+kzNFZFnUvYmiD3CYdQMI/nVJLkmdP+bSd7R69EgKe40m00p5QR63M511nh+OsGw8GafD4KxMKgddgpIN9AofDt4yXt5mVrffCJzfeMucpcDOuGEyoBMENOyboLsz1+FNYGnAcoB9e05X98rTsluRQbGEnIhoaaBraUNzvD6a+YU2yIokE2Fi3NRtMJJgO13q+553AtArP6sEeLd6hgT/T/KTFdEQtNPmGMKrMfD/6zWYsMdpWnEM+sMfUCZfblq2y6yUufCOzXDVlnoPBU3GZ/nAU16LBFwf3JqLV+hlg0xwKWwZr3IH6wL5dWk2fnVCEaqPLgKsiPfpqlbaOpCH8LObpGfBoLsU4oGgtbgQ1FmNUFTZAjd/ep+w+E4rQM1JrqtDSptYwP6ra3LuIqBI7MSOgYNDlZyADLGwijkXmQ0UL3VLjBGCrHw6eDvKMkRzjA8AmbgA0qGKe5Y2zgsf2MmPHsjv5LsZn8j/ATwRdgs/Fiv6JKWPYDeQCFCpJs9Y9D0vnPLbFUwOP3WmZRagmPksOlIGIKLcNAyTPyeSH0gU/5rnOh+o4wQY7gYHxG0C0fjffRrigCu0Z3xt4tJinkq3eYoKlYdBQ5dlnuTFVAvZ3sD5vSUGRpPShIIxLCaAdgpiferCAnjE/Y6V2lOHzDUldM47YTJV77O3gsOTqj9HPqzhxjVJl1zwzWTiJZRFNxtbzqPoKc4dpqC4dL/vV0SALEBoZvRs5i1m71E1lhOuLC1z+8Z+iEYIz9p6n1iNm/IsxJV1yYWfkwmFCSW9hfFSU2fqdJDmHEtI78ySehQYLKuZMWfzx0p521v5hrkVg95q9QW3Ok7+JyJPEK41OTGyiC4/jTJ2po63cd7T/eeygLOiU620SbKTZJt9bHUixESK57YPHsXhkT23ypxz+zjiGUMdXcVBA9jtaTsiTgJbQFKSZp6eC1Yr+XkN+GgxrD1x8A6vNlwCB5wrqL+nI5IQwlYnYWmkZe0Ck+pG193BUFYkRLPWYQFJ+lTZWm1mulvU02ACEWpWIQ8gFPDMlsVjQ/w72XiI8HuK/DdF3Mh0u2c/hn8VjnrPVJfhfZXVsNir1zo6KBrGwy1jyOTN/945RWZwxotbyvNFMlrJE+iSUv1FPZYmTPppomrT7WinF59oS8CVLp55ibddsN3e0WnTL62ZculixHs2VOoEuqriD8cYWcobHJhfa43dvxj6SxAftAUGTJZ2YFV3Il9UjFtBGwjvLbdxg3Zgfn32baUbF/t4ctVd0L4K0wmJY4WB
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0146_01D714D0.09B048E0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2299.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ced6d69-4ad5-4858-5c9b-08d8e2decb26
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2021 09:36:19.1041 (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: Pw9j+vCF2O4K/VIW6S0eNTI0qUGhlVL+C9glPhT5WMQezXotl90OaeVrVhB+ZmXP2K8FAdLFS3BErnTuYleX8DlxU/RuxpsYNz+NrF8Eqe4uEXIee992YPaXez/ADLbZ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4346
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vz2KD07aeTganr34jvIBCRtkdjs>
Subject: Re: [tsvwg] Review: draft-ietf-tsvwg-ecn-encap-guidelines-14.txt
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 Mar 2021 09:36:37 -0000
Hi Bob, please see in line [IJ] mostly ACKs on your comments /Ingemar From: Bob Briscoe <ietf@bobbriscoe.net> Sent: den 8 mars 2021 12:30 To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Cc: tsvwg@ietf.org; kjohn@futurewei.com Subject: Re: Review: draft-ietf-tsvwg-ecn-encap-guidelines-14.txt Ingemar, inline tagged [BB]... On 17/12/2020 15:10, Ingemar Johansson S wrote: Hi Bob, John + others Very slow with the review of these documents, sorry for that. I have now reviewed draft-ietf-tsvwg-ecn-encap-guidelines-14.txt My comments are mostly around the implementation of ECN capability in 4G/5G (eNB/gNB). The comments are applicable mainly for downlink data traffic and the case where queues build up in the RLC layer. Section 4 : Feed-Forward-and-Up mode. A 3GPP RAN2 contribution was proposed a while ago, the outline was here that a RLC Control PDU (or a MAC Control Element) is signaled from the eNB or gNB to the UE (mobile terminal or modem). This can be just an indication that the next decapsulated ECT IP packet should be CE marked, or it can be an indication to CE mark packets with a given probability. At least for now I believe that the mark probability option is to prefer as a per packet signaling can become too burdensome. It can be worth to mention that this proposal has so far not gained momentum in 3GPP [BB] I try to avoid citing possibly ephemeral documents such as individual IETF drafts from documents like this that are intended as BCP. So I don't really want to cite a proposal into 3GPP that didn't go anywhere (yet?). [IJ] OK, sounds reasonable This does raise the question, though, of whether to give any advice to help decide between a unary encoding with 1 or 2 bits per frame (probabilistic marks on a stream packets) versus less frequent control messages that tell a remote system what probability to mark with. However, I wouldn't want to give such advice in this doc. Those designing such a system would have to try it out empirically in the particular environment of their use-case to make sure it handled changes fast enough. [IJ] OK, and perhaps this is something that is up to implementation depending on the possibilities and limitations, it is not for certain that it needs to be documented in standards. The introduction says Another way to add congestion notification without consuming header space in the subnet protocol might be to use a parallel control plane protocol. Also, S.4.4 gives the specific example of QCN: 3. In some lower layer protocols congestion may be signalled as a numerical level, such as in the control frames of quantized congestion notification (QCN [IEEE802.1Q <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-14#ref-IEEE802.1Q> ]). If such a multi-bit encoding encapsulates an ECN-capable IP data packet, a function will be needed to convert the quantized congestion level into the frequency of congestion markings in outgoing IP packets. So do you agree that there's nothing further to change in the doc on this point? [IJ] Yes, this probably covers it. Section 5 : Feed-Up-and-Forward mode. This is problematic to achieve with the present LTE and NR standards (4G and 5G) as the IP headers are encrypted on the RLC layer. An approach to mark an IP packet would the require that the RLC SDU is decrypted, and the IP header is extracted and marked , then encrypted again. This can perhaps be doable with classic ECN but appears to me as quite unfeasible to do for instance for L4S where a large fraction of packets may be marked. [BB] I would certainly not expect an ECN capability to be added to the RLC layer in 4G/5G using feed-up-and-forward (for the encryption reasons you give). I don't think anything further needs writing in the draft from what you've said above. Sec.5 already says feed-up-and-forward is not applicable where "Link-layer encryption might be in use, making the layer-2 payload inaccessible". [IJ] OK, missed that, sorry Sec.5. also gives the example for the VoLTE service where in the uplink direction the eNode-B is forwarding on a packet from the radio access and it has stripped off the RLC layer, but not the PDCP layer header inside it, which encapsulates a non-encrypted IP header. The eNode-B buries inside the PDCP header and writes the ECN field of the IP header. The draft cites [LTE-RA]. I've just checked the latest version (07-Jan-2021) and it is still in there. [LTE-RA] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2", Technical Specification TS 36.300. Section 6 : Feed-Backward mode. This is currently the mode that is the most feasible to implement in LTE/NR, given the current 3GPP standardization status. The approach requires signaling from the layer where the queue builds up (RLC) to the PDCP layer where the next ECT IP packet subject to ciphering is marked, thus it essentially becomes tail marking. In Davide Brunello's L4S in 5G paper an additional constraint was put on the signaling, which resulted in that a mark probability was signaled up to the PDCP layer. [BB] I think Brunello's proposal is best described as feed-backward-then-forward. That's not been done in a production system before - to my knowledge. The examples of feed-backward mode in the draft feed back to a node at the ingress of the subnet that regulates the load into the subnet (e.g. a shaper/policer). If the load from the higher layer keeps arriving, it backs up at this regulator and eventually queues or drops. That indirectly causes congestion signals to feed-forward. Brunello's scheme is at least stitched together better. The subnet ingress node is not a load regulator; instead it receives the backward feedback and directly propagates these signals up to the higher layer to be forwarded. This is certainly faster than waiting for the queue to grow at the subnet ingress. But obviously the feedback path is still rather circuitous. [IJ] It is not optimal but appears to work better than expected. Hope though that if/when L4S flies that it will be possible to argue for better methods such as RLC Ctrl PDUs, but that is something for the future Again, I don't think there's anything I can add to the text here. Given this is a BCP, I would rather keep it based on stuff that has been implemented and used in production, so experience has been learned from it. If Feed-backward-then-forward is the most feasible mode in LTE/NR, then do you think that the draft at least gives sufficient and appropriate warnings about what to watch our for, at least from experience of feed-backward mode? [IJ] Yes, I agree now that the info already in the draft is sufficient. Bob /Ingemar -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ <https://protect2.fireeye.com/v1/url?k=8bfe80da-d465b9df-8bfec041-86d2114eab2f-77c55ce524c4a857&q=1&e=c231e073-66ce-4921-8aaa-bee9c07e4a15&u=http%3A%2F%2Fbobbriscoe.net%2F>
- [tsvwg] Review: draft-ietf-tsvwg-ecn-encap-guidel… Ingemar Johansson S
- Re: [tsvwg] Review: draft-ietf-tsvwg-ecn-encap-gu… Bob Briscoe
- Re: [tsvwg] Review: draft-ietf-tsvwg-ecn-encap-gu… Ingemar Johansson S