draft-ietf-tsvwg-ecn-encap-guidelines-07.txt   draft-ietf-tsvwg-ecn-encap-guidelines-08.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Simula Research Laboratory Internet-Draft Simula Research Laboratory
Updates: 3819 (if approved) J. Kaippallimalil Updates: 3819 (if approved) J. Kaippallimalil
Intended status: Best Current Practice Huawei Intended status: Best Current Practice Huawei
Expires: January 9, 2017 P. Thaler Expires: September 28, 2017 P. Thaler
Broadcom Corporation Broadcom Corporation
July 8, 2016 March 27, 2017
Guidelines for Adding Congestion Notification to Protocols that Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP Encapsulate IP
draft-ietf-tsvwg-ecn-encap-guidelines-07 draft-ietf-tsvwg-ecn-encap-guidelines-08
Abstract Abstract
The purpose of this document is to guide the design of congestion The purpose of this document is to guide the design of congestion
notification in any lower layer or tunnelling protocol that notification in any lower layer or tunnelling protocol that
encapsulates IP. The aim is for explicit congestion signals to encapsulates IP. The aim is for explicit congestion signals to
propagate consistently from lower layer protocols into IP. Then the propagate consistently from lower layer protocols into IP. Then the
IP internetwork layer can act as a portability layer to carry IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the congestion notification from non-IP-aware congested nodes up to the
transport layer (L4). Following these guidelines should assure transport layer (L4). Following these guidelines should assure
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017. This Internet-Draft will expire on September 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 11 skipping to change at page 4, line 11
However, until recently this was more due to the inability of TCP to However, until recently this was more due to the inability of TCP to
saturate the links. For many years, fixes such as window scaling saturate the links. For many years, fixes such as window scaling
[RFC1323] proved hard to deploy. And the New Reno variant of TCP has [RFC1323] proved hard to deploy. And the New Reno variant of TCP has
remained in widespread use despite its inability to scale to high remained in widespread use despite its inability to scale to high
flow rates. However, now that modern operating systems are finally flow rates. However, now that modern operating systems are finally
capable of saturating interior links, even the buffers of well- capable of saturating interior links, even the buffers of well-
provisioned interior switches will need to signal episodes of provisioned interior switches will need to signal episodes of
queuing. queuing.
Propagation of ECN is defined for MPLS [RFC5129], and is being Propagation of ECN is defined for MPLS [RFC5129], and is being
defined for TRILL [RFC7780], [I-D.eastlake-trill-ecn-support], but it defined for TRILL [RFC7780], [I-D.ietf-trill-ecn-support], but it
remains to be defined for a number of other subnetwork technologies. remains to be defined for a number of other subnetwork technologies.
Similarly, ECN propagation is yet to be defined for many tunnelling Similarly, ECN propagation is yet to be defined for many tunnelling
protocols. [RFC6040] defines how ECN should be propagated for IP-in- protocols. [RFC6040] defines how ECN should be propagated for IP-in-
IP [RFC2003] and IPsec [RFC4301] tunnels, and it is cited by more IP [RFC2003] and IPsec [RFC4301] tunnels, and it is cited by more
recent tunnelling protocols, e.g. Generic UDP Encapsulation (GUE) recent tunnelling protocols, e.g. Generic UDP Encapsulation (GUE)
[I-D.ietf-nvo3-gue] and Geneve [I-D.ietf-nvo3-geneve]. However, as [I-D.ietf-nvo3-gue] and Geneve [I-D.ietf-nvo3-geneve]. However, as
Section 9.3 of RFC3168 pointed out, ECN support will need to be Section 9.3 of RFC3168 pointed out, ECN support will need to be
defined for other tunnelling protocols, e.g. L2TP [RFC2661], GRE defined for other tunnelling protocols, e.g. L2TP [RFC2661], GRE
[RFC1701], [RFC2784], PPTP [RFC2637] and GTP [GTPv1], [GTPv1-U], [RFC1701], [RFC2784], PPTP [RFC2637] and GTP [GTPv1], [GTPv1-U],
skipping to change at page 7, line 17 skipping to change at page 7, line 17
CE: Congestion Experienced [RFC3168] CE: Congestion Experienced [RFC3168]
ECT: ECN-Capable Transport [RFC3168] ECT: ECN-Capable Transport [RFC3168]
Not-ECT: Not ECN-Capable Transport [RFC3168] Not-ECT: Not ECN-Capable Transport [RFC3168]
Load Regulator: For each flow of PDUs, the transport function that Load Regulator: For each flow of PDUs, the transport function that
is capable of controlling the data rate. Typically located at the is capable of controlling the data rate. Typically located at the
data source, but in-path nodes can regulate load in some data source, but in-path nodes can regulate load in some
congestion control arrangements (e.g. admission control, policing congestion control arrangements (e.g. admission control, policing
nodes or transport circuit-breakers nodes or transport circuit-breakers [RFC8084]). Note the term "a
[I-D.ietf-tsvwg-circuit-breaker]). Note the term "a function function capable of controlling the load" deliberately includes a
capable of controlling the load" deliberately includes a transport transport that doesn't actually control the load responsively but
that doesn't actually control the load responsively but ideally it ideally it ought to (e.g. a sending application without
ought to (e.g. a sending application without congestion control congestion control that uses UDP).
that uses UDP).
ECN-PDU: A PDU that is part of a feedback loop within which all the ECN-PDU: A PDU that is part of a feedback loop within which all the
nodes that need to propagate explicit congestion notifications nodes that need to propagate explicit congestion notifications
back to the Load Regulator are ECN-capable. An IP packet with a back to the Load Regulator are ECN-capable. An IP packet with a
non-zero ECN field implies that the endpoints are ECN-capable, so non-zero ECN field implies that the endpoints are ECN-capable, so
this would be an ECN-PDU. However, ECN-PDU is intended to be a this would be an ECN-PDU. However, ECN-PDU is intended to be a
general term for a PDU at any layer, not just IP. general term for a PDU at any layer, not just IP.
Not-ECN-PDU: A PDU that is part of a feedback-loop within which some Not-ECN-PDU: A PDU that is part of a feedback-loop within which some
nodes necessary to propagate explicit congestion notifications nodes necessary to propagate explicit congestion notifications
skipping to change at page 14, line 26 skipping to change at page 14, line 26
cases the shim header(s) and the outer IP header are always added (or cases the shim header(s) and the outer IP header are always added (or
removed) as part of the same process. We call this a tightly coupled removed) as part of the same process. We call this a tightly coupled
shim header. Processing the shim and outer together is often shim header. Processing the shim and outer together is often
necessary because the shim(s) are not sufficient for packet necessary because the shim(s) are not sufficient for packet
forwarding in their own right; not unless complemented by an outer forwarding in their own right; not unless complemented by an outer
header. header.
For all such tightly coupled shim headers (such as those listed in For all such tightly coupled shim headers (such as those listed in
the Introduction), the rules in [RFC6040] for propagating the ECN the Introduction), the rules in [RFC6040] for propagating the ECN
field can be applied directly between the inner and outer IP headers. field can be applied directly between the inner and outer IP headers.
[I-D.briscoe-tsvwg-rfc6040bis] clarifies that RFC 6040 is just as [I-D.ietf-tsvwg-rfc6040update-shim] clarifies that RFC 6040 is just
applicable when there is a tightly-coupled shim between two IP as applicable when there is a tightly-coupled shim between two IP
headers as wehen there is not. headers as wehen there is not.
5.2. Wire Protocol Design: Indication of ECN Support 5.2. Wire Protocol Design: Indication of ECN Support
This section is intended to guide the redesign of any lower layer This section is intended to guide the redesign of any lower layer
protocol that encapsulate IP to add native ECN support at the lower protocol that encapsulate IP to add native ECN support at the lower
layer. It reflects the approaches used in [RFC6040] and in layer. It reflects the approaches used in [RFC6040] and in
[RFC5129]. Therefore IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS [RFC5129]. Therefore IP-in-IP tunnels or IP-in-MPLS or MPLS-in-MPLS
encapsulations that already comply with [RFC6040] or [RFC5129] will encapsulations that already comply with [RFC6040] or [RFC5129] will
already satisfy this guidance. already satisfy this guidance.
skipping to change at page 16, line 19 skipping to change at page 16, line 19
technologies targeted at zero-configuration deployment or deployment technologies targeted at zero-configuration deployment or deployment
by the general public (e.g. Ethernet). For such 'plug-and-play' by the general public (e.g. Ethernet). For such 'plug-and-play'
environments it will be necessary to invent a failsafe approach that environments it will be necessary to invent a failsafe approach that
ensures congestion markings will never fall into black holes, no ensures congestion markings will never fall into black holes, no
matter how inconsistently a system is put together. Alternatively, matter how inconsistently a system is put together. Alternatively,
congestion notification relying on correct system configuration could congestion notification relying on correct system configuration could
be confined to flavours of Ethernet intended only for professional be confined to flavours of Ethernet intended only for professional
network operators, such as IEEE 802.1ah Provider Backbone Bridges network operators, such as IEEE 802.1ah Provider Backbone Bridges
(PBB). (PBB).
ECN support in TRILL [I-D.eastlake-trill-ecn-support] provides a good ECN support in TRILL [I-D.ietf-trill-ecn-support] provides a good
example of how to add ECN to a lower layer protocol without relying example of how to add ECN to a lower layer protocol without relying
on careful and consistent operator configuration. TRILL provides an on careful and consistent operator configuration. TRILL provides an
extension header word with space for flags of different categories extension header word with space for flags of different categories
depending on whether logic to understand the extension is critical. depending on whether logic to understand the extension is critical.
The congestion experienced marking has been defined as a 'critical The congestion experienced marking has been defined as a 'critical
ingress-to-egress' flag. So if a transit RBridge sets this flag and ingress-to-egress' flag. So if a transit RBridge sets this flag and
an egress RBridge does not have any logic to process it, it will drop an egress RBridge does not have any logic to process it, it will drop
it; which is the desired default action anyway. Therefore TRILL it; which is the desired default action anyway. Therefore TRILL
RBridges can be updated with support for ECN in no particular order RBridges can be updated with support for ECN in no particular order
and, at the egress of the TRILL campus, congestion notification will and, at the egress of the TRILL campus, congestion notification will
skipping to change at page 26, line 16 skipping to change at page 26, line 16
interface", Technical Specification TS 29.060. interface", Technical Specification TS 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling [GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical Specification TS Protocol User Plane (GTPv1-U)", Technical Specification TS
29.281. 29.281.
[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS) [GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS)
Tunnelling Protocol for Control plane (GTPv2-C)", Tunnelling Protocol for Control plane (GTPv2-C)",
Technical Specification TS 29.274. Technical Specification TS 29.274.
[I-D.briscoe-tsvwg-rfc6040bis]
Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", draft-
briscoe-tsvwg-rfc6040bis-00 (work in progress), July 2016.
[I-D.eastlake-trill-ecn-support]
3rd, D. and B. Briscoe, "TRILL: ECN (Explicit Congestion
Notification) Support", draft-eastlake-trill-ecn-
support-00 (work in progress), March 2016.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J. and I. Ganga, "Geneve: Generic Network Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Virtualization Encapsulation", draft-ietf-nvo3-geneve-01 Network Virtualization Encapsulation", draft-ietf-
(work in progress), January 2016. nvo3-geneve-04 (work in progress), March 2017.
[I-D.ietf-nvo3-gue] [I-D.ietf-nvo3-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-ietf-nvo3-gue-04 (work in progress), Encapsulation", draft-ietf-nvo3-gue-05 (work in progress),
July 2016. October 2016.
[I-D.ietf-tsvwg-circuit-breaker] [I-D.ietf-trill-ecn-support]
Fairhurst, G., "Network Transport Circuit Breakers", Eastlake, D. and B. Briscoe, "TRILL: ECN (Explicit
draft-ietf-tsvwg-circuit-breaker-15 (work in progress), Congestion Notification) Support", draft-ietf-trill-ecn-
April 2016. support-02 (work in progress), March 2017.
[I-D.ietf-tsvwg-rfc6040update-shim]
Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", draft-ietf-
tsvwg-rfc6040update-shim-00 (work in progress), November
2016.
[I-D.moncaster-tcpm-rcv-cheat] [I-D.moncaster-tcpm-rcv-cheat]
Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
Allow Senders to Identify Receiver Non-Compliance", draft- Allow Senders to Identify Receiver Non-Compliance", draft-
moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014. moncaster-tcpm-rcv-cheat-03 (work in progress), July 2014.
[IEEE802.1Qah] [IEEE802.1Qah]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Virtual Bridged Local Area Networks--Amendment Networks--Virtual Bridged Local Area Networks--Amendment
6: Provider Backbone Bridges", IEEE Std 802.1Qah-2008, 6: Provider Backbone Bridges", IEEE Std 802.1Qah-2008,
skipping to change at page 29, line 16 skipping to change at page 29, line 11
Concepts, Abstract Mechanism, and Requirements", RFC 7713, Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015, DOI 10.17487/RFC7713, December 2015,
<http://www.rfc-editor.org/info/rfc7713>. <http://www.rfc-editor.org/info/rfc7713>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>. <http://www.rfc-editor.org/info/rfc7780>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<http://www.rfc-editor.org/info/rfc8084>.
[UTRAN] 3GPP, "UTRAN Overall Description", Technical [UTRAN] 3GPP, "UTRAN Overall Description", Technical
Specification TS 25.401. Specification TS 25.401.
Appendix A. Outstanding Document Issues Appendix A. Outstanding Document Issues
1. [GF] Concern that certain guidelines warrant a MUST (NOT) rather 1. [GF] Concern that certain guidelines warrant a MUST (NOT) rather
than a SHOULD (NOT). Given the guidelines say that if any SHOULD than a SHOULD (NOT). Given the guidelines say that if any SHOULD
(NOT)s are not followed, a strong justification will be needed, (NOT)s are not followed, a strong justification will be needed,
they have been left as SHOULD (NOT) pending further list they have been left as SHOULD (NOT) pending further list
discussion. In particular: discussion. In particular:
skipping to change at page 30, line 24 skipping to change at page 30, line 24
congestion level), MUST (not SHOULD) drop? congestion level), MUST (not SHOULD) drop?
This issue has been addressed by explaining when SHOULD or This issue has been addressed by explaining when SHOULD or
MUST is appropriate. MUST is appropriate.
2. Consider whether an IETF Standard Track doc will be needed to 2. Consider whether an IETF Standard Track doc will be needed to
Update the IP-in-IP protocols listed in Section 5.1--at least Update the IP-in-IP protocols listed in Section 5.1--at least
those that the IETF controls--and which Area it should sit under. those that the IETF controls--and which Area it should sit under.
This issue has been addressed by the production of This issue has been addressed by the production of
[I-D.briscoe-tsvwg-rfc6040bis], but this text is left outstanding [I-D.ietf-tsvwg-rfc6040update-shim], but this text is left
until that draft is adopted. outstanding until that draft is adopted.
Appendix B. Changes in This Version (to be removed by RFC Editor) Appendix B. Changes in This Version (to be removed by RFC Editor)
From ietf-05 to ietf-06: From ietf-05 to ietf-06:
* Introduction: Added GUE and Geneve as examples of tightly * Introduction: Added GUE and Geneve as examples of tightly
coupled shims between IP headers that cite RFC 6040. And added coupled shims between IP headers that cite RFC 6040. And added
VXLAN to list of those that do not. VXLAN to list of those that do not.
* Replaced normative text about tightly coupled shims between IP * Replaced normative text about tightly coupled shims between IP
headers, with reference to new draft-briscoe-tsvwg-rfc6040bis headers, with reference to new draft-ietf-tsvwg-rfc6040update-
shim
* Wire Protocol Design: Indication of ECN Support: Added TRILL as * Wire Protocol Design: Indication of ECN Support: Added TRILL as
an example of a well-design protocol that does not need an an example of a well-design protocol that does not need an
indication of ECN support in the wire protocol. indication of ECN support in the wire protocol.
* Encapsulation Guidelines: In the case of a Not-ECN-PDU with a * Encapsulation Guidelines: In the case of a Not-ECN-PDU with a
CE outer, replaced SHOULD be dropped, with explanations of when CE outer, replaced SHOULD be dropped, with explanations of when
SHOULD or MUST are appropriate. SHOULD or MUST are appropriate.
* Feed-Up-and-Forward Mode: Explained examples more carefully, * Feed-Up-and-Forward Mode: Explained examples more carefully,
 End of changes. 16 change blocks. 
37 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/