draft-ietf-tsvwg-ecn-encap-guidelines-02.txt   draft-ietf-tsvwg-ecn-encap-guidelines-03.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft BT 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: September 27, 2015 P. Thaler Expires: March 28, 2016 P. Thaler
Broadcom Corporation Broadcom Corporation
March 26, 2015 September 25, 2015
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-02 draft-ietf-tsvwg-ecn-encap-guidelines-03
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 September 27, 2015. This Internet-Draft will expire on March 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
7. Feed-Backward Mode: Guidelines for Adding Congestion 7. Feed-Backward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 21 Notification . . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations (to be removed by RFC Editor) . . . . . . 22 8. IANA Considerations (to be removed by RFC Editor) . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 23 12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Outstanding Document Issues . . . . . . . . . . . . 27 Appendix A. Outstanding Document Issues . . . . . . . . . . . . 28
Appendix B. Changes in This Version (to be removed by RFC Appendix B. Changes in This Version (to be removed by RFC
Editor) . . . . . . . . . . . . . . . . . . . . . . 27 Editor) . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The benefits of Explicit Congestion Notification (ECN) described The benefits of Explicit Congestion Notification (ECN) described
below can only be fully realised if support for ECN is added to the below can only be fully realised if support for ECN is added to the
relevant subnetwork technology, as well as to IP. When a lower layer relevant subnetwork technology, as well as to IP. When a lower layer
buffer drops a packet obviously it does not just drop at that layer; buffer drops a packet obviously it does not just drop at that layer;
the packet disappears from all layers. In contrast, when a lower the packet disappears from all layers. In contrast, when a lower
layer marks a packet with ECN, the marking needs to be explicitly layer marks a packet with ECN, the marking needs to be explicitly
propagated up the layers. The same is true if a buffer marks the propagated up the layers. The same is true if a buffer marks the
skipping to change at page 7, line 40 skipping to change at page 7, line 40
sequence of packets, before any are set to the congestion sequence of packets, before any are set to the congestion
experienced (CE) codepoint if they experience congestion further experienced (CE) codepoint if they experience congestion further
downstream. Typically the original data source at layer-4. downstream. Typically the original data source at layer-4.
3. Guidelines in All Cases 3. Guidelines in All Cases
RFC 3168 specifies that the ECN field in the IP header is intended to RFC 3168 specifies that the ECN field in the IP header is intended to
be marked by active queue management algorithms. Any congestion be marked by active queue management algorithms. Any congestion
notification from an algorithm that does not conform to the notification from an algorithm that does not conform to the
recommendations in [I-D.ietf-aqm-recommendation] MUST NOT be recommendations in [I-D.ietf-aqm-recommendation] MUST NOT be
propagated from a lower layer into the ECN field in IP. propagated from a lower layer into the ECN field in IP (see also
[RFC4774] on alternate uses of the ECN field).
4. Modes of Operation 4. Modes of Operation
This section sets down the different modes by which congestion This section sets down the different modes by which congestion
information is passed between the lower layer and the higher one. It information is passed between the lower layer and the higher one. It
acts as a reference framework for the following sections, which give acts as a reference framework for the following sections, which give
normative guidelines for designers of explicit congestion normative guidelines for designers of explicit congestion
notification protocols, taking each mode in turn: notification protocols, taking each mode in turn:
Feed-Forward-and-Up: Nodes feed forward congestion notification Feed-Forward-and-Up: Nodes feed forward congestion notification
skipping to change at page 23, line 46 skipping to change at page 23, line 46
Comments and questions are encouraged and very welcome. They can be Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Transport Area working group mailing list addressed to the IETF Transport Area working group mailing list
<tsvwg@ietf.org>, and/or to the authors. <tsvwg@ietf.org>, and/or to the authors.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC of Explicit Congestion Notification (ECN) to IP",
3168, September 2001. RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, DOI 10.17487/RFC3819, July 2004,
<http://www.rfc-editor.org/info/rfc3819>.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, November 2006. RFC 4774, DOI 10.17487/RFC4774, November 2006,
<http://www.rfc-editor.org/info/rfc4774>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008. Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010. Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>.
13.2. Informative References 13.2. Informative References
[ATM-TM-ABR] [ATM-TM-ABR]
Cisco, "Understanding the Available Bit Rate (ABR) Service Cisco, "Understanding the Available Bit Rate (ABR) Service
Category for ATM VCs", Design Technote 10415, June 2005. Category for ATM VCs", Design Technote 10415, June 2005.
[Buck00] Buckwalter, J., "Frame Relay: Technology and Practice", [Buck00] Buckwalter, J., "Frame Relay: Technology and Practice",
Pub. Addison Wesley ISBN-13: 978-0201485240, 2000. Pub. Addison Wesley ISBN-13: 978-0201485240, 2000.
skipping to change at page 25, line 14 skipping to change at page 25, line 19
[I-D.ietf-conex-abstract-mech] [I-D.ietf-conex-abstract-mech]
Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism and Requirements", draft- Concepts, Abstract Mechanism and Requirements", draft-
ietf-conex-abstract-mech-13 (work in progress), October ietf-conex-abstract-mech-13 (work in progress), October
2014. 2014.
[I-D.ietf-trill-rfc7180bis] [I-D.ietf-trill-rfc7180bis]
Eastlake, D., Zhang, M., Perlman, R., Banerjee, A., Eastlake, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "TRILL: Clarifications, Ghanwani, A., and S. Gupta, "TRILL: Clarifications,
Corrections, and Updates", draft-ietf-trill-rfc7180bis-04 Corrections, and Updates", draft-ietf-trill-rfc7180bis-05
(work in progress), March 2015. (work in progress), June 2015.
[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 25, line 51 skipping to change at page 26, line 10
ITU-T, "Traffic Control and Congestion Control in B-ISDN", ITU-T, "Traffic Control and Congestion Control in B-ISDN",
ITU-T Rec. I.371 (03/04), March 2004, ITU-T Rec. I.371 (03/04), March 2004,
<http://ieeexplore.ieee.org/xpl/ <http://ieeexplore.ieee.org/xpl/
mostRecentIssue.jsp?punumber=5454061>. mostRecentIssue.jsp?punumber=5454061>.
[LTE-RA] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) [LTE-RA] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN); Overall description; Stage 2", Technical (E-UTRAN); Overall description; Stage 2", Technical
Specification TS 36.300. Specification TS 36.300.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <http://www.rfc-editor.org/info/rfc1323>.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994,
<http://www.rfc-editor.org/info/rfc1701>.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. DOI 10.17487/RFC2003, October 1996,
<http://www.rfc-editor.org/info/rfc2003>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol", RFC W., and G. Zorn, "Point-to-Point Tunneling Protocol
2637, July 1999. (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
<http://www.rfc-editor.org/info/rfc2637>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999. RFC 2661, DOI 10.17487/RFC2661, August 1999,
<http://www.rfc-editor.org/info/rfc2661>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>.
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
Explicit Congestion Notification (ECN) in IP Networks", Explicit Congestion Notification (ECN) in IP Networks",
RFC 2884, July 2000. RFC 2884, DOI 10.17487/RFC2884, July 2000,
<http://www.rfc-editor.org/info/rfc2884>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC [RFC2983] Black, D., "Differentiated Services and Tunnels",
2983, October 2000. RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC Congestion Notification (ECN) Signaling with Nonces",
3540, June 2003. RFC 3540, DOI 10.17487/RFC3540, June 2003,
<http://www.rfc-editor.org/info/rfc3540>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, May 2012. RFC 6633, DOI 10.17487/RFC6633, May 2012,
<http://www.rfc-editor.org/info/rfc6633>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660, July Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
2012. DOI 10.17487/RFC6660, July 2012,
<http://www.rfc-editor.org/info/rfc6660>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, August 2014. Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
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:
* If inner is a Not-ECN-PDU and Outer is CE (or highest severity * If inner is a Not-ECN-PDU and Outer is CE (or highest severity
congestion level), MUST (not SHOULD) drop? congestion level), MUST (not SHOULD) drop?
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 IET those that the IET
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-02 to ietf-03:
* Updated references, ad cited RFC4774.
From ietf-01 to ietf-02: From ietf-01 to ietf-02:
* Added Section for guidelines that are applicable in all cases. * Added Section for guidelines that are applicable in all cases.
* Updated references. * Updated references.
From ietf-00 to ietf-01: Updated references. From ietf-00 to ietf-01: Updated references.
From briscoe-04 to ietf-00: Changed filename following tsvwg From briscoe-04 to ietf-00: Changed filename following tsvwg
adoption. adoption.
skipping to change at page 29, line 35 skipping to change at page 30, line 38
* Tightened up guideline text to remove vagueness / passive voice * Tightened up guideline text to remove vagueness / passive voice
/ ambiguity and highlight main guidelines as numbered items. / ambiguity and highlight main guidelines as numbered items.
* Added Outstanding Document Issues Appendix * Added Outstanding Document Issues Appendix
* Updated references * Updated references
Authors' Addresses Authors' Addresses
Bob Briscoe Bob Briscoe
BT Simula Research Laboratory
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK UK
Phone: +44 1473 645196 EMail: ietf@bobbriscoe.net
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
John Kaippallimalil John Kaippallimalil
Huawei Huawei
5340 Legacy Drive, Suite 175 5340 Legacy Drive, Suite 175
Plano, Texas 75024 Plano, Texas 75024
USA USA
EMail: john.kaippallimalil@huawei.com EMail: john.kaippallimalil@huawei.com
Pat Thaler Pat Thaler
 End of changes. 32 change blocks. 
43 lines changed or deleted 65 lines changed or added

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