Re: [tsvwg] Review: draft-ietf-tsvwg-ecn-encap-guidelines-14.txt
Bob Briscoe <ietf@bobbriscoe.net> Mon, 08 March 2021 11:30 UTC
Return-Path: <ietf@bobbriscoe.net>
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 85C7B3A0B1D for <tsvwg@ietfa.amsl.com>; Mon, 8 Mar 2021 03:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level:
X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpK9KAEpcVXT for <tsvwg@ietfa.amsl.com>; Mon, 8 Mar 2021 03:30:11 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (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 7D68F3A0B13 for <tsvwg@ietf.org>; Mon, 8 Mar 2021 03:30:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=igkGTUwHvbzI9cYVOAEgBl5AwGDLH6Dd3uoHTPo7Q40=; b=y9N6bcryZ8PEQMzA52EnDN3z9 IY+MML89g7oDp0UvmTKWlMFqYqFKX1LYrfVmDwhHyoAURO8LhM5QYkW4QqMusH8K/NlrbUWoe5Kzo b0NiXTQPsv0eji39SGbwnoQXLoxdIZvCiGqsQEM8hroSs3CsgNjU81ecySr51agSf2ragzqy0Mp+v RQB2fbY8lPzHW1ozR0S4Hlg0UL/PDyVFk/kM/K8L5Zf8C3XFaLXtgfOwGZcrwk/Yd+bFsYjHpb1IP 7PVM8CDXmmPxirZwvMAfQur5VfnmmMKm3xvSAK+OxN1yrcEYskX04r6aMl7+/OqA4jNMErPeZhtit DDlYiW3yA==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:35770 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lJE5R-0002Tv-1Z; Mon, 08 Mar 2021 11:30:09 +0000
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "kjohn@futurewei.com" <kjohn@futurewei.com>
References: <HE1PR0701MB22991CAB0164CFE7EC06D80EC2C40@HE1PR0701MB2299.eurprd07.prod.outlook.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <41307003-a48b-3e10-f12d-c75910b6b536@bobbriscoe.net>
Date: Mon, 08 Mar 2021 11:30:07 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <HE1PR0701MB22991CAB0164CFE7EC06D80EC2C40@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------366511A4802D3B45486DE89F"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jWswlrzPd6m4vyPPIM1CnH3Fzh4>
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: Mon, 08 Mar 2021 11:30:15 -0000
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?). 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. 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? > > 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". 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. 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? Bob > > > /Ingemar > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
- [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