Liaison statement
Explicit Congestion Notification for Lower Layer Protocols

State Posted
Posted Date 2015-07-21
From Group tsvwg
From Contact David Black
To Group 3GPP
To Contacts Susanna.Kooistra@etsi.org
CcGonzalo Camarillo
Gorry Fairhurst
Martin Stiemerling
Spencer Dawkins
John Kaippallimalil
Bob Briscoe
Transport Area Working Group Discussion List
Response Contact David Black
Technical Contact Bob Briscoe
Purpose For comment
Deadline 2015-10-30 Action Needed
Attachments (None)
Body
To: 3GPP SA, 3GPP CT, 3GPP RAN, 3GPP SA4, 3GPP SA2, 3GPP RAN2
From: IETF TSVWG

In 2001, the IETF introduced explicit congestion notification (ECN) to the
Internet Protocol as a proposed standard [RFC3168]. The purpose of ECN was to
notify congestion without having to drop packets. The IETF originally
specified ECN for cases where buffers were IP-aware. However, ECN is now being
used in a number of environments including codec selection and rate
adaptation, where 3GPP protocols such as PDCP encapsulate IP. As active queue
management (AQM) and ECN become widely deployed in 3GPP networks and
interconnected IP networks, it could be incompatible with the standardized use
of ECN across the end-to-end IP transport [RFC7567].

The IETF is now considering new uses of ECN for low latency
[draft-welzl-ecn-benefits] that would be applicable to 5G mobile flows.
However, the IETF has realized that it has given little if any guidance on how
to add explicit congestion notification to lower layer protocols or interfaces
between lower layers and ECN in IP.

This liaison statement is to inform 3GPP, in particular those groups including
those involved in 3GPP Release-10 work on the work item ECSRA_LA (TR23.860) -
SA4, CT4, SA2 and RAN2. Please distribute to all groups that have used or plan
to use IETF ECN /AQM RFCs in 3GPP specifications. 

The IETF has started work on guidelines for adding ECN to protocols that may
encapsulate IP and interfacing these protocols with ECN in IP. Then IP may act
in its role as an interoperability protocol over multiple forwarding
protocols. This activity is led by the IETF's transport services working group
(tsvwg).

Actions:
The IETF tsvwg kindly asks 3GPP:
1) to tell the IETF tsvwg which 3GPP working groups could be affected by this
work.
2) To inform the IETF tsvwg of any specific 3GPP specifications affected by
this work.
3) to forward this liaison statement to these affected working groups, and to
invite them to review the latest draft of the guidelines, available here:
         < http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines>

Review comments are particularly welcome on:
  - comprehensibility for the 3GPP community
  - usefulness and applicability
  - technical feasibility

Review comments may be posted directly to the IETF tsvwg mailing list <mailto:
tsvwg@ietf.org>. Postings from non-subscribers may be delayed by moderation.
Alternatively, subscription is open to all at: <
https://www.ietf.org/mailman/listinfo/tsvwg>.

The following IETF specifications or drafts are particularly relevant to this
activity (the relevance of each of them is explained in the first item
below):
* draft-ietf-tsvwg-ecn-encap-guidelines
* RFC3168 updated by RFC4301, RFC6040 (ECN in respectively: IP/TCP, IPsec &
IP-in-IP tunnels)
* RFC6679 (ECN in RTP)
* RFC5129 updated by RFC5462 (ECN in MPLS)
* RFC4774 (Specifying alternative semantics for the ECN field)
* RFC7567 (Recommendations Regarding Active Queue Management
* draft-welzl-ecn-benefits (Benefits to Applications of Using ECN)

Yours,
--David L. Black (TSVWG co-chair)