draft-ietf-tsvwg-ecn-encap-guidelines-10.txt   draft-ietf-tsvwg-ecn-encap-guidelines-11.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft Simula Research Laboratory 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 19, 2018 P. Thaler Expires: May 16, 2019 P. Thaler
Broadcom Corporation Broadcom Corporation
March 18, 2018 November 12, 2018
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-10 draft-ietf-tsvwg-ecn-encap-guidelines-11
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 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 19, 2018. This Internet-Draft will expire on May 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Guidelines in All Cases . . . . . . . . . . . . . . . . . . . 7 3. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 8
4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 8 3.1. Feed-Forward-and-Up Mode . . . . . . . . . . . . . . . . 9
4.1. Feed-Forward-and-Up Mode . . . . . . . . . . . . . . . . 8 3.2. Feed-Up-and-Forward Mode . . . . . . . . . . . . . . . . 10
4.2. Feed-Up-and-Forward Mode . . . . . . . . . . . . . . . . 10 3.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 11
4.3. Feed-Backward Mode . . . . . . . . . . . . . . . . . . . 11 3.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Null Mode . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
5. Feed-Forward-and-Up Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 13 Notification . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. IP-in-IP Tunnels with Shim Headers . . . . . . . . . . . 14 4.1. IP-in-IP Tunnels with Shim Headers . . . . . . . . . . . 14
5.2. Wire Protocol Design: Indication of ECN Support . . . . . 15 4.2. Wire Protocol Design: Indication of ECN Support . . . . . 15
5.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 17 4.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 17
5.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 19 4.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 19
5.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 20 4.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 20
5.6. Reframing and Congestion Markings . . . . . . . . . . . . 21 4.6. Reframing and Congestion Markings . . . . . . . . . . . . 21
6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 21 Notification . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Feed-Backward Mode: Guidelines for Adding Congestion 6. Feed-Backward Mode: Guidelines for Adding Congestion
Notification . . . . . . . . . . . . . . . . . . . . . . . . 23 Notification . . . . . . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations (to be removed by RFC Editor) . . . . . . 24 7. IANA Considerations (to be removed by RFC Editor) . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
12. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 25 11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Changes in This Version (to be removed by RFC Appendix A. Changes in This Version (to be removed by RFC
Editor) . . . . . . . . . . . . . . . . . . . . . . 31 Editor) . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The benefits of Explicit Congestion Notification (ECN) described The benefits of Explicit Congestion Notification (ECN) described in
below can only be fully realised if support for ECN is added to the [RFC8087] and summarized below can only be fully realised if support
relevant subnetwork technology, as well as to IP. When a lower layer for ECN is added to the relevant subnetwork technology, as well as to
buffer drops a packet obviously it does not just drop at that layer; IP. When a lower layer buffer drops a packet obviously it does not
the packet disappears from all layers. In contrast, when a lower just drop at that layer; the packet disappears from all layers. In
layer marks a packet with ECN, the marking needs to be explicitly contrast, when a lower layer marks a packet with ECN, the marking
propagated up the layers. The same is true if a buffer marks the needs to be explicitly propagated up the layers. The same is true if
outer header of a packet that encapsulates inner tunnelled headers. a buffer marks the outer header of a packet that encapsulates inner
Forwarding ECN is not as straightforward as other headers because it tunnelled headers. Forwarding ECN is not as straightforward as other
has to be assumed ECN may be only partially deployed. If an egress headers because it has to be assumed ECN may be only partially
at any layer is not ECN-aware, or if the ultimate receiver or sender deployed. If an egress at any layer is not ECN-aware, or if the
is not ECN-aware, congestion needs to be indicated by dropping a ultimate receiver or sender is not ECN-aware, congestion needs to be
packet, not marking it. 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 equipment can signal congestion explicitly and it will
propagate consistently into encapsulated (higher layer) headers, 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
skipping to change at page 3, line 52 skipping to change at page 3, line 52
is because drop involves a trade-off between sending a timely is because drop involves a trade-off between sending a timely
signal and trying to avoid impairment, whereas ECN is solely a signal and trying to avoid impairment, whereas ECN is solely a
signal not an impairment, so there is no harm triggering it signal not an impairment, so there is no harm triggering it
earlier. earlier.
Some lower layer technologies (e.g. MPLS, Ethernet) are used to form Some lower layer technologies (e.g. MPLS, Ethernet) are used to form
subnetworks with IP-aware nodes only at the edges. These networks subnetworks with IP-aware nodes only at the edges. These networks
are often sized so that it is rare for interior queues to overflow. are often sized so that it is rare for interior queues to overflow.
However, until recently this was more due to the inability of TCP to However, until recently this was more due to the inability of TCP to
saturate the links. For many years, fixes such as window scaling saturate the links. For many years, fixes such as window scaling
[RFC1323] proved hard to deploy. And the Reno variant of TCP has [RFC1323] (now [RFC7323]) proved hard to deploy. And the Reno
remained in widespread use despite its inability to scale to high variant of TCP has remained in widespread use despite its inability
flow rates. However, now that modern operating systems are finally to scale to high flow rates. However, now that modern operating
capable of saturating interior links, even the buffers of well- systems are finally capable of saturating interior links, even the
provisioned interior switches will need to signal episodes of buffers of well-provisioned interior switches will need to signal
queuing. episodes of queuing.
Propagation of ECN is defined for MPLS [RFC5129], and is being Propagation of ECN is defined for MPLS [RFC5129], and is being
defined for TRILL [RFC7780], [I-D.ietf-trill-ecn-support], but it defined for TRILL [RFC7780], [I-D.ietf-trill-ecn-support], but it
remains to be defined for a number of other subnetwork technologies. remains to be defined for a number of other subnetwork technologies.
Similarly, ECN propagation is yet to be defined for many tunnelling Similarly, ECN propagation is yet to be defined for many tunnelling
protocols. [RFC6040] defines how ECN should be propagated for IP-in- protocols. [RFC6040] defines how ECN should be propagated for IP-in-
IPv4 [RFC2003], IP-in-IPv6 [RFC2473] and IPsec [RFC4301] tunnels, but IPv4 [RFC2003], IP-in-IPv6 [RFC2473] and IPsec [RFC4301] tunnels, but
there are numerous other tunnelling protocols with a shim and/or a there are numerous other tunnelling protocols with a shim and/or a
layer 2 header between two IP headers (v4 or v6). Some address ECN layer 2 header between two IP headers (v4 or v6). Some address ECN
skipping to change at page 4, line 32 skipping to change at page 4, line 32
[I-D.ietf-tsvwg-rfc6040update-shim] updates those existing IP-shim- [I-D.ietf-tsvwg-rfc6040update-shim] updates those existing IP-shim-
(L2)-IP protocols that are under IETF change control and still widely (L2)-IP protocols that are under IETF change control and still widely
used. used.
Incremental deployment is the most delicate aspect when adding Incremental deployment is the most delicate aspect when adding
support for ECN. The original ECN protocol in IP [RFC3168] was support for ECN. The original ECN protocol in IP [RFC3168] was
carefully designed so that a congested buffer would not mark a packet carefully designed so that a congested buffer would not mark a packet
(rather than drop it) unless both source and destination hosts were (rather than drop it) unless both source and destination hosts were
ECN-capable. Otherwise its congestion markings would never be ECN-capable. Otherwise its congestion markings would never be
detected and congestion would just build up further. However, to detected and congestion would just build up further. However, to
support congestion marking below the IP layer, it is not sufficient support congestion marking below the IP layer or within tunnels, it
to only check that the two transport layer end-points support ECN; is not sufficient to only check that the two layer 4 transport end-
correct operation also depends on the decapsulator at each subnet points support ECN; correct operation also depends on the
egress faithfully propagating congestion notifications to the higher decapsulator at each subnet or tunnel egress faithfully propagating
layer. Otherwise, a legacy decapsulator might silently fail to congestion notifications to the higher layer. Otherwise, a legacy
propagate any ECN signals from the outer to the forwarded header. decapsulator might silently fail to propagate any ECN signals from
Then the lost signals would never be detected and again congestion the outer to the forwarded header. Then the lost signals would never
would build up further. The guidelines given later require protocol be detected and again congestion would build up further. The
designers to carefully consider incremental deployment, and suggest guidelines given later require protocol designers to carefully
various safe approaches for different circumstances. consider incremental deployment, and suggest various safe approaches
for different circumstances.
Of course, the IETF does not have standards authority over every link Of course, the IETF does not have standards authority over every link
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 term 'SHOULD' or 'SHOULD NOT' are often Therefore, the capitalised 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 to contradict 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 4, backward; and null mode. These modes are described in Section 3,
then in the following sections separate guidelines are given for each then in the subsequent sections separate guidelines are given for
mode. each mode.
This document updates the advice to subnetwork designers about ECN in This document updates the advice to subnetwork designers about ECN in
Section 13 of [RFC3819]. Section 13 of [RFC3819].
1.1. Scope 1.1. Scope
This document only concerns wire protocol processing of explicit This document only concerns wire protocol processing of explicit
notification of congestion and 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 (algorithm issues should be independent of the layer the response, because algorithm issues should be independent of the layer
algorithm operates in). the algorithm operates in.
The question of congestion notification signals with different The default ECN semantics are described in [RFC3168] and updated by
semantics to those of ECN in IP is touched on in a couple of specific [RFC8311]. Also the guidelines for AQM designers [RFC7567] clarify
cases (e.g. QCN [IEEE802.1Qau]) and with schemes with multiple the semantics of both drop and ECN signals from AQM algorithms.
severity levels such as PCN [RFC6660]). However, no attempt is made [RFC4774] is the appropriate best current practice specification of
to give guidelines about schemes with different semantics that are how algorithms with alternative semantics for the ECN field can be
yet to be invented. partitioned from Internet traffic that uses the default ECN
semantics, for example:
The semantics of congestion signals can be relative to the traffic o by using the ECN field in combination with a Diffserv codepoint
class. Therefore correct propagation of congestion signals could such as in PCN [RFC6660], Voice over 3G [UTRAN] or Voice over LTE
depend on correct propagation of any traffic class field between the (VoLTE) [LTE-RA];
layers. In this document, correct propagation of traffic class
o or by using the ECT(1) codepoint of the ECN field to indicate
alternative semantics such as for the experimental Low Latency Low
Loss Scalable throughput (L4S) service [RFC8311]
[I-D.ietf-tsvwg-ecn-l4s-id]).
The aim is that the default rules for encapsulating and decapsulating
the ECN field are sufficiently generic that tunnels and subnets will
encapsulate and decapsulate packets without regard to how algorithms
elsewhere are setting or interpreting the semantics of the ECN field.
[RFC6040] updates RFC 4774 to allow alternative encapsulation and
decapsulation behaviours to be defined for alternative ECN semantics.
However it reinforces the same point - that it is far preferable to
try to fit within the common ECN encapsulation and decapsulation
behaviours, because expecting all lower layer technologies and
tunnels to be updated is likely to be completely impractical.
Alternative semantics for the ECN field can be defined to depend on
the traffic class indicated by the DSCP. Therefore correct
propagation of congestion signals could depend on correct propagation
of the DSCP between the layers. For instance, if the meaning of the
ECN field depends on the DSCP (as in PCN or VoLTE) and if the outer
DSCP is stripped on descapsulation, as in the pipe model of
[RFC2983], the special semantics of the ECN field will be lost. This
is an important implication of the localized scope of most Diffserv
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. [RFC2983]) 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.
Note that these guidelines do not require the subnet wire protocol to The guidelines in this document do ensure that common encapsulation
be changed to accommodate congestion notification. For instance, the and decapsulation rules are sufficiently generic to cover cases where
Feed-Up-and-Forward Mode (Section 4.2) and the Null Mode ECT(1) is used instead of ECT(0) to identify alternative ECN
(Section 4.4) do not. Another way to add congestion notification semantics (as in L4S [I-D.ietf-tsvwg-ecn-l4s-id]) and where ECN
without consuming header space in the subnet protocol might be to use marking algorithms use ECT(1) to encode 3 severity levels into the
a parallel control plane protocol. ECN field (e.g. PCN [RFC6660]) rather than the default of 2. All
these different semantics for the ECN field work because it has been
possible to define common default decapsulation rules that allow for
all cases.
Note that the guidelines in this document do not necessarily require
the subnet wire protocol to be changed to add support for congestion
notification. For instance, the Feed-Up-and-Forward Mode
(Section 3.2) and the Null Mode (Section 3.4) do not. Another way to
add congestion notification without consuming header space in the
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 protocols that can encapsulate IP, where between IP and lower layer or tunnel protocols that can encapsulate
the term 'IP' includes v4 or v6, unicast, multicast or anycast. IP, where the term 'IP' includes v4 or v6, unicast, multicast or
However, it is likely that the guidelines will also be useful when a anycast. However, it is likely that the guidelines will also be
lower layer protocol or tunnel encapsulates itself (e.g. Ethernet useful when a lower layer protocol or tunnel encapsulates itself
MAC in MAC [IEEE802.1Qah]) or when it encapsulates other protocols. (e.g. Ethernet MAC in MAC [IEEE802.1Qah]) or when it encapsulates
In the feed-backward mode, propagation of congestion signals for other protocols. In the feed-backward mode, propagation of
multicast and anycast packets is out-of-scope (because it would be so congestion signals for multicast and anycast packets is out-of-scope
complicated that it is hoped no-one would attempt such an (because it would be so complicated that it is hoped no-one would
abomination). attempt such an abomination).
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.
Further terminology used within this document: Further terminology used within this document:
Protocol data unit (PDU): Information that is delivered as a unit Protocol data unit (PDU): Information that is delivered as a unit
among peer entities of a layered network consisting of protocol among peer entities of a layered network consisting of protocol
control information (typically a header) and possibly user data control information (typically a header) and possibly user data
(payload) of that layer. The scope of this document includes (payload) of that layer. The scope of this document includes
layer 2 and layer 3 networks, where the PDU is respectively termed layer 2 and layer 3 networks, where the PDU is respectively termed
a frame or a packet (or a cell in ATM). PDU is a general term for a frame or a packet (or a cell in ATM). PDU is a general term for
any of these. This definition also includes a payload with a shim any of these. This definition also includes a payload with a shim
skipping to change at page 7, line 13 skipping to change at page 7, line 51
Incoming header: The header of an arriving PDU before encapsulation. Incoming header: The header of an arriving PDU before encapsulation.
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 Transport [RFC3168] ECT: ECN-Capable (L4) Transport [RFC3168]
Not-ECT: Not ECN-Capable (L4) Transport [RFC3168]
Not-ECT: Not ECN-Capable Transport [RFC3168]
Load Regulator: For each flow of PDUs, the transport function that Load Regulator: For each flow of PDUs, the transport function that
is capable of controlling the data rate. Typically located at the is capable of controlling the data rate. Typically located at the
data source, but in-path nodes can regulate load in some data source, but in-path nodes can regulate load in some
congestion control arrangements (e.g. admission control, policing congestion control arrangements (e.g. admission control, policing
nodes or transport circuit-breakers [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 doesn't 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 control that uses UDP). congestion control that uses UDP).
skipping to change at page 7, line 44 skipping to change at page 8, line 33
Not-ECN-PDU: A PDU that is part of a feedback-loop within which some Not-ECN-PDU: A PDU that is part of a feedback-loop within which some
nodes necessary to propagate explicit congestion notifications nodes necessary to propagate explicit congestion notifications
back to the load regulator are not ECN-capable. back to the load regulator are not ECN-capable.
Congestion Baseline: The location of the function on the path that Congestion Baseline: The location of the function on the path that
initialised the values of all congestion notification fields in a initialised the values of all congestion notification fields in a
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. Modes of Operation
RFC 3168 specifies that the ECN field in the IP header is intended to
be marked by active queue management algorithms. Any congestion
notification from an algorithm that does not conform to the
recommendations in [RFC7567] MUST NOT be 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
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.
skipping to change at page 8, line 31 skipping to change at page 9, line 13
egress of a subnet. 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).
4.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. It will then also be necessary to define how the
egress of the lower layer subnet propagates this explicit signal into egress of the lower layer subnet propagates this explicit signal into
skipping to change at page 10, line 14 skipping to change at page 10, line 43
Note that the FECN (forward ECN) bit in Frame Relay and the explicit Note that the FECN (forward ECN) bit in Frame Relay and the explicit
forward congestion indication (EFCI [ITU-T.I.371]) bit in ATM user forward congestion indication (EFCI [ITU-T.I.371]) bit in ATM user
data cells follow a feed-forward pattern. However, in ATM, this data cells follow a feed-forward pattern. However, in ATM, this
arrangement is only part of a feed-forward-and-backward pattern at arrangement is only part of a feed-forward-and-backward pattern at
the lower layer, not feed-forward-and-up out of the lower layer--the the lower layer, not feed-forward-and-up out of the lower layer--the
intention was never to interface to IP ECN at the subnet egress. To intention was never to interface to IP ECN at the subnet egress. To
our knowledge, Frame Relay FECN is solely used to detect where more our knowledge, Frame Relay FECN is solely used to detect where more
capacity should be provisioned [Buck00]. capacity should be provisioned [Buck00].
4.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 bury 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 [DCTCP], 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 doesn't use IP addresses, and it
doesn't decrement the TTL field in the IP header. doesn't 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 +---+
skipping to change at page 11, line 7 skipping to change at page 11, line 36
Figure 2: Feed-Up-and-Forward Mode Figure 2: Feed-Up-and-Forward Mode
By comparing Figure 2 with Figure 1, it can be seen that subnet E By comparing Figure 2 with Figure 1, it can be seen that subnet E
(perhaps a subnet of layer-3 Ethernet switches) works in feed-up-and- (perhaps a subnet of layer-3 Ethernet switches) works in feed-up-and-
forward mode by notifying congestion directly into L3 at the point of forward mode by notifying congestion directly into L3 at the point of
congestion, even though the congested switch does not otherwise act congestion, even though the congested switch does not otherwise act
at L3. In this example, the technology in subnet F (e.g. MPLS) does at L3. In this example, the technology in subnet F (e.g. MPLS) does
support ECN natively, so when the router adds the layer-2 header it support ECN natively, so when the router adds the layer-2 header it
copies the ECN marking from L3 to L2 as well. copies the ECN marking from L3 to L2 as well.
4.3. Feed-Backward Mode 3.3. Feed-Backward Mode
In some layer 2 technologies, explicit congestion notification has In some layer 2 technologies, explicit congestion notification has
been defined for use internally within the subnet with its own been defined for use internally within the subnet with its own
feedback and load regulation, but typically the interface with IP for feedback and load regulation, but typically the interface with IP for
ECN has not been defined. ECN has not been defined.
For instance, for the available bit-rate (ABR) service in ATM, the For instance, for the available bit-rate (ABR) service in ATM, the
relative rate mechanism was one of the more popular mechanisms for relative rate mechanism was one of the more popular mechanisms for
managing traffic, tending to supersede earlier designs. In this managing traffic, tending to supersede earlier designs. In this
approach ATM switches send special resource management (RM) cells in approach ATM switches send special resource management (RM) cells in
skipping to change at page 13, line 9 skipping to change at page 13, line 11
which it signals forwards on later data packets at layer 3 (e.g. which it signals forwards on later data packets at layer 3 (e.g.
packet W). Note that the forward signal from the middle router is packet W). Note that the forward signal from the middle router is
not triggered directly by the backward signal. Rather, it 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.
4.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. An alternative to fat links
near the root is numerous thin links with multi-path routing to near the root is numerous thin links with multi-path routing to
ensure even worst-case patterns of load cannot congest any link, e.g. ensure even worst-case patterns of load cannot congest any link, e.g.
a Clos network. a Clos network.
5. 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].
The rest of this section is structured as follows: The rest of this section is structured as follows:
o Section 5.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
not so similar to IP that [RFC6040] rules can be applied directly. not so similar to IP that [RFC6040] rules can be applied directly.
Specifically: Specifically:
* Sections 5.2, 5.3 and 5.4 respectively address how to add ECN * Sections 4.2, 4.3 and 4.4 respectively address how to add ECN
support to the wire protocol and to the encapsulators and support to the wire protocol and to the encapsulators and
decapsulators at the ingress and egress of the subnet. decapsulators at the ingress and egress of the subnet.
* Section 5.5 deals with the special, but common, case of * Section 4.5 deals with the special, but common, case of
sequences of tunnels or subnets that all use the same sequences of tunnels or subnets that all use the same
technology technology
* Section 5.6 deals with the question of reframing when IP * Section 4.6 deals with the question of reframing when IP
packets do not map 1:1 into lower layer frames. packets do not map 1:1 into lower layer frames.
5.1. IP-in-IP Tunnels with Shim Headers 4.1. IP-in-IP Tunnels with Shim Headers
A common pattern for many tunnelling protocols is to encapsulate an A common pattern for many tunnelling protocols is to encapsulate an
inner IP header with shim header(s) then an outer IP header. A shim inner IP header with shim header(s) then an outer IP header. A shim
header is defined as one that is not sufficient alone to forward the header is defined as one that is not sufficient alone to forward the
packet as an outer header. Another common pattern is for a shim to packet as an outer header. Another common pattern is for a shim to
encapsulate a layer 2 (L2) header, which in turn encapsulates (or encapsulate a layer 2 (L2) header, which in turn encapsulates (or
might encapsulate) an IP header. [I-D.ietf-tsvwg-rfc6040update-shim] might encapsulate) an IP header. [I-D.ietf-tsvwg-rfc6040update-shim]
clarifies that RFC 6040 is just as applicable when there are shim(s) clarifies that RFC 6040 is just as applicable when there are shim(s)
and possibly a L2 header between two IP headers. and possibly a L2 header between two IP headers.
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 4.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 non-ECN tunnel so that it zeros the ECN
field in the outer IP header. 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 header and propagate ECN between
that and the outer IP header. This can be thought of as a special that and the outer IP header. This can be thought of as a special
case of the feed-up-and-forward mode (Section 4.2), so the guidelines case of the feed-up-and-forward mode (Section 3.2), so the guidelines
for this mode apply (Section 6). for 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],
skipping to change at page 15, line 24 skipping to change at page 15, line 24
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
sufficient standards track status to update standards track sufficient 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.
5.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
encapsulations that already comply with [RFC6040] or [RFC5129] will encapsulations that already comply with [RFC6040] or [RFC5129] will
already satisfy this guidance. already satisfy this guidance.
A lower layer (or subnet) congestion notification system: A lower layer (or subnet) congestion notification system:
skipping to change at page 16, line 27 skipping to change at page 16, line 27
The mechanism a lower layer uses to distinguish the ECN-capability of The mechanism a lower layer uses to distinguish the ECN-capability of
PDUs need not mimic that of IP. The above guidelines merely say that PDUs need not mimic that of IP. The above guidelines merely say that
the lower layer system, as a whole, should achieve the same outcome. the lower layer system, as a whole, should achieve the same outcome.
For instance, ECN-capable feedback loops might use PDUs that are For instance, ECN-capable feedback loops might use PDUs that are
identified by a particular set of labels or tags. Alternatively, identified by a particular set of labels or tags. Alternatively,
logical link protocols that use flow state might determine whether a logical link protocols that use flow state might determine whether a
PDU can be congestion marked by checking for ECN-support in the flow PDU can be congestion marked by checking for ECN-support in the flow
state. Other protocols might depend on out-of-band control signals. state. Other protocols might depend on out-of-band control signals.
The per-domain checking of ECN support in MPLS [RFC5129] is a good The per-domain checking of ECN support in MPLS [RFC5129] is a good
example of a way to avoid sending congestion markings to transports example of a way to avoid sending congestion markings to L4
that will not understand them, without using any header space in the transports that will not understand them, without using any header
subnet protocol. space in the subnet protocol.
In MPLS, header space is extremely limited, therefore RFC5129 does In MPLS, header space is extremely limited, therefore RFC5129 does
not provide a field in the MPLS header to indicate whether the PDU is not provide a field in the MPLS header to indicate whether the PDU is
an ECN-PDU or a Not-ECN-PDU. Instead, interior nodes in a domain are an ECN-PDU or a Not-ECN-PDU. Instead, interior nodes in a domain are
allowed to set explicit congestion indications without checking allowed to set explicit congestion indications without checking
whether the PDU is destined for a transport that will understand whether the PDU is destined for a L4 transport that will understand
them. Nonetheless, this is made safe by requiring that the network them. Nonetheless, this is made safe by requiring that the network
operator upgrades all decapsulating edges of a whole domain at once, operator upgrades all decapsulating edges of a whole domain at once,
as soon as even one switch within the domain is configured to mark as soon as even one switch within the domain is configured to mark
rather than drop during congestion. Therefore, any edge node that rather than drop during congestion. Therefore, any edge node that
might decapsulate a packet will be capable of checking whether the might decapsulate a packet will be capable of checking whether the
higher layer transport is ECN-capable. When decapsulating a CE- higher layer transport is ECN-capable. When decapsulating a CE-
marked packet, if the decapsulator discovers that the higher layer marked packet, if the decapsulator discovers that the higher layer
(inner header) indicates the transport is not ECN-capable, it drops (inner header) indicates the transport is not ECN-capable, it drops
the packet--effectively on behalf of the earlier congested node (see the packet--effectively on behalf of the earlier congested node (see
Decapsulation Guideline 1 in Section 5.4). Decapsulation Guideline 1 in Section 4.4).
It was only appropriate to define such an incremental deployment It was only appropriate to define such an incremental deployment
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,
skipping to change at page 17, line 26 skipping to change at page 17, line 26
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] provides another example of how to indicate to QCN [IEEE802.1Qau] is not intended to extend beyond a single subnet,
lower layer devices that the end-points will not understand ECN. An or to interoperate with ECN. Nonetheless, the way QCN indicates to
operator can define certain 802.1p classes of service to indicate lower layer devices that the end-points will not understand QCN
non-QCN frames and an ingress bridge is required to map arriving not- provides another example that a lower layer protocol designer might
QCN-capable IP packets to one of these non-QCN 802.1p classes. 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
bridge is required to map arriving not-QCN-capable IP packets to one
of these non-QCN 802.1p classes.
5.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
encapsulates IP with a lower layer header when adding native ECN encapsulates IP with a lower layer header when adding native ECN
support to the lower layer protocol. It reflects the approaches used support to the lower layer protocol. It reflects the approaches used
in [RFC6040] and in [RFC5129]. Therefore IP-in-IP tunnels or IP-in- in [RFC6040] and in [RFC5129]. Therefore IP-in-IP tunnels or IP-in-
MPLS or MPLS-in-MPLS encapsulations that already comply with 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.
1. Egress Capability Check: A subnet ingress needs to be sure that 1. Egress Capability Check: A subnet ingress needs to be sure that
the corresponding egress of a subnet will propagate any the corresponding egress of a subnet will propagate any
skipping to change at page 19, line 5 skipping to change at page 19, line 9
markings while others copy incoming CE markings into the outer. markings while others copy incoming CE markings into the outer.
Most information can be extracted if the Congestion Baseline is Most information can be extracted if the Congestion Baseline is
standardised at the node that is regulating the load (the Load standardised at the node that is regulating the load (the Load
Regulator--typically the data source). Then the operator can Regulator--typically the data source). Then the operator can
measure both congestion since the Load Regulator, and congestion measure both congestion since the Load Regulator, and congestion
since the subnet ingress. The latter might be measurable by since the subnet ingress. The latter might be measurable by
subtracting the level of CE markings on inner headers from that subtracting the level of CE markings on inner headers from that
on outer headers (see Appendix C of [RFC6040]). on outer headers (see Appendix C of [RFC6040]).
5.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.
A subnet egress SHOULD NOT simply copy congestion notification from A subnet egress SHOULD NOT simply copy congestion notification from
outer headers to the forwarded header. It SHOULD calculate the outer headers to the forwarded header. It SHOULD calculate the
skipping to change at page 19, line 48 skipping to change at page 20, line 5
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 quantised
congestion notification [IEEE802.1Qau]. If such a multi-bit congestion notification [IEEE802.1Qau]. 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 quantised congestion level into the
frequency of congestion markings in outgoing IP packets. frequency of congestion markings in outgoing IP packets.
4. Congestion indications may 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]. levels in IP or MPLS [RFC6660] and the default encapsulation and
decapsulation rules [RFC6040] are compatible with this
interpretation of the ECN field.
If the arriving inner header is an ECN-PDU, where the inner and If the arriving inner header is an ECN-PDU, where the inner and
outer headers carry indications of congestion of different outer headers carry indications of congestion of different
severity, the more severe indication SHOULD be forwarded in severity, the more severe indication SHOULD be forwarded in
preference to the less severe. preference to the less severe.
5. The inner and outer headers might carry a combination of 5. The inner and outer headers might carry a combination of
congestion notification fields that should not be possible given congestion notification fields that should not be possible given
any currently used protocol transitions. For instance, if any currently used protocol transitions. For instance, if
Encapsulation Guideline 3 in Section 5.3 had been followed, it Encapsulation Guideline 3 in Section 4.3 had been followed, it
should not be possible to have a less severe indication of should not be possible to have a less severe indication of
congestion in the outer than in the inner. It MAY be appropriate congestion in the outer than in the inner. It MAY be appropriate
to log unexpected combinations of headers and possibly raise an to log unexpected combinations of headers and possibly raise an
alarm. alarm.
If a safe outgoing codepoint can be defined for such a PDU, the If a safe outgoing codepoint can be defined for such a PDU, the
PDU SHOULD be forwarded rather than dropped. Some implementers PDU SHOULD be forwarded rather than dropped. Some implementers
discard PDUs with currently unused combinations of headers just discard PDUs with currently unused combinations of headers just
in case they represent an attack. However, an approach using in case they represent an attack. However, an approach using
alarms and policy-mediated drop is preferable to hard-coded drop, alarms and policy-mediated drop is preferable to hard-coded drop,
so that operators can keep track of possible attacks but so that operators can keep track of possible attacks but
currently unused combinations are not precluded from future use currently unused combinations are not precluded from future use
through new standards actions. through new standards actions.
5.5. Sequences of Similar Tunnels or Subnets 4.5. Sequences of Similar Tunnels or Subnets
In some deployments, particularly in 3GPP networks, an IP packet may In some deployments, particularly in 3GPP networks, an IP packet may
traverse two or more IP-in-IP tunnels in sequence that all use traverse two or more IP-in-IP tunnels in sequence that all use
identical technology (e.g. GTP). identical technology (e.g. GTP).
In such cases, it would be sufficient for every encapsulation and In such cases, it would be sufficient for every encapsulation and
decapsulation in the chain to comply with RFC 6040. Alternatively, decapsulation in the chain to comply with RFC 6040. Alternatively,
as an optimisation, a node that decapsulates a packet and immediately as an optimisation, a node that decapsulates a packet and immediately
re-encapsulates it for the next tunnel MAY copy the incoming outer re-encapsulates it for the next tunnel MAY copy the incoming outer
ECN field directly to the outgoing outer and the incoming inner ECN ECN field directly to the outgoing outer and the incoming inner ECN
skipping to change at page 21, line 9 skipping to change at page 21, line 17
monitor the whole sequence of tunnels, but only if the above monitor the whole sequence of tunnels, but only if the above
optimisation were used consistently along the sequence of tunnels, in optimisation were used consistently along the sequence of tunnels, in
order to make it appear as a single tunnel. Therefore, tunnel order to make it appear as a single tunnel. Therefore, tunnel
endpoint implementations SHOULD allow the operator to configure endpoint implementations SHOULD allow the operator to configure
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.
5.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 or packets.
Where framing boundaries are different between two layers, congestion Where framing boundaries are different between two layers, congestion
indications SHOULD be propagated on the basis that a congestion indications SHOULD be propagated on the basis that a congestion
indication on a PDU applies to all the octets in the PDU. On indication on a PDU applies to all the octets in the PDU. On
average, an encapsulator or decapsulator SHOULD approximately 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
skipping to change at page 21, line 36 skipping to change at page 21, line 44
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
minus departing marked octets. It adds the size of every marked minus departing marked octets. It adds the size of every marked
frame that arrives and if the counter is positive it marks the next frame that arrives and if the counter is positive it marks the next
frame to depart and subtracts its size from the counter. This will frame to depart and subtracts its size from the counter. This will
often leave a negative remainder in the counter, which is deliberate. often leave a negative remainder in the counter, which is deliberate.
6. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion 5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
Notification Notification
The guidance in this section is applicable, for example, when IP The guidance in this section is applicable, for example, when IP
packets: packets:
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,
skipping to change at page 23, line 5 skipping to change at page 23, line 13
an IP header is not found soon enough, or an unrecognised or an IP header is not found soon enough, or an unrecognised 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.
7. Feed-Backward Mode: Guidelines for Adding Congestion Notification 6. Feed-Backward Mode: Guidelines for Adding Congestion Notification
It can be seen from Section 4.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 minimise 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:
skipping to change at page 23, line 51 skipping to change at page 24, line 12
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 Quantised congestion notification (QCN--also known as backward
congestion notification or BCN) [IEEE802.1Qau] uses a feed-backward congestion notification or BCN) [IEEE802.1Qau] uses a feed-backward
mode structurally similar to ATM's relative rate mechanism. However, mode structurally similar to ATM's relative rate mechanism. However,
QCN confines its applicability to scenarios such as some data centres QCN confines its applicability to scenarios such as some data centres
where all endpoints are directly attached by the same Ethernet where all endpoints are directly attached by the same Ethernet
technology. If a QCN subnet were later connected into a wider IP- technology. If a QCN subnet were later connected into a wider IP-
based internetwork (e.g. when attempting to interconnect multiple based internetwork (e.g. when attempting to interconnect multiple
data centres) it would suffer the inefficiency shown Figure 3. data centres) it would suffer the inefficiency shown in Figure 3.
8. 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.
9. 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
transit. Otherwise interior nodes signalling congestion would transit. Otherwise interior nodes signalling congestion would
invalidate any authentication protocol applied to the lower layer invalidate any authentication protocol applied to the lower layer
header--by altering a header field that had been assumed as header--by altering a header field that had been assumed as
immutable. immutable.
The redesign of protocols that encapsulate IP in order to propagate The redesign of protocols that encapsulate IP in order to propagate
congestion signals between layers raises potential signal integrity congestion signals between layers raises potential signal integrity
concerns. Experimental or proposed approaches exist for assuring the concerns. Experimental or proposed approaches exist for assuring the
end-to-end integrity of in-band congestion signals, e.g.: end-to-end integrity of in-band congestion signals, e.g.:
o Congestion exposure (ConEx ) for networks to audit that their o Congestion exposure (ConEx ) for networks to audit that their
congestion signals are not being suppressed by other networks or congestion signals are not being suppressed by other networks or
by receivers, and for networks to police that senders are by receivers, and for networks to police that senders are
responding sufficiently to the signals, irrespective of the responding sufficiently to the signals, irrespective of the L4
transport protocol used [RFC7713]. transport protocol used [RFC7713].
o A test for a sender to detect whether a network or the receiver is o A test for a sender to detect whether a network or the receiver is
suppressing congestion signals (for example see suppressing congestion signals (for example see 2nd para of
[I-D.moncaster-tcpm-rcv-cheat]). Section 20.2 of [RFC3168]).
Given these end-to-end approaches are already being specified, it Given these end-to-end approaches are already being specified, it
would make little sense to attempt to design hop-by-hop congestion would make little sense to attempt to design hop-by-hop congestion
signal integrity into a new lower layer protocol, because end-to-end signal integrity into a new lower layer protocol, because end-to-end
integrity inherently achieves hop-by-hop integrity. integrity inherently achieves hop-by-hop integrity.
10. Conclusions Section 6 gives vulnerability to spoofing as one of the reasons for
deprecating feed-backward mode.
9. Conclusions
Following the guidance in the document enables ECN support to be Following the guidance in the document enables ECN support to be
extended to numerous protocols that encapsulate IP (v4 & v6) in a extended to numerous protocols that encapsulate IP (v4 & v6) in a
consistent way, so that IP continues to fulfil its role as an end-to- consistent way, so that IP continues to fulfil its role as an end-to-
end interoperability layer. This includes: end interoperability layer. This includes:
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;
skipping to change at page 25, line 15 skipping to change at page 25, line 30
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-an-forward' mode. This approach could enable other subnet
technologies to pass ECN signals into the IP layer, even if they do technologies to pass ECN signals into the IP layer, even if they do
not support ECN natively. 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.
11. Acknowledgements 10. Acknowledgements
Thanks to Gorry Fairhurst for extensive reviews. Thanks also to the Thanks to Gorry Fairhurst for extensive reviews. Thanks also to the
following reviewers: Richard Scheffenegger, Ingemar Johansson, Piers following reviewers: Richard Scheffenegger, Ingemar Johansson, Piers
O'Hanlon and Michael Welzl, who pointed out that lower layer O'Hanlon and Michael Welzl, who pointed out that lower layer
congestion notification signals may have different semantics to those congestion notification signals may have different semantics to those
in IP. Thanks are also due to the tsvwg chairs, TSV ADs and IETF in IP. Thanks are also due to the tsvwg chairs, TSV ADs and IETF
liaison people such as Eric Gray, Dan Romascanu and Gonzalo Camarillo liaison people such as Eric Gray, Dan Romascanu and Gonzalo Camarillo
for helping with the liaisons with the IEEE and 3GPP. And thanks to for helping with the liaisons with the IEEE and 3GPP. And thanks to
Georg Mayer and particularly to Erik Guttman for the extensive search Georg Mayer and particularly to Erik Guttman for the extensive search
and categorisation of any 3GPP specifications that cite ECN 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.
12. Comments Solicited 11. Comments Solicited
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 12. References
13.1. Normative References 12.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://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", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 26, line 24 skipping to change at page 26, line 44
<https://www.rfc-editor.org/info/rfc4774>. <https://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, DOI 10.17487/RFC5129, January Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>. 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
13.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.
[DCTCP] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel,
P., Prabhakar, B., Sengupta, S., and M. Sridharan, "Data
Center TCP (DCTCP)", ACM SIGCOMM CCR 40(4)63--74, October
2010, <http://portal.acm.org/citation.cfm?id=1851192>.
[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.
[I-D.ietf-intarea-gue] [I-D.ietf-intarea-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T. and O. Zia, "Generic UDP Encapsulation",
Encapsulation", draft-ietf-intarea-gue-05 (work in draft-ietf-intarea-gue-06 (work in progress), August 2018.
progress), December 2017.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-06 (work in progress), March 2018. nvo3-geneve-08 (work in progress), October 2018.
[I-D.ietf-trill-ecn-support] [I-D.ietf-trill-ecn-support]
Eastlake, D. and B. Briscoe, "TRILL (TRansparent Eastlake, D. and B. Briscoe, "TRILL (TRansparent
Interconnection of Lots of Links): ECN (Explicit Interconnection of Lots of Links): ECN (Explicit
Congestion Notification) Support", draft-ietf-trill-ecn- Congestion Notification) Support", draft-ietf-trill-ecn-
support-07 (work in progress), February 2018. support-07 (work in progress), February 2018.
[I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
id-05 (work in progress), November 2018.
[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-05 (work in progress), November tsvwg-rfc6040update-shim-06 (work in progress), March
2017. 2018.
[I-D.moncaster-tcpm-rcv-cheat]
Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to
Allow Senders to Identify Receiver Non-Compliance", draft-
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,
August 2008, August 2008,
<http://www.ieee802.org/1/pages/802.1ah.html>. <http://www.ieee802.org/1/pages/802.1ah.html>.
(Access Controlled link within page) (Access Controlled link within page)
skipping to change at page 29, line 35 skipping to change at page 29, line 49
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, Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012, DOI 10.17487/RFC6660, July 2012,
<https://www.rfc-editor.org/info/rfc6660>. <https://www.rfc-editor.org/info/rfc6660>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[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, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
skipping to change at page 30, line 20 skipping to change at page 30, line 37
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection Ghanwani, A., and S. Gupta, "Transparent Interconnection
of Lots of Links (TRILL): Clarifications, Corrections, and of Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<https://www.rfc-editor.org/info/rfc7780>. <https://www.rfc-editor.org/info/rfc7780>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>. <https://www.rfc-editor.org/info/rfc8084>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<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-10 to ietf-11
* Removed short section (was 3) 'Guidelines for All Cases'
because it was out of scope, being covered by RFC 4774.
Expanded the Scope section (1.2) to explain all this.
Explained that the default encap/decap rules already support
certain alternative semantics, particularly all three of the
alternative semantics for ECT(1): equivalent to ECT(0) , higher
severity than ECT(0), and unmarked but implying different
marking semantics from ECT(0).
* Clarified why the QCN example was being given even though not
about increment deployment of ECN
* Pointed to the spoofing issue with feed-backward mode from the
Security Considerations section, to aid security review.
* Removed any ambiguity in the word 'transport' throughout
From ietf-09 to ietf-10 From ietf-09 to ietf-10
* Updated section 5.1 on "IP-in-IP tunnels with Shim Headers" to * Updated section 5.1 on "IP-in-IP tunnels with Shim Headers" to
be consistent with updates to draft-ietf-tsvwg-rfc6040update- be consistent with updates to draft-ietf-tsvwg-rfc6040update-
shim. shim.
* Removed reference to the ECN nonce, which has been made * Removed reference to the ECN nonce, which has been made
historic by RFC 8311 historic by RFC 8311
* Removed "Open Issues" Appendix, given all have been addressed. * Removed "Open Issues" Appendix, given all have been addressed.
skipping to change at page 34, line 35 skipping to change at page 36, line 4
* Tightened & added to terminology section * Tightened & added to terminology section
* Structured with Modes of Operation, then Guidelines section for * Structured with Modes of Operation, then Guidelines section for
each mode. each mode.
* 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
Simula Research Laboratory Independent
UK UK
EMail: ietf@bobbriscoe.net EMail: ietf@bobbriscoe.net
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
Broadcom Corporation Broadcom Corporation
 End of changes. 76 change blocks. 
172 lines changed or deleted 241 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/