Subject: Re: [tsvwg] Review: draft-ietf-tsvwg-ecn-encap-guidelines-14.txt

From: Bob Briscoe <[email-masked]>
Date: Mon, 8 Mar 2021 11:30:07 +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/

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 9 Mar 2021 09:36:19 +0000

Hi

Bob, please see in line [IJ] mostly ACKs on your comments
/Ingemar

From: Bob Briscoe <[email-masked]>
Sent: den 8 mars 2021 12:30
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Review: draft-ietf-tsvwg-ecn-encap-guidelines-14.txt

Hi Bob, John + others

[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

   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.

[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.

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

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>