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

[Bob Briscoe <[e-mail]>]

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/