draft-ietf-tsvwg-ecn-encap-guidelines-12.txt   draft-ietf-tsvwg-ecn-encap-guidelines-13.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Independent Internet-Draft Independent
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 30, 2019 P. Thaler Expires: November 21, 2019 P. Thaler
Broadcom Corporation Broadcom Corporation (retired)
March 29, 2019 May 20, 2019
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-12 draft-ietf-tsvwg-ecn-encap-guidelines-13
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
interworking between new lower layer congestion notification interworking among IP layer and lower layer congestion notification
mechanisms, whether specified by the IETF or other standards bodies. mechanisms, whether specified by the IETF or other standards bodies.
This document updates the advice to subnetwork designers about ECN in
RFC 3819.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 30, 2019. This Internet-Draft will expire on November 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Update to RFC 3819 . . . . . . . . . . . . . . . . . . . 5
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 8 3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 9
3.1. Feed-Forward-and-Up Mode . . . . . . . . . . . . . . . . 9 3.1. Feed-Forward-and-Up Mode . . . . . . . . . . . . . . . . 9
3.2. Feed-Up-and-Forward Mode . . . . . . . . . . . . . . . . 10 3.2. Feed-Up-and-Forward Mode . . . . . . . . . . . . . . . . 11
3.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 11 3.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 12
3.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion 4. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 13 Notification . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. IP-in-IP Tunnels with Shim Headers . . . . . . . . . . . 14 4.1. IP-in-IP Tunnels with Shim Headers . . . . . . . . . . . 15
4.2. Wire Protocol Design: Indication of ECN Support . . . . . 15 4.2. Wire Protocol Design: Indication of ECN Support . . . . . 16
4.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 17 4.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 18
4.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 19 4.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 20
4.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 20 4.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 22
4.6. Reframing and Congestion Markings . . . . . . . . . . . . 21 4.6. Reframing and Congestion Markings . . . . . . . . . . . . 22
5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Feed-Backward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 23 Notification . . . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations (to be removed by RFC Editor) . . . . . . 24 6. Feed-Backward Mode: Guidelines for Adding Congestion
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 Notification . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations (to be removed by RFC Editor) . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 26 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Changes in This Version (to be removed by RFC Appendix A. Changes in This Version (to be removed by RFC
Editor) . . . . . . . . . . . . . . . . . . . . . . 32 Editor) . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The benefits of Explicit Congestion Notification (ECN) described in The benefits of Explicit Congestion Notification (ECN) described in
[RFC8087] and summarized below can only be fully realised if support [RFC8087] and summarized below can only be fully realized if support
for ECN is added to the relevant subnetwork technology, as well as to for ECN is added to the relevant subnetwork technology, as well as to
IP. When a lower layer buffer drops a packet obviously it does not IP. When a lower layer buffer drops a packet obviously it does not
just drop at that layer; the packet disappears from all layers. In just drop at that layer; the packet disappears from all layers. In
contrast, when a lower layer marks a packet with ECN, the marking contrast, when active queue management (AQM) at a lower layer marks a
needs to be explicitly propagated up the layers. The same is true if packet with ECN, the marking needs to be explicitly propagated up the
a buffer marks the outer header of a packet that encapsulates inner layers. The same is true if AQM marks the outer header of a packet
tunnelled headers. Forwarding ECN is not as straightforward as other that encapsulates inner tunnelled headers. Forwarding ECN is not as
headers because it has to be assumed ECN may be only partially straightforward as other headers because it has to be assumed ECN may
deployed. If an egress at any layer is not ECN-aware, or if the be only partially deployed. If a lower layer header that contains
ultimate receiver or sender is not ECN-aware, congestion needs to be ECN congestion indications is stripped off by a subnet egress that is
indicated by dropping a packet, not marking it. not ECN-aware, or if the ultimate receiver or sender is not ECN-
aware, congestion needs to be indicated by dropping a packet, not
marking it.
The purpose of this document is to guide the addition of congestion The purpose of this document is to guide the addition of congestion
notification to any subnet technology or tunnelling protocol, so that notification to any subnet technology or tunnelling protocol, so that
lower layer equipment can signal congestion explicitly and it will lower layer AQM algorithms can signal congestion explicitly and it
propagate consistently into encapsulated (higher layer) headers, will propagate consistently into encapsulated (higher layer) headers,
otherwise the signals will not reach their ultimate destination. otherwise the signals will not reach their ultimate destination.
ECN is defined in the IP header (v4 and v6) [RFC3168] to allow a ECN is defined in the IP header (v4 and v6) [RFC3168] to allow a
resource to notify the onset of queue build-up without having to drop resource to notify the onset of queue build-up without having to drop
packets, by explicitly marking a proportion of packets with the packets, by explicitly marking a proportion of packets with the
congestion experienced (CE) codepoint. congestion experienced (CE) codepoint.
Given a suitable marking scheme, ECN removes nearly all congestion Given a suitable marking scheme, ECN removes nearly all congestion
loss and it cuts delays for two main reasons: loss and it cuts delays for two main reasons:
skipping to change at page 5, line 7 skipping to change at page 5, line 11
layer protocol. So this document gives guidelines for designing layer protocol. So this document gives guidelines for designing
propagation of congestion notification across the interface between propagation of congestion notification across the interface between
IP and protocols that may encapsulate IP (i.e. that can be layered IP and protocols that may encapsulate IP (i.e. that can be layered
beneath IP). Each lower layer technology will exhibit different beneath IP). Each lower layer technology will exhibit different
issues and compromises, so the IETF or the relevant standards body issues and compromises, so the IETF or the relevant standards body
must be free to define the specifics of each lower layer congestion must be free to define the specifics of each lower layer congestion
notification scheme. Nonetheless, if the guidelines are followed, notification scheme. Nonetheless, if the guidelines are followed,
congestion notification should interwork between different congestion notification should interwork between different
technologies, using IP in its role as a 'portability layer'. technologies, using IP in its role as a 'portability layer'.
Therefore, the capitalised terms 'SHOULD' or 'SHOULD NOT' are often Therefore, the capitalized terms 'SHOULD' or 'SHOULD NOT' are often
used in preference to 'MUST' or 'MUST NOT', because it is difficult used in preference to 'MUST' or 'MUST NOT', because it is difficult
to know the compromises that will be necessary in each protocol to know the compromises that will be necessary in each protocol
design. If a particular protocol design chooses to contradict a design. If a particular protocol design chooses not to follow a
'SHOULD (NOT)' given in the advice below, it MUST include a sound 'SHOULD (NOT)' given in the advice below, it MUST include a sound
justification. justification.
It has not been possible to give common guidelines for all lower It has not been possible to give common guidelines for all lower
layer technologies, because they do not all fit a common pattern. layer technologies, because they do not all fit a common pattern.
Instead they have been divided into a few distinct modes of Instead they have been divided into a few distinct modes of
operation: feed-forward-and-upward; feed-upward-and-forward; feed- operation: feed-forward-and-upward; feed-upward-and-forward; feed-
backward; and null mode. These modes are described in Section 3, backward; and null mode. These modes are described in Section 3,
then in the subsequent sections separate guidelines are given for then in the subsequent sections separate guidelines are given for
each mode. each mode.
This document updates the advice to subnetwork designers about ECN in 1.1. Update to RFC 3819
Section 13 of [RFC3819].
1.1. Scope This document updates the brief advice to subnetwork designers about
ECN in [RFC3819], by replacing the last two paragraphs of Section 13
with the following sentence:
By following the guidelines in [RFCXXXX], subnetwork designers can
enable a layer-2 protocol to participate in congestion control
without dropping packets via propagation of explicit congestion
notification (ECN [RFC3168]) to receivers.
and adding [RFCXXXX] as an informative reference. {RFC Editor: Please
replace both instances of XXXX above with the number of this RFC when
published.}
1.2. Scope
This document only concerns wire protocol processing of explicit This document only concerns wire protocol processing of explicit
notification of congestion. It makes no changes or recommendations notification of congestion. It makes no changes or recommendations
concerning algorithms for congestion marking or for congestion concerning algorithms for congestion marking or for congestion
response, because algorithm issues should be independent of the layer response, because algorithm issues should be independent of the layer
the algorithm operates in. the algorithm operates in.
The default ECN semantics are described in [RFC3168] and updated by The default ECN semantics are described in [RFC3168] and updated by
[RFC8311]. Also the guidelines for AQM designers [RFC7567] clarify [RFC8311]. Also the guidelines for AQM designers [RFC7567] clarify
the semantics of both drop and ECN signals from AQM algorithms. the semantics of both drop and ECN signals from AQM algorithms.
skipping to change at page 5, line 36 skipping to change at page 6, line 4
This document only concerns wire protocol processing of explicit This document only concerns wire protocol processing of explicit
notification of congestion. It makes no changes or recommendations notification of congestion. It makes no changes or recommendations
concerning algorithms for congestion marking or for congestion concerning algorithms for congestion marking or for congestion
response, because algorithm issues should be independent of the layer response, because algorithm issues should be independent of the layer
the algorithm operates in. the algorithm operates in.
The default ECN semantics are described in [RFC3168] and updated by The default ECN semantics are described in [RFC3168] and updated by
[RFC8311]. Also the guidelines for AQM designers [RFC7567] clarify [RFC8311]. Also the guidelines for AQM designers [RFC7567] clarify
the semantics of both drop and ECN signals from AQM algorithms. the semantics of both drop and ECN signals from AQM algorithms.
[RFC4774] is the appropriate best current practice specification of [RFC4774] is the appropriate best current practice specification of
how algorithms with alternative semantics for the ECN field can be how algorithms with alternative semantics for the ECN field can be
partitioned from Internet traffic that uses the default ECN partitioned from Internet traffic that uses the default ECN
semantics, for example: semantics. There are two main examples for how alternative ECN
semantics have been defined in practice:
o by using the ECN field in combination with a Diffserv codepoint o RFC 4774 suggests using the ECN field in combination with a
such as in PCN [RFC6660], Voice over 3G [UTRAN] or Voice over LTE Diffserv codepoint such as in PCN [RFC6660], Voice over 3G [UTRAN]
(VoLTE) [LTE-RA]; or Voice over LTE (VoLTE) [LTE-RA];
o or by using the ECT(1) codepoint of the ECN field to indicate o RFC 8311 suggests using the ECT(1) codepoint of the ECN field to
alternative semantics such as for the experimental Low Latency Low indicate alternative semantics such as for the experimental Low
Loss Scalable throughput (L4S) service [RFC8311] Latency Low Loss Scalable throughput (L4S) service
[I-D.ietf-tsvwg-ecn-l4s-id]). [I-D.ietf-tsvwg-ecn-l4s-id]).
The aim is that the default rules for encapsulating and decapsulating The aim is that the default rules for encapsulating and decapsulating
the ECN field are sufficiently generic that tunnels and subnets will the ECN field are sufficiently generic that tunnels and subnets will
encapsulate and decapsulate packets without regard to how algorithms encapsulate and decapsulate packets without regard to how algorithms
elsewhere are setting or interpreting the semantics of the ECN field. elsewhere are setting or interpreting the semantics of the ECN field.
[RFC6040] updates RFC 4774 to allow alternative encapsulation and [RFC6040] updates RFC 4774 to allow alternative encapsulation and
decapsulation behaviours to be defined for alternative ECN semantics. decapsulation behaviours to be defined for alternative ECN semantics.
However it reinforces the same point - that it is far preferable to However it reinforces the same point - that it is far preferable to
try to fit within the common ECN encapsulation and decapsulation try to fit within the common ECN encapsulation and decapsulation
behaviours, because expecting all lower layer technologies and behaviours, because expecting all lower layer technologies and
tunnels to be updated is likely to be completely impractical. tunnels to be updated is likely to be completely impractical.
Alternative semantics for the ECN field can be defined to depend on Alternative semantics for the ECN field can be defined to depend on
the traffic class indicated by the DSCP. Therefore correct the traffic class indicated by the DSCP. Therefore correct
propagation of congestion signals could depend on correct propagation propagation of congestion signals could depend on correct propagation
of the DSCP between the layers. For instance, if the meaning of the of the DSCP between the layers and along the path. For instance, if
ECN field depends on the DSCP (as in PCN or VoLTE) and if the outer the meaning of the ECN field depends on the DSCP (as in PCN or VoLTE)
DSCP is stripped on descapsulation, as in the pipe model of and if the outer DSCP is stripped on descapsulation, as in the pipe
[RFC2983], the special semantics of the ECN field will be lost. This model of [RFC2983], the special semantics of the ECN field would be
lost. Similarly, if the DSCP is changed at the boundary between
Diffserv domains, the special ECN semantics would also be lost. This
is an important implication of the localized scope of most Diffserv is an important implication of the localized scope of most Diffserv
arrangements. In this document, correct propagation of traffic class arrangements. In this document, correct propagation of traffic class
information is assumed, while what 'correct' means and how it is information is assumed, while what 'correct' means and how it is
achieved is covered elsewhere (e.g. RFC 2983) and is outside the achieved is covered elsewhere (e.g. RFC 2983) and is outside the
scope of the present document. scope of the present document.
The guidelines in this document do ensure that common encapsulation The guidelines in this document do ensure that common encapsulation
and decapsulation rules are sufficiently generic to cover cases where and decapsulation rules are sufficiently generic to cover cases where
ECT(1) is used instead of ECT(0) to identify alternative ECN ECT(1) is used instead of ECT(0) to identify alternative ECN
semantics (as in L4S [I-D.ietf-tsvwg-ecn-l4s-id]) and where ECN semantics (as in L4S [I-D.ietf-tsvwg-ecn-l4s-id]) and where ECN
skipping to change at page 6, line 47 skipping to change at page 7, line 18
the subnet wire protocol to be changed to add support for congestion the subnet wire protocol to be changed to add support for congestion
notification. For instance, the Feed-Up-and-Forward Mode notification. For instance, the Feed-Up-and-Forward Mode
(Section 3.2) and the Null Mode (Section 3.4) do not. Another way to (Section 3.2) and the Null Mode (Section 3.4) do not. Another way to
add congestion notification without consuming header space in the add congestion notification without consuming header space in the
subnet protocol might be to use a parallel control plane protocol. subnet protocol might be to use a parallel control plane protocol.
This document focuses on the congestion notification interface This document focuses on the congestion notification interface
between IP and lower layer or tunnel protocols that can encapsulate between IP and lower layer or tunnel protocols that can encapsulate
IP, where the term 'IP' includes v4 or v6, unicast, multicast or IP, where the term 'IP' includes v4 or v6, unicast, multicast or
anycast. However, it is likely that the guidelines will also be anycast. However, it is likely that the guidelines will also be
useful when a lower layer protocol or tunnel encapsulates itself useful when a lower layer protocol or tunnel encapsulates itself,
(e.g. Ethernet MAC in MAC [IEEE802.1Qah]) or when it encapsulates e.g. Ethernet MAC in MAC ([IEEE802.1Q]; previously 802.1ah) or when
other protocols. In the feed-backward mode, propagation of it encapsulates other protocols. In the feed-backward mode,
congestion signals for multicast and anycast packets is out-of-scope propagation of congestion signals for multicast and anycast packets
(because it would be so complicated that it is hoped no-one would is out-of-scope (because the complexity would make it unlikely to be
attempt such an abomination). attempted).
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] document are to be interpreted as described in RFC 2119 [RFC2119]
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
Further terminology used within this document: Further terminology used within this document:
skipping to change at page 8, line 4 skipping to change at page 8, line 23
Outer header: The header added to encapsulate a PDU. Outer header: The header added to encapsulate a PDU.
Inner header: The header encapsulated by the outer header. Inner header: The header encapsulated by the outer header.
Outgoing header: The header forwarded by the decapsulator. Outgoing header: The header forwarded by the decapsulator.
CE: Congestion Experienced [RFC3168] CE: Congestion Experienced [RFC3168]
ECT: ECN-Capable (L4) Transport [RFC3168] ECT: ECN-Capable (L4) Transport [RFC3168]
Not-ECT: Not ECN-Capable (L4) Transport [RFC3168] Not-ECT: Not ECN-Capable (L4) 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 [RFC8084]). Note the term "a nodes or transport circuit-breakers [RFC8084]). Note the term "a
function capable of controlling the load" deliberately includes a function capable of controlling the load" deliberately includes a
transport that doesn't actually control the load responsively but transport that does not actually control the load responsively but
ideally it ought to (e.g. a sending application without ideally it ought to (e.g. a sending application without congestion
congestion control that uses UDP). control that uses UDP).
ECN-PDU: A PDU that is part of a feedback loop within which all the
nodes that need to propagate explicit congestion notifications
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
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.
Not-ECN-PDU: A PDU that is part of a feedback-loop within which some ECN-PDU: A PDU at the IP layer or below with a capacity to signal
nodes necessary to propagate explicit congestion notifications congestion that is part of a congestion control feedback loop
back to the load regulator are not ECN-capable. within which all the nodes necessary to propagate the signal back
to the Load Regulator are capable of doing that propagation. An
IP packet with a 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 general term for a PDU at lower layers, as well
as at the IP layer.
Congestion Baseline: The location of the function on the path that Not-ECN-PDU: A PDU at the IP layer or below that is part of a
initialised the values of all congestion notification fields in a congestion control feedback-loop within which at least one node
sequence of packets, before any are set to the congestion necessary to propagate any explicit congestion notification
experienced (CE) codepoint if they experience congestion further signals back to the Load Regulator is not capable of doing that
downstream. Typically the original data source at layer-4. propagation.
3. Modes of Operation 3. 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
towards the egress within the lower layer then up and along the towards the egress within the lower layer then up and along the
layers towards the end-to-end destination at the transport layer. layers towards the end-to-end destination at the transport layer.
The following local optimisation is possible: The following local optimisation is possible:
Feed-Up-and-Forward: A lower layer switch feeds-up congestion Feed-Up-and-Forward: A lower layer switch feeds-up congestion
notification directly into the ECN field in the higher layer notification directly into the higher layer (e.g. into the ECN
(e.g. IP) header, irrespective of whether the node is at the field in the IP header), irrespective of whether the node is at
egress of a subnet. the egress of a subnet.
Feed-Backward: Nodes feed back congestion signals towards the Feed-Backward: Nodes feed back congestion signals towards the
ingress of the lower layer and (optionally) attempt to control ingress of the lower layer and (optionally) attempt to control
congestion within their own layer. congestion within their own layer.
Null: Nodes cannot experience congestion at the lower layer except Null: Nodes cannot experience congestion at the lower layer except
at ingress nodes (which are IP-aware or equivalently higher-layer- at ingress nodes (which are IP-aware or equivalently higher-layer-
aware). aware).
3.1. Feed-Forward-and-Up Mode 3.1. Feed-Forward-and-Up Mode
Like IP and MPLS, many subnet technologies are based on self- Like IP and MPLS, many subnet technologies are based on self-
contained protocol data units (PDUs) or frames sent unreliably. They contained protocol data units (PDUs) or frames sent unreliably. They
provide no feedback channel at the subnetwork layer, instead relying provide no feedback channel at the subnetwork layer, instead relying
on higher layers (e.g. TCP) to feed back loss signals. on higher layers (e.g. TCP) to feed back loss signals.
In these cases, ECN may best be supported by standardising explicit In these cases, ECN may best be supported by standardising explicit
notification of congestion into the lower layer protocol that carries notification of congestion into the lower layer protocol that carries
the data forwards. It will then also be necessary to define how the the data forwards. Then a specification is needed for how the egress
egress of the lower layer subnet propagates this explicit signal into of the lower layer subnet propagates this explicit signal into the
the forwarded upper layer (IP) header. It can then continue forwards forwarded upper layer (IP) header. This signal continues forwards
until it finally reaches the destination transport (at L4). Then until it finally reaches the destination transport (at L4). Then
typically the destination will feed this congestion notification back typically the destination will feed this congestion notification back
to the source transport using an end-to-end protocol (e.g. TCP). to the source transport using an end-to-end protocol (e.g. TCP).
This is the arrangement that has already been used to add ECN to IP- This is the arrangement that has already been used to add ECN to IP-
in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129]. in-IP tunnels [RFC6040], IP-in-MPLS and MPLS-in-MPLS [RFC5129].
This mode is illustrated in Figure 1. Along the middle of the This mode is illustrated in Figure 1. Along the middle of the
figure, layers 2, 3 and 4 of the protocol stack are shown, and one figure, layers 2, 3 and 4 of the protocol stack are shown, and one
packet is shown along the bottom as it progresses across the network packet is shown along the bottom as it progresses across the network
from source to destination, crossing two subnets connected by a from source to destination, crossing two subnets connected by a
skipping to change at page 10, line 28 skipping to change at page 10, line 46
__ _ _ _ __ _ _ _ __ _ _ __ _ _ _ __ _ _ _ __ _ _ _ __ _ _ __ _ _ _
| | | | | | | | |C| | | |C| | | |C|C| Data________\ | | | | | | | | |C| | | |C| | | |C|C| Data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) / |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| Packet (U) /
layer: 4 3 2A 4 3 2A 4 3 4 3 2B layer: 4 3 2A 4 3 2A 4 3 4 3 2B
header header
Figure 1: Feed-Forward-and-Up Mode Figure 1: Feed-Forward-and-Up Mode
Of course, modern networks are rarely as simple as this text-book Of course, modern networks are rarely as simple as this text-book
example, often involving multiple nested layers. For example, a 3GPP example, often involving multiple nested layers. For example, a 3GPP
mobile network may have two IP-in-IP (GTP) tunnels in series and an mobile network may have two IP-in-IP (GTP [GTPv1]) tunnels in series
MPLS backhaul between the base station and the first router. and an MPLS backhaul between the base station and the first router.
Nonetheless, the example illustrates the general idea of feeding Nonetheless, the example illustrates the general idea of feeding
congestion notification forward then upward whenever a header is congestion notification forward then upward whenever a header is
removed at the egress of a subnet. removed at the egress of a subnet.
Note that the FECN (forward ECN) bit in Frame Relay and the explicit Note that the FECN (forward ECN ) bit in Frame Relay [Buck00] and the
forward congestion indication (EFCI [ITU-T.I.371]) bit in ATM user explicit forward congestion indication (EFCI [ITU-T.I.371]) bit in
data cells follow a feed-forward pattern. However, in ATM, this ATM user data cells follow a feed-forward pattern. However, in ATM,
arrangement is only part of a feed-forward-and-backward pattern at this arrangement is only part of a feed-forward-and-backward pattern
the lower layer, not feed-forward-and-up out of the lower layer--the at the lower layer, not feed-forward-and-up out of the lower layer--
intention was never to interface to IP ECN at the subnet egress. To the intention was never to interface to IP ECN at the subnet egress.
our knowledge, Frame Relay FECN is solely used to detect where more To our knowledge, Frame Relay FECN is solely used to detect where
capacity should be provisioned [Buck00]. more capacity should be provisioned.
3.2. Feed-Up-and-Forward Mode 3.2. Feed-Up-and-Forward Mode
Ethernet is particularly difficult to extend incrementally to support Ethernet is particularly difficult to extend incrementally to support
explicit congestion notification. One way to support ECN in such explicit congestion notification. One way to support ECN in such
cases has been to use so called 'layer-3 switches'. These are cases has been to use so called 'layer-3 switches'. These are
Ethernet switches that bury into the Ethernet payload to find an IP Ethernet switches that dig into the Ethernet payload to find an IP
header and manipulate or act on certain IP fields (specifically header and manipulate or act on certain IP fields (specifically
Diffserv & ECN). For instance, in Data Center TCP [RFC8257], layer-3 Diffserv & ECN). For instance, in Data Center TCP [RFC8257], layer-3
switches are configured to mark the ECN field of the IP header within switches are configured to mark the ECN field of the IP header within
the Ethernet payload when their output buffer becomes congested. the Ethernet payload when their output buffer becomes congested.
With respect to switching, a layer-3 switch acts solely on the With respect to switching, a layer-3 switch acts solely on the
addresses in the Ethernet header; it doesn't use IP addresses, and it addresses in the Ethernet header; it does not use IP addresses, and
doesn't decrement the TTL field in the IP header. it does not decrement the TTL field in the IP header.
_ _ _ _ _ _
/_______ | | |C| ACK packet (V) /_______ | | |C| ACK packet (V)
\ |_|_|_| \ |_|_|_|
+---+ layer: 2 3 4 header +---+ +---+ layer: 2 3 4 header +---+
| <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4 | <|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Packet V <<<<<<<<<<<<<|<< |L4
| | +---+ | ^ | | | +---+ | ^ |
| | . . . >>>> Packet U >>>|>>>|>>> Packet U >>>>>>>>>>>>|>^ |L3 | | . . . >>>> Packet U >>>|>>>|>>> Packet U >>>>>>>>>>>>|>^ |L3
| | +--^+ +---+ | | +---+ +---+ | | | | +--^+ +---+ | | +---+ +---+ | |
| | | *| | | | | | | | | | |L2 | | | *| | | | | | | | | | |L2
skipping to change at page 12, line 36 skipping to change at page 13, line 33
\ |_| cell/frame (V) \ |_| cell/frame (V)
2 2
__ _ _ _ __ _ _ _ __ _ _ __ _ _ _ earlier __ _ _ _ __ _ _ _ __ _ _ __ _ _ _ earlier
| | | | | | | | | | | | | | | | | | | data________\ | | | | | | | | | | | | | | | | | | | data________\
|__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| packet (U) / |__|_|_|_| |__|_|_|_| |__|_|_| |__|_|_|_| packet (U) /
layer: 4 3 2 4 3 2 4 3 4 3 2 layer: 4 3 2 4 3 2 4 3 4 3 2
header header
Figure 3: Feed-Backward Mode Figure 3: Feed-Backward Mode
ATM's feed-backward approach doesn't fit well when layered beneath ATM's feed-backward approach does not fit well when layered beneath
IP's feed-forward approach--unless the initial data source is the IP's feed-forward approach--unless the initial data source is the
same node as the ATM ingress. Figure 3 shows the feed-backward same node as the ATM ingress. Figure 3 shows the feed-backward
approach being used in subnet H. If the final switch on the path is approach being used in subnet H. If the final switch on the path is
congested (*), it doesn't feed-forward any congestion indications on congested (*), it does not feed-forward any congestion indications on
packet (U). Instead it sends a control cell (V) back to the router packet (U). Instead it sends a control cell (V) back to the router
at the ATM ingress. at the ATM ingress.
However, the backward feedback doesn't reach the original data source However, the backward feedback does not reach the original data
directly because IP doesn't support backward feedback (and subnet G source directly because IP does not support backward feedback (and
is independent of subnet H). Instead, the router in the middle subnet G is independent of subnet H). Instead, the router in the
throttles down its sending rate but the original data sources don't middle throttles down its sending rate but the original data sources
reduce their rates. The resulting rate mismatch causes the middle don't reduce their rates. The resulting rate mismatch causes the
router's buffer at layer 3 to back up until it becomes congested, middle router's buffer at layer 3 to back up until it becomes
which it signals forwards on later data packets at layer 3 (e.g. congested, which it signals forwards on later data packets at layer 3
packet W). Note that the forward signal from the middle router is (e.g. packet W). Note that the forward signal from the middle router
not triggered directly by the backward signal. Rather, it is is not triggered directly by the backward signal. Rather, it is
triggered by congestion resulting from the middle router's mismatched triggered by congestion resulting from the middle router's mismatched
rate response to the backward signal. rate response to the backward signal.
In response to this later forward signalling, end-to-end feedback at In response to this later forward signalling, end-to-end feedback at
layer-4 finally completes the tortuous path of congestion indications layer-4 finally completes the tortuous path of congestion indications
back to the origin data source, as before. back to the origin data source, as before.
Quantized congestion notification (QCN [IEEE802.1Q]) would suffer
from similar problems if extended to multiple subnets. However, from
the start QCN was clearly characterized as solely applicable to a
single subnet (see Section 6).
3.4. Null Mode 3.4. Null Mode
Often link and physical layer resources are 'non-blocking' by design. Often link and physical layer resources are 'non-blocking' by design.
In these cases congestion notification may be implemented but it does In these cases congestion notification may be implemented but it does
not need to be deployed at the lower layer; ECN in IP would be not need to be deployed at the lower layer; ECN in IP would be
sufficient. sufficient.
A degenerate example is a point-to-point Ethernet link. Excess A degenerate example is a point-to-point Ethernet link. Excess
loading of the link merely causes the queue from the higher layer to loading of the link merely causes the queue from the higher layer to
back up, while the lower layer remains immune to congestion. Even a back up, while the lower layer remains immune to congestion. Even a
whole meshed subnetwork can be made immune to interior congestion by whole meshed subnetwork can be made immune to interior congestion by
limiting ingress capacity and sufficient sizing of interior links, limiting ingress capacity and sufficient sizing of interior links,
e.g. a non-blocking fat-tree network. An alternative to fat links e.g. a non-blocking fat-tree network [Leiserson85]. An alternative
near the root is numerous thin links with multi-path routing to to fat links near the root is numerous thin links with multi-path
ensure even worst-case patterns of load cannot congest any link, e.g. routing to ensure even worst-case patterns of load cannot congest any
a Clos network. link, e.g. a Clos network [Clos53].
4. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion 4. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
Notification Notification
Feed-forward-and-up is the mode already used for signalling ECN up Feed-forward-and-up is the mode already used for signalling ECN up
the layers through MPLS into IP [RFC5129] and through IP-in-IP the layers through MPLS into IP [RFC5129] and through IP-in-IP
tunnels [RFC6040], whether encapsulating with IPv4 [RFC2003], IPv6 tunnels [RFC6040], whether encapsulating with IPv4 [RFC2003], IPv6
[RFC2473] or IPsec [RFC4301]. These RFCs take a consistent approach [RFC2473] or IPsec [RFC4301]. These RFCs take a consistent approach
and the following guidelines are designed to ensure this consistency and the following guidelines are designed to ensure this consistency
continues as ECN support is added to other protocols that encapsulate continues as ECN support is added to other protocols that encapsulate
IP. The guidelines are also designed to ensure compliance with the IP. The guidelines are also designed to ensure compliance with the
more general best current practice for the design of alternate ECN more general best current practice for the design of alternate ECN
schemes given in [RFC4774]. schemes given in [RFC4774] and extended by [RFC8311].
The rest of this section is structured as follows: The rest of this section is structured as follows:
o Section 4.1 addresses the most straightforward cases, where o Section 4.1 addresses the most straightforward cases, where
[RFC6040] can be applied directly to add ECN to tunnels that are [RFC6040] can be applied directly to add ECN to tunnels that are
effectively IP-in-IP tunnels, but with shim header(s) between the effectively IP-in-IP tunnels, but with shim header(s) between the
IP headers. IP headers.
o The subsequent sections give guidelines for adding ECN to a subnet o The subsequent sections give guidelines for adding ECN to a subnet
technology that uses feed-forward-and-up mode like IP, but it is technology that uses feed-forward-and-up mode like IP, but it is
skipping to change at page 14, line 36 skipping to change at page 15, line 38
However, it is not always feasible or necessary to propagate ECN However, it is not always feasible or necessary to propagate ECN
between IP headers when separated by a shim. For instance, it might between IP headers when separated by a shim. For instance, it might
be too costly to dig to arbitrary depths to find an inner IP header, be too costly to dig to arbitrary depths to find an inner IP header,
there may be little or no congestion within the tunnel by design (see there may be little or no congestion within the tunnel by design (see
null mode in Section 3.4 above), or a legacy implementation might not null mode in Section 3.4 above), or a legacy implementation might not
support ECN. In cases where a tunnel does not support ECN, it is support ECN. In cases where a tunnel does not support ECN, it is
important that the ingress does not copy the ECN field from an inner important that the ingress does not copy the ECN field from an inner
IP header to an outer. Therefore section 4 of IP header to an outer. Therefore section 4 of
[I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to [I-D.ietf-tsvwg-rfc6040update-shim] requires network operators to
configure the ingress of a non-ECN tunnel so that it zeros the ECN configure the ingress of a tunnel that does not support ECN so that
field in the outer IP header. it zeros the ECN field in the outer IP header.
Nonetheless, in many cases it is feasible to propagate the ECN field Nonetheless, in many cases it is feasible to propagate the ECN field
between IP headers separated by shim header(s) and/or a L2 header. between IP headers separated by shim header(s) and/or a L2 header.
Particularly in the typical case when the outer IP header and the Particularly in the typical case when the outer IP header and the
shim(s) are added (or removed) as part of the same procedure. Even shim(s) are added (or removed) as part of the same procedure. Even
if the shim(s) encapsulate a L2 header, it is often possible to find if the shim(s) encapsulate a L2 header, it is often possible to find
an inner IP header within the L2 header and propagate ECN between an inner IP header within the L2 PDU and propagate ECN between that
that and the outer IP header. This can be thought of as a special and the outer IP header. This can be thought of as a special case of
case of the feed-up-and-forward mode (Section 3.2), so the guidelines the feed-up-and-forward mode (Section 3.2), so the guidelines for
for this mode apply (Section 5). this mode apply (Section 5).
Numerous shim protocols have been defined for IP tunnelling. More Numerous shim protocols have been defined for IP tunnelling. More
recent ones e.g. Generic UDP Encapsulation (GUE) recent ones e.g. Generic UDP Encapsulation (GUE)
[I-D.ietf-intarea-gue] and Geneve [I-D.ietf-nvo3-geneve] cite and [I-D.ietf-intarea-gue] and Geneve [I-D.ietf-nvo3-geneve] cite and
follow RFC 6040. And some earlier ones, e.g. CAPWAP [RFC5415] and follow RFC 6040. And some earlier ones, e.g. CAPWAP [RFC5415] and
LISP [RFC6830], cite RFC 3168, which is compatible with RFC 6040. LISP [RFC6830], cite RFC 3168, which is compatible with RFC 6040.
However, as Section 9.3 of RFC 3168 pointed out, ECN support needs to However, as Section 9.3 of RFC 3168 pointed out, ECN support needs to
be defined for many earlier shim-based tunnelling protocols, e.g. be defined for many earlier shim-based tunnelling protocols, e.g.
L2TPv2 [RFC2661], L2TPv3 [RFC3931], GRE [RFC2784], PPTP [RFC2637], L2TPv2 [RFC2661], L2TPv3 [RFC3931], GRE [RFC2784], PPTP [RFC2637],
GTP [GTPv1], [GTPv1-U], [GTPv2-C] and Teredo [RFC4380] as well as GTP [GTPv1], [GTPv1-U], [GTPv2-C] and Teredo [RFC4380] as well as
some recent ones, e.g. VXLAN [RFC7348], NVGRE [RFC7637] and NSH some recent ones, e.g. VXLAN [RFC7348], NVGRE [RFC7637] and NSH
[RFC8300]. [RFC8300].
All these IP-based encapsulations can be updated in one shot by All these IP-based encapsulations can be updated in one shot by
simple reference to RFC 6040. However, it would not be appropriate simple reference to RFC 6040. However, it would not be appropriate
to update all these protocols from within the present guidance to update all these protocols from within the present guidance
document. Instead a companion specification document. Instead a companion specification
[I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has [I-D.ietf-tsvwg-rfc6040update-shim] has been prepared that has the
sufficient standards track status to update standards track appropriate standards track status to update standards track
protocols. For those that are not under IETF change control protocols. For those that are not under IETF change control
[I-D.ietf-tsvwg-rfc6040update-shim] can only recommend that the [I-D.ietf-tsvwg-rfc6040update-shim] can only recommend that the
relevant body updates them. relevant body updates them.
4.2. Wire Protocol Design: Indication of ECN Support 4.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
skipping to change at page 15, line 46 skipping to change at page 16, line 50
are destined for legacy layer-4 transport implementations that are destined for legacy layer-4 transport implementations that
will not understand ECN, and will not understand ECN, and
2. SHOULD NOT apply explicit congestion notifications to PDUs if the 2. SHOULD NOT apply explicit congestion notifications to PDUs if the
egress of the subnet might not propagate congestion notifications egress of the subnet might not propagate congestion notifications
onward into the higher layer. onward into the higher layer.
We use the term ECN-PDUs for a PDU on a feedback loop that will We use the term ECN-PDUs for a PDU on a feedback loop that will
propagate congestion notification properly because it meets both propagate congestion notification properly because it meets both
the above criteria. And a Not-ECN-PDU is a PDU on a feedback the above criteria. And a Not-ECN-PDU is a PDU on a feedback
loop that does not meet both criteria, and will therefore not loop that does not meet at least one of the criteria, and will
propagate congestion notification properly. A corollary of the therefore not propagate congestion notification properly. A
above is that a lower layer congestion notification protocol: corollary of the above is that a lower layer congestion
notification protocol:
3. SHOULD be able to distinguish ECN-PDUs from Not-ECN-PDUs. 3. SHOULD be able to distinguish ECN-PDUs from Not-ECN-PDUs.
Note that there is no need for all interior nodes within a subnet to Note that there is no need for all interior nodes within a subnet to
be able to mark congestion explicitly. A mix of ECN and drop signals be able to mark congestion explicitly. A mix of ECN and drop signals
from different nodes is fine. However, if _any_ interior nodes might from different nodes is fine. However, if _any_ interior nodes might
generate ECN markings, guideline 2 above says that all relevant generate ECN markings, guideline 2 above says that all relevant
egress node(s) SHOULD be able to propagate those markings up to the egress node(s) SHOULD be able to propagate those markings up to the
higher layer. higher layer.
skipping to change at page 17, line 9 skipping to change at page 18, line 16
strategy because MPLS is targeted solely at professional operators, strategy because MPLS is targeted solely at professional operators,
who can be expected to ensure that a whole subnetwork is consistently who can be expected to ensure that a whole subnetwork is consistently
configured. This strategy might not be appropriate for other link configured. This strategy might not be appropriate for other link
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 Provider Backbone Bridges (PBB
(PBB). [IEEE802.1Q]; previously 802.1ah).
ECN support in TRILL [I-D.ietf-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
be propagated to IP as ECN whenever ECN logic has been implemented, be propagated to IP as ECN whenever ECN logic has been implemented,
or as drop otherwise. or as drop otherwise.
QCN [IEEE802.1Qau] is not intended to extend beyond a single subnet, QCN [IEEE802.1Q] is not intended to extend beyond a single subnet, or
or to interoperate with ECN. Nonetheless, the way QCN indicates to to interoperate with ECN. Nonetheless, the way QCN indicates to
lower layer devices that the end-points will not understand QCN lower layer devices that the end-points will not understand QCN
provides another example that a lower layer protocol designer might provides another example that a lower layer protocol designer might
be able to mimic for their scenario. An operator can define certain be able to mimic for their scenario. An operator can define certain
802.1p classes of service to indicate non-QCN frames and an ingress 802.1p classes of service to indicate non-QCN frames and an ingress
bridge is required to map arriving not-QCN-capable IP packets to one bridge is required to map arriving not-QCN-capable IP packets to one
of these non-QCN 802.1p classes. of these non-QCN 802.1p classes.
4.3. Encapsulation Guidelines 4.3. Encapsulation Guidelines
This section is intended to guide the redesign of any node that This section is intended to guide the redesign of any node that
skipping to change at page 18, line 10 skipping to change at page 19, line 14
congestion notification added to the outer header across the congestion notification added to the outer header across the
subnet. This is necessary in addition to checking that an subnet. This is necessary in addition to checking that an
incoming PDU indicates an ECN-capable (L4) transport. Examples incoming PDU indicates an ECN-capable (L4) transport. Examples
of how this guarantee might be provided include: of how this guarantee might be provided include:
* by configuration (e.g. if any label switches in a domain * by configuration (e.g. if any label switches in a domain
support ECN marking, [RFC5129] requires all egress nodes to support ECN marking, [RFC5129] requires all egress nodes to
have been configured to propagate ECN) have been configured to propagate ECN)
* by the ingress explicitly checking that the egress propagates * by the ingress explicitly checking that the egress propagates
ECN (e.g. TRILL uses IS-IS to check path capabilities before ECN (e.g. an early attempt to add ECN support to TRILL used
using critical options [RFC7780]) IS-IS to check path capabilities before adding ECN extension
flags to each frame [RFC7780]).
* by inherent design of the protocol (e.g. by encoding ECN * by inherent design of the protocol (e.g. by encoding ECN
marking on the outer header in such a way that a legacy egress marking on the outer header in such a way that a legacy egress
that does not understand ECN will consider the PDU corrupt and that does not understand ECN will consider the PDU corrupt or
discard it, thus at least propagating a form of congestion invalid and discard it, thus at least propagating a form of
signal). congestion signal).
2. Egress Fails Capability Check: If the ingress cannot guarantee 2. Egress Fails Capability Check: If the ingress cannot guarantee
that the egress will propagate congestion notification, the that the egress will propagate congestion notification, the
ingress SHOULD disable ECN when it forwards the PDU at the lower ingress SHOULD disable ECN at the lower layer when it forwards
layer. An example of how the ingress might disable ECN at the the PDU. An example of how the ingress might disable ECN at the
lower layer would be by setting the outer header of the PDU to lower layer would be by setting the outer header of the PDU to
identify it as a Not-ECN-PDU, assuming the subnet technology identify it as a Not-ECN-PDU, assuming the subnet technology
supports such a concept. supports such a concept.
3. Standard Congestion Monitoring Baseline: Once the ingress to a 3. Standard Congestion Monitoring Baseline: Once the ingress to a
subnet has established that the egress will correctly propagate subnet has established that the egress will correctly propagate
ECN, on encapsulation it SHOULD encode the same level of ECN, on encapsulation it SHOULD encode the same level of
congestion in outer headers as is arriving in incoming headers. congestion in outer headers as is arriving in incoming headers.
For example it might copy any incoming congestion notification For example it might copy any incoming congestion notification
into the outer header of the lower layer protocol. into the outer header of the lower layer protocol.
This ensures that all outer headers reflect congestion This ensures that bulk congestion monitoring of outer headers
accumulated along the whole upstream path since the Load (e.g. by a network management node monitoring ECN in passing
Regulator, not just since the ingress of the subnet. A node that frames) will measure congestion accumulated along the whole
is not the Load Regulator SHOULD NOT re-initialise the level of upstream path - since the Load Regulator not just since the
CE markings in the outer to zero. ingress of the subnet. A node that is not the Load Regulator
SHOULD NOT re-initialize the level of CE markings in the outer to
zero.
This guideline is intended to ensure that any bulk congestion It would still also be possible to measure congestion introduced
monitoring of outer headers (e.g. by a network management node across one subnet (or tunnel) by subtracting the level of CE
monitoring ECN in passing frames) is most meaningful. For markings on inner headers from that on outer headers (see
instance, if an operator measures CE in 0.4% of passing outer Appendix C of [RFC6040]). For example:
headers, this information is only useful if the operator knows
where the proportion of CE markings was last initialised to 0%
(the Congestion Baseline). Such monitoring information will not
be useful if some subnet ingress nodes reset all outer CE
markings while others copy incoming CE markings into the outer.
Most information can be extracted if the Congestion Baseline is * If this guideline has been followed and if the level of CE
standardised at the node that is regulating the load (the Load markings is 0.4% on the outer and 0.1% on the inner, 0.4%
Regulator--typically the data source). Then the operator can congestion has been introduced across all the networks since
measure both congestion since the Load Regulator, and congestion the load regulator, and 0.3% (= 0.4% - 0.1%) has been
since the subnet ingress. The latter might be measurable by introduced since the ingress to the current subnet (or
subtracting the level of CE markings on inner headers from that tunnel);
on outer headers (see Appendix C of [RFC6040]).
* Without this guideline, if the subnet ingress had re-
initialized the outer congestion level to zero, the outer and
inner would measure 0.1% and 0.3%. It would still be possible
to infer that the congestion introduced since the Load
Regulator was 0.4% (= 0.1% + 0.3%). But only if the
monitoring system somehow knows whether the subnet ingress re-
initialized the congestion level.
As long as subnet and tunnel technologies use the standard
congestion monitoring baseline in this guideline, monitoring
systems will know to use the former approach, rather than having
to "somehow know" which approach to use.
4.4. Decapsulation Guidelines 4.4. Decapsulation Guidelines
This section is intended to guide the redesign of any node that This section is intended to guide the redesign of any node that
decapsulates IP from within a lower layer header when adding native decapsulates IP from within a lower layer header when adding native
ECN support to the lower layer protocol. It reflects the approaches ECN support to the lower layer protocol. It reflects the approaches
used in [RFC6040] and in [RFC5129]. Therefore IP-in-IP tunnels or used in [RFC6040] and in [RFC5129]. Therefore IP-in-IP tunnels or
IP-in-MPLS or MPLS-in-MPLS encapsulations that already comply with IP-in-MPLS or MPLS-in-MPLS encapsulations that already comply with
[RFC6040] or [RFC5129] will already satisfy this guidance. [RFC6040] or [RFC5129] will already satisfy this guidance.
skipping to change at page 19, line 46 skipping to change at page 21, line 14
* If the outer is an ECN-PDU that carries no indication of * If the outer is an ECN-PDU that carries no indication of
congestion or a Not-ECN-PDU the PDU SHOULD be forwarded, but congestion or a Not-ECN-PDU the PDU SHOULD be forwarded, but
still as a Not-ECN-PDU. still as a Not-ECN-PDU.
2. If the outer header does not support explicit congestion 2. If the outer header does not support explicit congestion
notification (a Not-ECN-PDU), but the inner header does (an ECN- notification (a Not-ECN-PDU), but the inner header does (an ECN-
PDU), the inner header SHOULD be forwarded unchanged. PDU), the inner header SHOULD be forwarded unchanged.
3. In some lower layer protocols congestion may be signalled as a 3. In some lower layer protocols congestion may be signalled as a
numerical level, such as in the control frames of quantised numerical level, such as in the control frames of quantized
congestion notification [IEEE802.1Qau]. If such a multi-bit congestion notification (QCN [IEEE802.1Q]). If such a multi-bit
encoding encapsulates an ECN-capable IP data packet, a function encoding encapsulates an ECN-capable IP data packet, a function
will be needed to convert the quantised congestion level into the will be needed to convert the quantized congestion level into the
frequency of congestion markings in outgoing IP packets. frequency of congestion markings in outgoing IP packets.
4. Congestion indications might be encoded by a severity level. For 4. Congestion indications might be encoded by a severity level. For
instance increasing levels of congestion might be encoded by instance increasing levels of congestion might be encoded by
numerically increasing indications, e.g. pre-congestion numerically increasing indications, e.g. pre-congestion
notification (PCN) can be encoded in each PDU at three severity notification (PCN) can be encoded in each PDU at three severity
levels in IP or MPLS [RFC6660] and the default encapsulation and levels in IP or MPLS [RFC6660] and the default encapsulation and
decapsulation rules [RFC6040] are compatible with this decapsulation rules [RFC6040] are compatible with this
interpretation of the ECN field. interpretation of the ECN field.
skipping to change at page 21, line 21 skipping to change at page 22, line 39
whether this optimisation is enabled. whether this optimisation is enabled.
When ECN support is added to a subnet technology, consideration When ECN support is added to a subnet technology, consideration
SHOULD be given to a similar optimisation between subnets in sequence SHOULD be given to a similar optimisation between subnets in sequence
if they all use the same technology. if they all use the same technology.
4.6. Reframing and Congestion Markings 4.6. Reframing and Congestion Markings
The guidance in this section is worded in terms of framing The guidance in this section is worded in terms of framing
boundaries, but it applies equally whether the protocol data units boundaries, but it applies equally whether the protocol data units
are frames, cells or packets. are frames, cells, packets or fragments.
Where framing boundaries are different between two layers, congestion Where an AQM marks the ECN field of IP packets as they queue into a
indications SHOULD be propagated on the basis that a congestion layer-2 link, there will be no problem with framing boundaries,
indication on a PDU applies to all the octets in the PDU. On because the ECN markings would be applied directly to IP packets.
average, an encapsulator or decapsulator SHOULD approximately The guidance in this section is only applicable where an ECN
capability is being added to a layer-2 protocol so that layer-2
frames can be ECN-marked by an AQM at layer-2. This would only be
necessary where AQM will be applied at pure layer-2 nodes (without
IP-awareness). Where framing boundaries do not necessarily align
with packet boundaries, the following guidance will be needed. It
explains how to propagate ECN markings from layer-2 frame headers
when they are stripped off and IP PDUs with different boundaries are
reassembled for forwarding.
Congestion indications SHOULD be propagated on the basis that a
congestion indication on a PDU applies to all the octets in the PDU.
On average, an encapsulator or decapsulator SHOULD approximately
preserve the number of marked octets arriving and leaving (counting preserve the number of marked octets arriving and leaving (counting
the size of inner headers, but not added encapsulating headers). the size of inner headers, but not encapsulating headers that are
being added or stripped).
The next departing frame SHOULD be immediately marked even if only The next departing frame SHOULD be immediately marked even if only
enough incoming marked octets have arrived for part of the departing enough incoming marked octets have arrived for part of the departing
frame. This ensures that any outstanding congestion marked octets frame. This ensures that any outstanding congestion marked octets
are propagated immediately, rather than held back waiting for a frame are propagated immediately, rather than held back waiting for a frame
no bigger than the outstanding marked octets--which might involve a no bigger than the outstanding marked octets--which might involve a
long wait. long wait.
For instance, an algorithm for marking departing frames could For instance, an algorithm for marking departing frames could
maintain a counter representing the balance of arriving marked octets maintain a counter representing the balance of arriving marked octets
skipping to change at page 22, line 11 skipping to change at page 23, line 41
o are encapsulated in Ethernet headers, which have no support for o are encapsulated in Ethernet headers, which have no support for
ECN; ECN;
o are forwarded by the eNode-B (base station) of a 3GPP radio access o are forwarded by the eNode-B (base station) of a 3GPP radio access
network, which is required to apply ECN marking during congestion, network, which is required to apply ECN marking during congestion,
[LTE-RA], [UTRAN], but the Packet Data Convergence Protocol (PDCP) [LTE-RA], [UTRAN], but the Packet Data Convergence Protocol (PDCP)
that encapsulates the IP header over the radio access has no that encapsulates the IP header over the radio access has no
support for ECN. support for ECN.
This guidance also generalises to encapsulation by other subnet This guidance also generalizes to encapsulation by other subnet
technologies with no native support for explicit congestion technologies with no native support for explicit congestion
notification at the lower layer, but with support for finding and notification at the lower layer, but with support for finding and
processing an IP header. It is unlikely to be applicable or processing an IP header. It is unlikely to be applicable or
necessary for IP-in-IP encapsulation, where feed-forward-and-up mode necessary for IP-in-IP encapsulation, where feed-forward-and-up mode
based on [RFC6040] would be more appropriate. based on [RFC6040] would be more appropriate.
Marking the IP header while switching at layer-2 (by using a layer-3 Marking the IP header while switching at layer-2 (by using a layer-3
switch) or while forwarding in a radio access network seems to switch) or while forwarding in a radio access network seems to
represent a layering violation. However, it can be considered as a represent a layering violation. However, it can be considered as a
benign optimisation if the guidelines below are followed. Feed-up- benign optimisation if the guidelines below are followed. Feed-up-
skipping to change at page 22, line 36 skipping to change at page 24, line 18
encapsulated by lower layer protocols encapsulated by lower layer protocols
o Link-layer encryption might be in use, making the layer-2 payload o Link-layer encryption might be in use, making the layer-2 payload
inaccessible inaccessible
o Many Ethernet switches do not have 'layer-3 switch' capabilities o Many Ethernet switches do not have 'layer-3 switch' capabilities
so they cannot read or modify an IP payload so they cannot read or modify an IP payload
o It might be costly to find an IP header (v4 or v6) when it may be o It might be costly to find an IP header (v4 or v6) when it may be
encapsulated by more than one lower layer header, e.g. Ethernet encapsulated by more than one lower layer header, e.g. Ethernet
MAC in MAC [IEEE802.1Qah]. MAC in MAC ([IEEE802.1Q]; previously 802.1ah).
Nonetheless, configuring lower layer equipment to look for an ECN Nonetheless, configuring lower layer equipment to look for an ECN
field in an encapsulated IP header is a useful optimisation. If the field in an encapsulated IP header is a useful optimisation. If the
implementation follows the guidelines below, this optimisation does implementation follows the guidelines below, this optimisation does
not have to be confined to a controlled environment such as within a not have to be confined to a controlled environment such as within a
data centre; it could usefully be applied on any network--even if the data centre; it could usefully be applied on any network--even if the
operator is not sure whether the above issues will never apply: operator is not sure whether the above issues will never apply:
1. If a native lower-layer congestion notification mechanism exists 1. If a native lower-layer congestion notification mechanism exists
for a subnet technology, it is safe to mix feed-up-and-forward for a subnet technology, it is safe to mix feed-up-and-forward
with feed-forward-and-up on other switches in the same subnet. with feed-forward-and-up on other switches in the same subnet.
However, it will generally be more efficient to use the native However, it will generally be more efficient to use the native
mechanism. mechanism.
2. The depth of the search for an IP header SHOULD be limited. If 2. The depth of the search for an IP header SHOULD be limited. If
an IP header is not found soon enough, or an unrecognised or an IP header is not found soon enough, or an unrecognized or
unreadable header is encountered, the switch SHOULD resort to an unreadable header is encountered, the switch SHOULD resort to an
alternative means of signalling congestion (e.g. drop, or the alternative means of signalling congestion (e.g. drop, or the
native lower layer mechanism if available). native lower layer mechanism if available).
3. It is sufficient to use the first IP header found in the stack; 3. It is sufficient to use the first IP header found in the stack;
the egress of the relevant tunnel can propagate congestion the egress of the relevant tunnel can propagate congestion
notification upwards to any more deeply encapsulated IP headers notification upwards to any more deeply encapsulated IP headers
later. later.
6. Feed-Backward Mode: Guidelines for Adding Congestion Notification 6. Feed-Backward Mode: Guidelines for Adding Congestion Notification
It can be seen from Section 3.3 that congestion notification in a It can be seen from Section 3.3 that congestion notification in a
subnet using feed-backward mode has generally not been designed to be subnet using feed-backward mode has generally not been designed to be
directly coupled with IP layer congestion notification. The subnet directly coupled with IP layer congestion notification. The subnet
attempts to minimise congestion internally, and if the incoming load attempts to minimize congestion internally, and if the incoming load
at the ingress exceeds the capacity somewhere through the subnet, the at the ingress exceeds the capacity somewhere through the subnet, the
layer 3 buffer into the ingress backs up. Thus, a feed-backward mode layer 3 buffer into the ingress backs up. Thus, a feed-backward mode
subnet is in some sense similar to a null mode subnet, in that there subnet is in some sense similar to a null mode subnet, in that there
is no need for any direct interaction between the subnet and higher is no need for any direct interaction between the subnet and higher
layer congestion notification. Therefore no detailed protocol design layer congestion notification. Therefore no detailed protocol design
guidelines are appropriate. Nonetheless, a more general guideline is guidelines are appropriate. Nonetheless, a more general guideline is
appropriate: appropriate:
A subnetwork technology intended to eventually interface to IP A subnetwork technology intended to eventually interface to IP
SHOULD NOT be designed using only the feed-backward mode, which is SHOULD NOT be designed using only the feed-backward mode, which is
skipping to change at page 24, line 5 skipping to change at page 25, line 35
In the early days of TCP/IP, a similar feed-backward approach was In the early days of TCP/IP, a similar feed-backward approach was
tried for explicit congestion signalling, using source-quench (SQ) tried for explicit congestion signalling, using source-quench (SQ)
ICMP control packets. However, SQ fell out of favour and is now ICMP control packets. However, SQ fell out of favour and is now
formally deprecated [RFC6633]. The main problem was that it is hard formally deprecated [RFC6633]. The main problem was that it is hard
for a data source to tell the difference between a spoofed SQ message for a data source to tell the difference between a spoofed SQ message
and a quench request from a genuine buffer on the path. It is also and a quench request from a genuine buffer on the path. It is also
hard for a lower layer buffer to address an SQ message to the hard for a lower layer buffer to address an SQ message to the
original source port number, which may be buried within many layers original source port number, which may be buried within many layers
of headers, and possibly encrypted. of headers, and possibly encrypted.
Quantised congestion notification (QCN--also known as backward QCN (also known as backward congestion notification, BCN; see
congestion notification or BCN) [IEEE802.1Qau] uses a feed-backward Sections 30--33 of [IEEE802.1Q]; previously known as 802.1Qau) uses a
mode structurally similar to ATM's relative rate mechanism. However, feed-backward mode structurally similar to ATM's relative rate
QCN confines its applicability to scenarios such as some data centres mechanism. However, QCN confines its applicability to scenarios such
where all endpoints are directly attached by the same Ethernet as some data centres where all endpoints are directly attached by the
technology. If a QCN subnet were later connected into a wider IP- same Ethernet technology. If a QCN subnet were later connected into
based internetwork (e.g. when attempting to interconnect multiple a wider IP-based internetwork (e.g. when attempting to interconnect
data centres) it would suffer the inefficiency shown in Figure 3. multiple data centres) it would suffer the inefficiency shown in
Figure 3.
7. IANA Considerations (to be removed by RFC Editor) 7. IANA Considerations (to be removed by RFC Editor)
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
If a lower layer wire protocol is redesigned to include explicit If a lower layer wire protocol is redesigned to include explicit
congestion signalling in-band in the protocol header, care SHOULD be congestion signalling in-band in the protocol header, care SHOULD be
take to ensure that the field used is specified as mutable during take to ensure that the field used is specified as mutable during
skipping to change at page 25, line 22 skipping to change at page 27, line 7
o A wide range of tunnelling protocols including those with various o A wide range of tunnelling protocols including those with various
forms of shim header between two IP headers, possibly also forms of shim header between two IP headers, possibly also
separated by a L2 header; separated by a L2 header;
o A wide range of subnet technologies, particularly those that work o A wide range of subnet technologies, particularly those that work
in the same 'feed-forward-and-up' mode that is used to support ECN in the same 'feed-forward-and-up' mode that is used to support ECN
in IP and MPLS. in IP and MPLS.
Guidelines have been defined for supporting propagation of ECN Guidelines have been defined for supporting propagation of ECN
between Ethernet and IP on so-called Layer-3 Ethernet switches, using between Ethernet and IP on so-called Layer-3 Ethernet switches, using
a 'feed-up-an-forward' mode. This approach could enable other subnet a 'feed-up-and-forward' mode. This approach could enable other
technologies to pass ECN signals into the IP layer, even if they do subnet technologies to pass ECN signals into the IP layer, even if
not support ECN natively. they do not support ECN natively.
Finally, attempting to add ECN to a subnet technology in feed- Finally, attempting to add ECN to a subnet technology in feed-
backward mode is deprecated except in special cases, due to its backward mode is deprecated except in special cases, due to its
likely sluggish response to congestion. likely sluggish response to congestion.
10. Acknowledgements 10. Acknowledgements
Thanks to Gorry Fairhurst for extensive reviews. Thanks also to the Thanks to Gorry Fairhurst and David Black for extensive reviews.
following reviewers: Richard Scheffenegger, Ingemar Johansson, Piers Thanks also to the following reviewers: Joe Touch, Andrew McGregor,
O'Hanlon and Michael Welzl, who pointed out that lower layer Richard Scheffenegger, Ingemar Johansson, Piers O'Hanlon and Michael
congestion notification signals may have different semantics to those Welzl, who pointed out that lower layer congestion notification
in IP. Thanks are also due to the tsvwg chairs, TSV ADs and IETF signals may have different semantics to those in IP. Thanks are also
liaison people such as Eric Gray, Dan Romascanu and Gonzalo Camarillo due to the tsvwg chairs, TSV ADs and IETF liaison people such as Eric
for helping with the liaisons with the IEEE and 3GPP. And thanks to Gray, Dan Romascanu and Gonzalo Camarillo for helping with the
Georg Mayer and particularly to Erik Guttman for the extensive search liaisons with the IEEE and 3GPP. And thanks to Georg Mayer and
and categorisation of any 3GPP specifications that cite ECN particularly to Erik Guttman for the extensive search and
categorisation of any 3GPP specifications that cite ECN
specifications. specifications.
Bob Briscoe was part-funded by the European Community under its Bob Briscoe was part-funded by the European Community under its
Seventh Framework Programme through the Trilogy project (ICT-216372) Seventh Framework Programme through the Trilogy project (ICT-216372)
for initial drafts and through the Reducing Internet Transport for initial drafts and through the Reducing Internet Transport
Latency (RITE) project (ICT-317700) subsequently. The views Latency (RITE) project (ICT-317700) subsequently. The views
expressed here are solely those of the authors. expressed here are solely those of the authors.
11. Comments Solicited 11. Comments Solicited
skipping to change at page 27, line 5 skipping to change at page 28, line 38
12.2. Informative References 12.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.
[Clos53] Clos, C., "A Study of Non-Blocking Switching Networks",
Bell Systems Technical Journal 32(2):406--424, March 1953.
[GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp [GTPv1] 3GPP, "GPRS Tunnelling Protocol (GTP) across the Gn and Gp
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.
skipping to change at page 27, line 41 skipping to change at page 29, line 30
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
id-06 (work in progress), March 2019. id-06 (work in progress), March 2019.
[I-D.ietf-tsvwg-rfc6040update-shim] [I-D.ietf-tsvwg-rfc6040update-shim]
Briscoe, B., "Propagating Explicit Congestion Notification Briscoe, B., "Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim", draft-ietf- Across IP Tunnel Headers Separated by a Shim", draft-ietf-
tsvwg-rfc6040update-shim-07 (work in progress), November tsvwg-rfc6040update-shim-08 (work in progress), March
2018. 2019.
[IEEE802.1Qah] [IEEE802.1Q]
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.1Q-2018, July
August 2008, 2018, <https://ieeexplore.ieee.org/document/8403927>.
<http://www.ieee802.org/1/pages/802.1ah.html>.
(Access Controlled link within page)
[IEEE802.1Qau]
Finn, N., Ed., "IEEE Standard for Local and Metropolitan
Area Networks--Virtual Bridged Local Area Networks -
Amendment 13: Congestion Notification", IEEE Std 802.1Qau-
2010, March 2010, <http://ieeexplore.ieee.org/xpl/
mostRecentIssue.jsp?punumber=5454061>.
(Access Controlled link within page)
[ITU-T.I.371] [ITU-T.I.371]
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>.
[Leiserson85]
Leiserson, C., "Fat-trees: universal networks for
hardware-efficient supercomputing", IEEE Transactions on
Computers 34(10):892-901, October 1985.
[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, R., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <https://www.rfc-editor.org/info/rfc1323>. 1992, <https://www.rfc-editor.org/info/rfc1323>.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
skipping to change at page 32, line 7 skipping to change at page 33, line 7
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311, Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018, DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>. <https://www.rfc-editor.org/info/rfc8311>.
[UTRAN] 3GPP, "UTRAN Overall Description", Technical [UTRAN] 3GPP, "UTRAN Overall Description", Technical
Specification TS 25.401. Specification TS 25.401.
Appendix A. Changes in This Version (to be removed by RFC Editor) Appendix A. Changes in This Version (to be removed by RFC Editor)
From ietf-12 to ietf-13
* Following 3rd tsvwg WGLC:
+ Formalized update to RFC 3819 in its own subsection (1.1)
and referred to it in the abstract
+ Scope: Clarified that the specification of alternative ECN
semantics using ECT(1) was not in RFC 4774, but rather in
RFC 8311, and that the problem with using a DSCP to indicate
alternative semantics has issues at domain boundaries as
well as tunnels.
+ Terminology: tighted up definitions of ECN-PDU and Not-ECN-
PDU, and removed definition of Congestion Baseline, given it
was only used once.
+ Mentioned QCN where feed-backward is first introduced (S.3),
referring forward to where it is discussed more deeply
(S.4).
+ Clarified that IS-IS solution to adding ECN support to TRILL
was not pursued
+ Completely rewrote the rationale for the guideline about a
Standard Congestion Monitoring Baseline, to focus on
standardization of the otherwise unknown scenario used,
rather than the relative usefulness of the info in each
approach
+ Explained the re-framing problem better and added
fragmentation as another possible cause of the problem
+ Acknowledged new reviewers
+ Updated references, replaced citations of 802.1Qau and
802.1ah with rolled up 802.1Q, and added citations of Fat
trees and Clos Networks
+ Numerous other editorial improvements
From ietf-11 to ietf-12 From ietf-11 to ietf-12
* Updated references * Updated references
From ietf-10 to ietf-11 From ietf-10 to ietf-11
* Removed short section (was 3) 'Guidelines for All Cases' * Removed short section (was 3) 'Guidelines for All Cases'
because it was out of scope, being covered by RFC 4774. because it was out of scope, being covered by RFC 4774.
Expanded the Scope section (1.2) to explain all this. Expanded the Scope section (1.2) to explain all this.
Explained that the default encap/decap rules already support Explained that the default encap/decap rules already support
certain alternative semantics, particularly all three of the certain alternative semantics, particularly all three of the
alternative semantics for ECT(1): equivalent to ECT(0) , higher alternative semantics for ECT(1): equivalent to ECT(0) , higher
severity than ECT(0), and unmarked but implying different severity than ECT(0), and unmarked but implying different
marking semantics from ECT(0). marking semantics from ECT(0).
* Clarified why the QCN example was being given even though not * Clarified why the QCN example was being given even though not
skipping to change at page 36, line 30 skipping to change at page 38, line 24
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
Broadcom Corporation Broadcom Corporation (retired)
5025 Keane Drive CA
Carmichael, CA 95608
USA USA
EMail: pthaler@broadcom.com
 End of changes. 74 change blocks. 
213 lines changed or deleted 300 lines changed or added

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