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, 9 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: =?utf-8?B?MzN0Y3hxSWw3K2lPbW9nYUg5VFhuNzJIMFV1akhpQjAyWDRYQ3hLNUt3OXFW?= =?utf-8?B?bmgzcnM3SlZrS1NldDNkdW95K2t6TkZaRm5VdlltaUQzQ1lkUU1JL25WSkxr?= =?utf-8?B?bWRQK2JTZDdSNjlFZ0tlNDBtMDBwNVFSNjNNNTExbmgrT3NHdzhHYWZENEt4?= =?utf-8?B?TUtnZGRncElOOUFvZkR0NHlYdDVtVnJmZkNKemZlTXVjcGNET3VHRXlvQk1F?= =?utf-8?B?Tk95Ym9Mc3oxK0ZOWUduQWNvQjllMDVYOThyVHNsdVJRYkdFbklob2FhQnJh?= =?utf-8?B?VU56dkQ2YStZVTJ5SW9rRTJGaTNOUnRNSkpnTzEzcSs1NTNBdEFyUDZzRWVM?= =?utf-8?B?ZDZoZ1QvVC9LVEZkRVF0TlBtR01Lck1mRC82eldZc01kcFduRU0rc01mVUNa?= =?utf-8?B?ZmJscTJ5NnlVdWZDT3pYRFZsbm9QQlUzR1ovbkFVMTZMQkZ3ZjNKcUxWK2hs?= =?utf-8?B?ZzB4d0tXd1pyM0lINndMNWRXazJmblZDRWFxUExnS3NpUGZwcWxiYU9wQ0g4?= =?utf-8?B?TE9icEdmQm9Mc1U0b0dndGJnUTFGbU5VRlRaQWpkL2VwK3crRTRyUU0xSnJx?= =?utf-8?B?dERTcHRZd1A2cmEzTHVJcUJJN01TT2dZTkRsWnlBRExHd2lqa1htUTBVTDNW?= =?utf-8?B?TGpCR0NySHc2ZUR2S01rUnpqQThBbWJnQTBxR0tlNVkyemdzZjJNbVBIc2p2?= =?utf-8?B?NUxzWm44ai9BVHdSZGdzL0ZpdjZKS1dQWURlUUNGQ3BKczlZOUQwdm5QTGJG?= =?utf-8?B?VXdPUDNXbVpSYWdtUGtzT2xJR0lLTGNOQXlUUHllU0gwZ1UvNXJuT2grbzR3?= =?utf-8?B?UVk3Z1lIeEcwQzBmamZmUnJpZ0N1MFozeHQ0dEppbmtxM2VZb0tsWWRCUTVk?= =?utf-8?B?bG51VEZWQXZaM3NENXZTVUdScFBTaElJeExDYUFkZ3BpZmVyQ0FuakUvWTZW?= =?utf-8?B?MmxPSHpEVWxkTTQ3WVRKVjc3TzNnc09UcWo5SFBxemh4alZKbDF6d3pXVGlK?= =?utf-8?B?WlJGTnh0YnpxUG9LYzRkcHFDNGRML3ZWMFNBTEVCb1p2UnM1aTFtNzFFMWxo?= =?utf-8?B?T3VMQzF6KzhaK2lFWUl6OXA2bjFpTm0vSXN4SlYxeVlXZmt3bUZDU1c5aGZG?= =?utf-8?B?U1UyZnFkSkRtSEV0STc4eVNlaFFZTEt1Wk1XZnp4MHA1MjF2NWhya1ZnOTVx?= =?utf-8?B?OVFXM09rNytKeUpQRUs0MU9UR3lpQzQvalRKMnBvNjNjZDdUL2VleWdMT2lV?= =?utf-8?B?NjIwU2JLVFpKdDliSFVpeEVTSzU3WVBIc1hoa1QyM3lweHoremppR1VNZFhj?= =?utf-8?B?VkJBOWp0YVRzaVRnSmJRRktTWnA2ZUMxWXIrWGtOK0dneHJEMXg4QTZ2Tmx3?= =?utf-8?B?Q0I1d3JxTCtuSTVJUXdsWW5ZV21rWmUwQ2srcEcxOTNCVUZZa1JMUFdZUUZK?= =?utf-8?B?K2xUWldtMW11bHZVMDJBQ0VXcFdJUThnRlBETWxzVmpRL3c3MlhpSThIdUsv?= =?utf-8?B?RGRGM01oMHUyYy9objhWam5yUFZKZmhmWlhWc05pcjF6bzZLQnJHd3kxanlP?= =?utf-8?B?VE4vOTQ1Uldad3hvdGJ5dk5GTWxySkUraVNVdjFGUFpZbVRQcHBvbXJUN1dp?= =?utf-8?B?bkY1OW9TOENWTHA1NWliZGRzTjNlMFduVEw2MlpjdWxpeEhzMlZPb0V1cXJp?= =?utf-8?B?RDhjWVdjb2JISmhmYTQzZHZ4ajZTeEFmdEFVR1RKWjJZRlYzSWw5VWpGdEJH?= =?utf-8?Q?wjvLbdxg3Zgfn32baUbF/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>