From nobody Tue Mar 9 01:36:39 2021 Return-Path: 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 ; 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 ; 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 ; 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 To: Bob Briscoe CC: "tsvwg@ietf.org" , "kjohn@futurewei.com" , Ingemar Johansson S 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: References: <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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 09:36:37 -0000 ------=_NextPart_000_0146_01D714D0.09B048E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0147_01D714D0.09B048E0" ------=_NextPart_001_0147_01D714D0.09B048E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Bob, please see in line [IJ] mostly ACKs on your comments /Ingemar From: Bob Briscoe Sent: den 8 mars 2021 12:30 To: Ingemar Johansson S 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 ]). 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/ ------=_NextPart_001_0147_01D714D0.09B048E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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
&n=
bsp;
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 

=C2=A0=C2=A0=C2=A0Another way =
to
=C2=A0=C2=A0 add congestion notification without =
consuming header space in the
=C2=A0=C2=A0 subnet =
protocol might be to use a parallel control plane =
protocol.


Also, S.4.4 gives the specific = example of QCN:

=C2=A0=C2=A0 3.=C2=A0 In some lower =
layer protocols congestion may be signalled as =
a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 numerical =
level, such as in the control frames of =
quantized
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
congestion notification (QCN [IEEE802.1Q]).=C2=A0 If such a =
multi-bit
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
encoding encapsulates an ECN-capable IP data packet, a =
function
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 will =
be needed to convert the quantized congestion level into =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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)
          &= nbsp;   and Evolved Universal Terrestrial Radio Access = Network
          &n= bsp;   (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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://bobbriscoe.n=
et/
------=_NextPart_001_0147_01D714D0.09B048E0-- ------=_NextPart_000_0146_01D714D0.09B048E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVaTCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF+jCCA+KgAwIBAgIP AXWsTwOGurO54gJ+lN9MMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDExMDkw OTIwNTlaFw0yMzExMTAwOTIwNTlaMGIxETAPBgNVBAoMCEVyaWNzc29uMRwwGgYDVQQDDBNJbmdl bWFyIEpvaGFuc3NvbiBTMS8wLQYJKoZIhvcNAQkBFiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNz c29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKM8NLGONT21wL/w2E/7OdQi eLiQdF9r2oH7aowAVCWcHrdaIg+RidSZj9MVEjymz2GNC+/NuJRpssy9ueaT3SeJYqw7rBBEDeIs bwqR4dB3HnbH4nJEJ+/RWt/M6qvkGWRIaKXWulA2Gpi4ogD8w7qcp+g2SOXod7Zk4ieqOvi3Bfqf a5TG8BLWxb8iOo/mtf6zRE8XDpe522ZcPbl3cl0JH9Ec57wS7Q4wtsTxqJKoFBbFrTwxV1M+MZq2 j4qYlJYy0R9dsXPOlFYN+iDoDNi0lHLLLg+eiSgFXf3mQ4wUTuZpc6WJ4lpkOooRjFcR7lTaIsCF 4viQbxnEe2ihL4sCAwEAAaOCAcYwggHCMB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZT MB0GA1UdDgQWBBQWsmSmqV2RO4zberN0nQ1XJ2q3fjAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwKwYDVR0RBCQwIoEgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJp Y3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s aW5kaXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQCkqYizUblUVAO2Hd8qacFV0dUO cJ4M/ZOMfrm/6KByKPObAVjz2j8eQ9O6oiaE/Wwhqv5XAVeE+F1dxhajzbuav+NjRHqMfOGLYsgM BLZkz/F9yHVNAo6YUtfABs2maFgOrfezn31tGupRCLb12H2MjGcMTHGNEqyXUTysrjMIyz87h5l5 5Q7eXelpaXYGKY+2W0JXSzNwek6jhipnXcjaLp+4cA5Oj4RwWxORl7HTCOStsbXIv91Hl/05+8qR XIAESI1emcrd9QjJ0r1b9MSlGMB4ORfMXfRutKn6/+m5vnyeq9JT4qGSJWZi3PN1Z4D6QMY8xDs+ 6tebCfPYzXzvNYvxPbyTxbNPi1FNszXbQpo4y3LvP7wuQJat7wUmD2CmxIv9Qu7OKkmKzT6sndY0 4VRJdQb2S+q+onf/g+WE4JPNS2dQ9oTPu6JwdYaWCAE80D2Sz7NSGncJkywh/e78EhyTfJGrm7o8 dpkuT6+IxWV/kiIVQchx9vTOZGvWhN4XcFaB+EuKzgNHlyDSmYP3E9UQ5MtSemsaUgRI6xk2adt4 tf2qN/CF24K93BIM6YPj+eKB7Y662IGwOye/OIL1p5XprdQV4uKfazQ0ZiawYErTK/qiCdQG0+n1 ORDMeVSUbznRwL5sklhsHeNGrJd/G7pU0UpZtDan4Or+8FERdTCCBsIwggSqoAMCAQICEFO4foPh nJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2 WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8AALhQ 8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL7fFzoe4i IZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Leo0awEhfL f98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBID fqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1z btT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEW qIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9e Ru3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmq v25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8z HaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IB uDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVs aWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMu dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y 3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUA A4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNHCZ7m mSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKvdASzYL4K MaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshUcqRdUbkS 13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNt cMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoK fUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFK kaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bc IkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1 mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9E KY+WkDGCAv8wggL7AgEBMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdaxPA4a6s7niAn6U30wwCQYFKw4D AhoFAKCCAXowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMzA5 MDkzNjE3WjAjBgkqhkiG9w0BCQQxFgQUBq1jkhP/S4tX3jmHsUkHBGiKMfcwQwYJKoZIhvcNAQkP MTYwNDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhow aQYJKwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCDwF1rE8DhrqzueICfpTfTDBrBgsqhkiG 9w0BCRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdaxPA4a6s7niAn6U30wwDQYJKoZIhvcNAQEB BQAEggEAE9XoBUKpabNSTYQfB75SYFs8QDEP5uu68fi184xCYhq693BDAiDZ7ghvRUi1C0or43t5 hDV5Lvll8XkwBuO5t2HQRZrQEFBNzqT7eOf5ss5jc7rbKFA3pl6A8n1z9dMSGVEyTCODLKKXWh/7 HT+sXquSYdM2DUMQ4g+3SAQYeqUpPoqbZ/o5ORPLYJn+80frVa37qE6kj+b4nWlJ63KtBEXlfM4Q zGRi0c4U2zLzSdk6sd3dosqKaIzuTSt0zFkV1yKy8TAHH18Y6fr5LXhw1U870HMQA6LcubYWqZRY 0IyZDH8jJmYm4ND0kujuQnLWPVG2VSWKpno3gl2DaZEqpgAAAAAAAA== ------=_NextPart_000_0146_01D714D0.09B048E0--