ECN
Click on the red underlined text to get to the source
... CE) codepoint in the IP
header of packets from ECN-capable transports. We describe when the
CE ...
... routers, and describe modifications
needed to TCP to make it ECN-capable. Modifications to other
transport protocols (e.g., unreliable unicast ...
... considered as those protocols are developed and advance through the
standards process. We also describe in this document the issues
involving the use of ECN within IP tunnels, and within IPsec tunnels ...
... has been the prior existence of some IP tunnels that were not
compatible with the use of ECN. As ECN becomes deployed, non-
compatible IP tunnels ...
... IP tunnels that were not
compatible with the use of ECN. As ECN becomes deployed, non-
compatible IP tunnels will have to be upgraded to conform to this
...
... This document obsoletes RFC 2481(-> 3168prop), "A Proposal to add Explicit
Congestion Notification (ECN) to IP", which defined ECN as an
...
... Explicit
Congestion Notification (ECN) to IP", which defined ECN as an
Experimental Protocol for the Internet Community ...
... DS Field) in the IPv4 and IPv6 Headers", in defining the ECN field
in the IP header, RFC 2401(-> 4301prop) ...
... tunnel mode header construction to be compatible with
the use of ECN, and RFC 793std7, "Transmission Control Protocol", in
...
... Internet that either drop a TCP SYN packet
configured to negotiate ECN, or respond with a RST. This document
specifies procedures that TCP ...
... and assumptions that guided the design choices in this proposal.
* Because ECN is likely to be adopted gradually, accommodating
migration is essential. Some routers ...
... routers may still only drop packets
to indicate congestion, and some end-systems may not be ECN-
capable. The most viable strategy is one that accommodates
incremental deployment ...
... incremental deployment without having to resort to "islands" of
ECN-capable and non-ECN-capable environments.
...
... deployment without having to resort to "islands" of
ECN-capable and non-ECN-capable environments.
* New mechanisms for congestion control ...
... congestion control. The benefit of lying about participating in
new mechanisms such as ECN-capability should be small.
...
... several alternatives for congestion indication, but in the absence of
ECN, AQM is restricted to using packet drops as a mechanism for
congestion indication. AQM drops packets based on the average queue ...
... of the CE codepoint with ECN allows the receiver(s) to receive the
packet, avoiding the potential for excessive delays due to
...
... RJ90]) where the notification can sometimes be through marking
packets rather than dropping them. This uses an ECN field in the IP
header with two bits, making four ECN ...
... ECN codepoints, '00' to '11'. The
ECN-Capable Transport (ECT) codepoints '10' and '01' are set by the
...
... end-points of the transport protocol
are ECN-capable; we call them ECT(0) and ECT(1) respectively. The
phrase "the ECT codepoint" in this documents refers to either of the
...
... Routers that have a packet arriving at a full queue
drop the packet, just as they do in the absence of ECN.
+-----+-----+
...
... The use of two ECT codepoints essentially gives a one-bit ECN nonce
in packet headers, and routers ...
... codepoint
would be more likely to be detected by the end-nodes. The ECN nonce
also can address the problem of misbehaving transport ...
... codepoint '01'). Backwards compatibility with earlier ECN
implementations that do not understand the ECT(1) codepoint is
...
... In RFC 2481(-> 3168prop) [RFC2481], the ECN field was divided into the ECN-Capable
Transport ...
... 2481(-> 3168prop) [RFC2481], the ECN field was divided into the ECN-Capable
Transport (ECT) bit ...
... bit. The ECN field with only the
ECN-Capable Transport (ECT) bit set in RFC 2481(-> 3168prop) ...
... 2481(-> 3168prop) corresponds to the
ECT(0) codepoint in this document, and the ECN field with both the
ECT and CE ...
... Traffic Class octet in IPv6,
and the ECN field is defined identically in both cases. The
definitions for the IPv4 TOS ...
... 2780 as
approved for experimental use for ECN. Section 22 gives a brief
history of the TOS octet.
...
...
Because of the unstable history of the TOS octet, the use of the ECN
field as specified in this document cannot be guaranteed to be
backwards compatible with those past uses of these two bits ...
... backwards compatible with those past uses of these two bits that
pre-date ECN. The potential dangers of this lack of backwards
compatibility are discussed in Section 22.
...
... backwards
compatibility are discussed in Section 22.
Upon the receipt by an ECN-Capable transport of a single CE packet,
...
... essentially the same as the congestion control response to a *single*
dropped packet. For example, for ECN-Capable TCP the source TCP is
...
... required to halve its congestion window for any window of data
containing either a packet drop or an ECN indication.
One reason for requiring that the congestion ...
... CE packet be essentially the same as the response to a dropped packet
is to accommodate the incremental deployment of ECN in both end-
systems and in routers. Some routers ...
... systems and in routers. Some routers may drop ECN-Capable packets
(e.g., using the same AQM policies for congestion detection) while
...
... congestion. Similarly, a router might drop a non-ECN-Capable packet
but set the CE codepoint ...
... but set the CE codepoint in an ECN-Capable packet, for equivalent
levels of congestion. If there were different congestion control ...
... router, the CE codepoint of an ECN-Capable packet SHOULD only
be set if the router would otherwise have dropped the packet as an
...
...
An environment where all end nodes were ECN-Capable could allow new
criteria to be developed for setting the CE codepoint ...
... packet losses will become relatively infrequent when a majority of
end-systems become ECN-Capable and participate in TCP or other
compatible congestion control ...
... TCP or other
compatible congestion control mechanisms. In an ECN-Capable
environment that is adequately-provisioned, packet losses should
...
... active queue management, leaving that
endeavor, if needed, to other areas of the IETF. While ECN is
inextricably tied up with the need to have a reasonable active queue
management mechanism at the router ...
... router, the reverse does not hold; active
queue management mechanisms have been developed and deployed
independent of ECN, using packet drops as indications of congestion
in the absence of ECN ...
... ECN, using packet drops as indications of congestion
in the absence of ECN in the IP architecture.
...
... ECN as an Indication of Persistent Congestion ...
... TCP-sender reaction specified in this document for
ECN is NOT the appropriate reaction for such a noisy signal of
congestion notification. However, if the routers ...
... switches or Frame Relay switches) to take advantage of ECN.
For example, using a scheme such as RED (where packet marking is
based on the average queue ...
...
For the proposed use for ECN in this document (that is, for a
transport protocol such as TCP ...
... ACK packets in response to
an earlier dropped ACK packet. Any proposal for extending ECN-
Capability to such packets would have to address issues such as the
...
... subject of research, so this document specifies that at this
time, "pure" ACK packets MUST NOT indicate ECN-Capability.
Similarly, if a CE ...
... buffer overflow. In particular, the ubiquitous
deployment of ECN would not, in and of itself, be a sufficient
development to allow end-nodes to interpret packet drops as
...
... If both actions are applicable, either MAY be chosen. Reassembly of
a fragmented packet MUST NOT change the ECN codepoint when all of the
fragments ...
... We would note that because RFC 2481(-> 3168prop) did not specify reassembly
behavior, older ECN implementations conformant with that Experimental
RFC do not necessarily perform reassembly correctly, in terms of
...
... sender could avoid
the consequences of this behavior by setting the DF bit in ECN-
Capable packets.
...
... protocol
specifications SHOULD instead specify that DF MUST be set in all
ECN-capable packets sent by the protocol.
...
...
ECN requires support from the transport protocol, in addition to the
functionality given by the ECN ...
... ECN requires support from the transport protocol, in addition to the
functionality given by the ECN field in the IP packet header. The
...
... endpoints
during setup to determine that all of the endpoints are ECN-capable,
so that the sender can set the ECT codepoint ...
... ECN Capability to TCP,
leaving issues of ECN in other transport protocols to further
research. For TCP ...
... transport protocols to further
research. For TCP, ECN requires three new pieces of functionality:
negotiation between the endpoints ...
... endpoints during connection setup to
determine if they are both ECN-capable; an ECN-Echo (ECE) flag in the
...
... connection setup to
determine if they are both ECN-capable; an ECN-Echo (ECE) flag in the
TCP header ...
...
The following sections describe in detail the proposed use of ECN in
TCP. This proposal is described in essentially the same form in
...
... TCP mechanism for negotiating ECN-Capability uses
the ECN-Echo (ECE) flag in the TCP header. Bit ...
... Bit 9 in the Reserved
field of the TCP header is designated as the ECN-Echo flag. The
location of the 6-bit ...
... 793std7 [RFC793] (and is reproduced below for
completeness). This specification of the ECN Field leaves the
Reserved field as a 4-bit ...
... TCP receiver to determine when to stop setting the
ECN-Echo flag, we introduce a second new flag in the TCP header, the
...
... connection endpoints, and
uses the ECN-Echo and CWR flags in the TCP header (as shown in Figure
...
... signaling. For a TCP connection,
a typical sequence of events in an ECN-based reaction to congestion
is as follows:
...
... codepoint is set in packets transmitted by the sender to
indicate that ECN is supported by the transport entities for
these packets.
...
... packet sent to the receiver to acknowledge its receipt of and
reaction to the ECN-Echo flag.
...
... TCP transport entities and the
use of the ECN-Echo and CWR flags is described in more detail in the
sections below.
...
... TCP connection setup phase, the source and destination TCPs
exchange information about their willingness to use ECN. Subsequent
to the completion of this negotiation, the TCP ...
... network
that the transport is capable and willing to participate in ECN for
this packet. This indicates to the routers that they may mark this
...
... congestion notification. If the TCP connection does not
wish to use ECN notification for a particular packet, the sending TCP
...
... notification for a particular packet, the sending TCP
sets the ECN codepoint to not-ECT, and the TCP receiver ...
... Host B. We call a SYN packet with the ECE and
CWR flags set an "ECN-setup SYN packet", and we call a SYN packet
...
... SYN packet", and we call a SYN packet
with at least one of the ECE and CWR flags not set a "non-ECN-setup
SYN packet". Similarly, we call a SYN ...
... SYN-ACK packet with only the ECE
flag set but the CWR flag not set an "ECN-setup SYN-ACK packet", and
...
... SYN-ACK packet with any other configuration of the ECE and
CWR flags a "non-ECN-setup SYN-ACK packet".
...
... ACK packet. For a SYN
packet, the setting of both ECE and CWR in the ECN-setup SYN packet
is defined as an indication that the sending TCP ...
... SYN packet
is defined as an indication that the sending TCP is ECN-Capable,
rather than as an indication of congestion or of response to
...
... congestion or of response to
congestion. More precisely, an ECN-setup SYN packet indicates that
the TCP ...
... transmitting the SYN packet will participate
in ECN as both a sender and receiver. Specifically, as a receiver,
...
... have ECE set by reducing the congestion window and setting CWR when
appropriate. An ECN-setup SYN packet does not commit the TCP sender ...
... SYN-ACK packet, it sets the ECE flag
but not the CWR flag. An ECN-setup SYN-ACK packet is defined as an
...
... packets.
The following rules apply to the sending of ECN-setup packets within
a TCP connection, where a TCP connection ...
... ECN-setup SYN packet, then it MAY send
an ECN-setup SYN-ACK packet. Otherwise, it MUST NOT send an
...
... host MUST NOT set ECT on data packets unless it has sent at
least one ECN-setup SYN or ECN-setup SYN ...
... IP header, then
that host MUST process these packets as specified for an ECN-
capable connection.
...
...
* A host that is not willing to use ECN on a TCP connection SHOULD
clear both the ECE and CWR flags in all non-ECN ...
... ECN on a TCP connection SHOULD
clear both the ECE and CWR flags in all non-ECN-setup SYN and/or
SYN ...
... ACK packets that it sends to indicate this unwillingness.
Receivers MUST correctly handle all forms of the non-ECN-setup
SYN and SYN ...
...
ECN introduces the use of the ECN-Echo and CWR flags in the TCP
header (as shown in Figure 3) for initialization ...
... intrusion detection systems in
the Internet that either drop an ECN-setup SYN packet or respond with
a RST ...
... host that receives a RST in response to the transmission
of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared.
...
... SYN being lost, the
originating host may retransmit one or more ECN-setup SYN packets
before giving up and retransmitting the SYN ...
... bit on data packets. Further, an
important consequence of the rules for ECN setup and usage in Section
6.1.1 is that a host is forbidden from using the reception of ECT
...
... ACK packet. This asymmetry is
necessary for the robust negotiation of ECN-capability with some
deployed TCP implementations. There exists at least one faulty TCP ...
... ECN-Echo and CWR flags to
indicate ECN-capability, while the SYN-ACK packet sets only the ECN ...
... Reserved field as an indication
that the receiver is not ECN-capable. The sending TCP is not mislead
by a faulty TCP ...
... ACK
packet (that is, an ACK packet with the ECN-Echo flag set in the TCP
header), then the sender ...
... congestion should be treated just as a congestion loss in non-
ECN-Capable TCP. That is, the TCP source halves the congestion window ...
... TCP SHOULD NOT increase the congestion window in response to the
receipt of an ECN-Echo ACK packet.
...
... TCP sender even further, on
receipt of an ECN-Echo packet when the congestion window is one. We
...
... retransmit timer on receiving the ECN-Echo packet when the congestion
window is one. The sending TCP ...
... reason (because of a retransmit timeout, a Fast Retransmit, or in
response to an ECN Notification), the TCP sender ...
... [Floyd94] discusses TCP's response to ECN in more detail. [Floyd98]
discusses the validation ...
... ns simulator, which illustrates
a wide range of ECN scenarios. These scenarios include the following:
an ECN followed by another ECN ...
... wide range of ECN scenarios. These scenarios include the following:
an ECN followed by another ECN, a Fast Retransmit, or a Retransmit
...
... ECN scenarios. These scenarios include the following:
an ECN followed by another ECN, a Fast Retransmit, or a Retransmit
Timeout; a Retransmit Timeout or a Fast Retransmit ...
... Timeout; a Retransmit Timeout or a Fast Retransmit followed by an
ECN; and a congestion window of one packet followed by an ECN.
...
... ACK for two arriving data packets, then the
ECN-Echo flag in the ACK packet will be set to '1' if the CE ...
... To provide robustness against the possibility of a dropped ACK packet
carrying an ECN-Echo flag, the TCP receiver ...
... receiver
would once again send ACK packets with the ECN-Echo flag set. While
the receipt of a CWR packet does not guarantee that the data sender ...
... the receipt of a CWR packet does not guarantee that the data sender
received the ECN-Echo message, this does suggest that the data sender
...
... TCP data receiver SHOULD
ignore the ECN field on arriving data packets that are outside of the
receiver ...
... security against
denial-of-service attacks, as well as for robustness of the ECN
congestion indication with packets that are dropped later in the
...
... valid indication of congestion, and therefore
whether to return ECN-Echo indications to the TCP data sender ...
...
One drawback of not setting ECT(0) or ECT(1) on retransmitted packets
is that it denies ECN protection for retransmitted packets. However,
for an ECN-capable TCP connection ...
... is that it denies ECN protection for retransmitted packets. However,
for an ECN-capable TCP connection in a fully-ECN-capable environment
...
... for an ECN-capable TCP connection in a fully-ECN-capable environment
with mild congestion, packets should rarely be dropped due to
...
... packet losses (from corruption or from
congestion) that ECN has been unable to prevent.
We note that if the router ...
...
This section discusses concerns about the vulnerability of ECN to
non-compliant end-nodes (i.e., end nodes ...
... in transmitted packets but do not respond to received CE packets).
We argue that the addition of ECN to the IP architecture will not
...
... flows.
Even for non-ECN environments, there are serious concerns about the
damage that can be done by non-compliant or unresponsive flows (that
...
...
It might seem that dropping packets in itself is an adequate
deterrent for non-compliance, and that the use of ECN removes this
deterrent. We would argue in response that (1) ECN ...
... ECN removes this
deterrent. We would argue in response that (1) ECN-capable routers
preserve packet-dropping behavior in times of high congestion ...
... not an adequate deterrent for non-compliance.
First, ECN-Capable routers will only mark packets (as opposed to
dropping them) when the packet marking rate is reasonably low. During
...
... packet headers.
During the periods of low or moderate packet marking rates when ECN
would be deployed, there would be little deterrent effect on
unresponsive flows ...
... methods have been proposed to identify and restrict non-
compliant or unresponsive flows. The addition of ECN to the network
environment would not in any way increase the difficulty of designing
and deploying such mechanisms. If anything, the addition of ECN ...
... ECN to the network
environment would not in any way increase the difficulty of designing
and deploying such mechanisms. If anything, the addition of ECN to
the architecture would make the job of identifying unresponsive flows ...
... architecture would make the job of identifying unresponsive flows
slightly easier. For example, in an ECN-Capable environment routers
are not limited to information about packets that are dropped or have
...
... router is operating,
possibly maliciously, to modify either of the bits in the ECN field.
We note that in IPv4, the IP header ...
...
By tampering with the bits in the ECN field, an adversary (or a
broken router) could do one or more of the following: falsely report
...
... router) could do one or more of the following: falsely report
congestion, disable ECN-Capability for an individual packet, erase
the ECN congestion ...
... congestion, disable ECN-Capability for an individual packet, erase
the ECN congestion indication, or falsely indicate ECN-Capability.
...
... the ECN congestion indication, or falsely indicate ECN-Capability.
Section 18 systematically examines the various cases by which the ECN
...
... congestion indication, or falsely indicate ECN-Capability.
Section 18 systematically examines the various cases by which the ECN
field could be modified. The important criterion considered in
determining the consequences of such modifications is whether it is
...
... The first two possible changes, falsely reporting congestion or
disabling ECN-Capability for an individual packet, are no worse than
if the router were to simply drop the packet. From a congestion
control ...
...
However, as discussed in Section 18, a router that erases the ECN
congestion indication or falsely indicates ECN ...
... ECN
congestion indication or falsely indicates ECN-Capability could
potentially do more damage to the flow that if it has simply dropped
...
... Section 19 considers the potential repercussions of subverting end-
to-end congestion control by either falsely indicating ECN-
Capability, or by erasing the congestion indication in ECN ...
... codepoint). We observe in Section 19 that the consequence of
subverting ECN-based congestion control may lead to potential
unfairness, but this is likely to be no worse than the subversion of
...
... congestion control may lead to potential
unfairness, but this is likely to be no worse than the subversion of
either ECN-based or packet-based congestion control by the end nodes.
...
... router could do no more damage to a flow by
altering the ECN field than it could by simply dropping all of the
packets from that flow. However, in some cases, a malicious or
...
... flow. The question is as follows: can this router, by altering
the ECN field in this subset of the packets, do more damage to that
flow than if it has simply dropped that set of the packets?
...
... discussed in detail in Section 18, which concludes as
follows: It is true that the adversary that has access only to a
subset of packets in an aggregate might, by subverting ECN-based
congestion control, be able to deny the benefits of ECN ...
... ECN-based
congestion control, be able to deny the benefits of ECN to the other
packets in the aggregate. While this is undesirable, this is not a
sufficient concern to result in disabling ECN ...
... ECN to the other
packets in the aggregate. While this is undesirable, this is not a
sufficient concern to result in disabling ECN.
...
... IP [RFC2003]. This section
considers issues related to interactions between ECN and IP tunnels,
and specifies two alternative solutions. This discussion ...
... Differentiated Services uses the remaining six bits of the IP
header octet that is used by ECN (see Figure 2 in Section 5).
Some IP tunnel ...
... ECN interacts with IP tunnels based on the
treatment of the ECN field in the IP header. In simple IP tunnels
...
... IP header. In simple IP tunnels
the octet containing the ECN field is copied or mapped from the inner
IP header to the outer IP header ...
... outer header were to be simply discarded without taking care to deal
with the ECN field, and an ECN-capable router were to set the CE ...
... header were to be simply discarded without taking care to deal
with the ECN field, and an ECN-capable router were to set the CE
...
... header is discarded at the tunnel egress point. This problem
was encountered with ECN and IPsec in tunnel mode, and RFC 2481(-> 3168prop) ...
... tunnel mode, and RFC 2481(-> 3168prop)
recommended that ECN not be used with the older simple IPsec tunnels
...
... IPsec tunnels
in order to avoid this behavior and its consequences. When ECN
becomes widely deployed, then simple tunnels likely to carry ECN ...
... ECN
becomes widely deployed, then simple tunnels likely to carry ECN-
capable traffic will have to be changed. If ECN ...
... ECN-
capable traffic will have to be changed. If ECN-capable traffic is
carried by a simple tunnel ...
... traffic is
carried by a simple tunnel through a congested, ECN-capable router,
this could result in subsequent packets being dropped for this flow ...
... IP tunnel might raise security concerns because an adversary could
tamper with the ECN information that propagates beyond the tunnel
endpoint. Based on an analysis in Sections 18 and 19 of these
concerns and the resultant risks, our overall approach is to make
...
... tunnel
endpoint. Based on an analysis in Sections 18 and 19 of these
concerns and the resultant risks, our overall approach is to make
support for ECN an option for IP tunnels, so that an IP tunnel can be
...
... IP tunnels, so that an IP tunnel can be
specified or configured either to use ECN or not to use ECN in the
outer header ...
... IP tunnel can be
specified or configured either to use ECN or not to use ECN in the
outer header of the tunnel ...
... tunnel. Thus, in environments or tunneling
protocols where the risks of using ECN are judged to outweigh its
benefits, the tunnel can simply not use ECN ...
... ECN are judged to outweigh its
benefits, the tunnel can simply not use ECN in the outer header.
Then the only indication of congestion ...
...
The result is that there are two viable options for the behavior of
ECN-capable connections over an IP tunnel, including IPsec ...
... tunnels:
* A limited-functionality option in which ECN is preserved in the
inner header, but disabled in the outer header ...
... tunnel in this case is dropped packets.
* A full-functionality option that supports ECN in both the inner
and outer headers, and propagates congestion ...
... these changes sufficient to support only the limited-functionality
option would be sufficient to eliminate any incompatibility between
ECN and IP tunnels.
...
... full discussion of the potential effects of an adversary's
modifications of the ECN field is given in Sections 18 and 19.
...
... codepoint to be set in the outside (encapsulating)
header regardless of the value of the ECN field in the inside
(encapsulated) header ...
... (encapsulated) header. With this option, the ECN field in the inner
header is not altered upon de-capsulation. The disadvantage of this
...
... header is not altered upon de-capsulation. The disadvantage of this
approach is that the flow does not have ECN support for that part of
the path that is using IP tunneling ...
... (from the original TCP sender) is ECN-Capable. That is, if the
encapsulated packet arrives at a congested router ...
... encapsulated packet arrives at a congested router that is ECN-
capable, and the router can decide to drop or mark the packet as an
...
... will have to drop the packet.
The full-functionality option for ECN encapsulation is to copy the
ECN ...
... ECN