Response to Reply LS in response to (SP-150579) on 3GPP Work on Explicit Congestion Notification for Lower Layer Protocols from 3GPP SA
|From Contact||David Black|
Transport Area Working Group Discussion List
|Response Contact||David Black|
|Technical Contact||Bob Briscoe
|Deadline||2017-03-10 Action Needed|
|Liaisons referred by this one||
Liaison Statement: Communication of Recommendation Y.1541, "Network Performance Objectives for IP-based Services"
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.