Liaison statement
Response to Reply LS in response to (SP-150579) on 3GPP Work on Explicit Congestion Notification for Lower Layer Protocols from 3GPP SA

Title:  Response to Reply LS in response to (SP-150579) on 3GPP Work on
Explicit Congestion Notification for Lower Layer Protocols from 3GPP SA 3GPP
Work Item:    ECSRA_LAA Purpose: For action

Thank you for the comprehensive response to the liaison regarding Explicit
Congestion Notification (ECN) for tunnels and lower layer protocols.

The IETF TSVWG has assessed all the 3GPP specifications identified by the
reponse as referring to ECN.  In addition to those listed, normative text was
also found in TS 23.334 (IMS-ALG). But otherwise the 3GPP list was
comprehensive and invaluable as a reference for this exercise.  No
incompatibilities were found with IETF RFCs in any of the 3GPP TSs concerning
the IP layer and higher.  However, there could be problems in two critical
radio access TSs:

* TS 36.300 (E-UTRAN)
* TS 25.401 (UTRA/HPSA)

The potential problems occur in the following two sentences:
“The eNB should set the Congestion Experienced (CE) codepoint (‘11’) in PDCP
SDUs in the downlink direction to indicate downlink (radio) congestion” “The
eNB should set the Congestion Experienced (CE) codepoint (‘11’) in PDCP SDUs in
the uplink direction to indicate uplink (radio) congestion”

Our concerns are two-fold:
1/ Requiring the eNB to set the ECN field of an SDU within a PDCP header has
layering implications. 2/ The behaviour for setting the CE field is unclear,
and perhaps even implies on-off marking, which would be incorrect.

While it is not the IETF's place to resolve these concerns, we offer the
following suggestions:

1/ We assume the "the CE codepoint in PDCP SDUs" is intended to refer to "the
CE codepoint in the (outermost) IP header within PDCP SDUs".   If that is the
case, this represents a layering violation, although the IETF recognizes that
there are some circumstances where such a layering violation is benign.

For these TSs, we believe Robust Header Compression (RoHC) is applied to the
PDCP SDU, so in the downlink ECN marking will have to be applied before
compression and in the uplink, if access to the ECN field is needed, it will
only be possible after decompression.

Therefore, we suggest the 3GPP ensure that the circumstances where the eNB
accesses the IP header match those where violating layering is benign, as
discussed in Section 6 of [ecn-encap], entitled "Feed-Up-and-Forward Mode:
Guidelines for Adding Congestion Notification".  While this document is still
only a draft, it is a mature draft that the IETF is likely to publish it as a
"best current practice" RFC without significant further changes.

[ecn-encap] Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-07#section-6

2/ The quoted text should state that that the eNB should set the CE codepoint
probabilistically with higher levels of radio congestion resulting in higher
probabilities of setting the CE codepoint.  The above quoted text allows (and
could be read to imply) that congestion is an on-off condition, and hence
marking of the CE codepoint is consequently be either all-on or all-off for a
period of time. For further discussion, please refer to the IETF's
"Recommendations Regarding Active Queue Management" [RFC7567], where random CE
marking based on marking probabilities is recommended.

It is also important that any 3GPP specification of end-point response to CE
markings does not assume on-off marking behavior in the network.  Otherwise
there could be interoperability problems when a data flow passes through
non-3GPP networks that set the CE codepoint probabilistically - a 3GPP endpoint
could trigger a significant congestion response based on a very low level of
congestion in the non-3GPP network.

We trust that 3GPP will resolve these concerns, hopefully without further need
for formal liaison. We thank the 3GPP again for the very useful response. 
Please let us know if we can be of further assistance.