ECN(Explicit Congestion Notification) - capable transport - ECT(1) vs ECT(0)
Explicit Congestion Notification in IP
ECN (Explicit Congestion Notification)
This document specifies that the Internet provide a congestion
indication for incipient congestion (as in RED and earlier work
[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 codepoints, '00' to '11'. The
ECN-Capable Transport (ECT) codepoints '10' and '01' are set by the
data sender to indicate that 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
two ECT codepoints. Routers treat the ECT(0) and ECT(1) codepoints
as equivalent. Senders are free to use either the ECT(0) or the
ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.
The use of both the two codepoints for ECT, ECT(0) and ECT(1), is
motivated primarily by the desire to allow mechanisms for the data
sender to verify that network elements are not erasing the CE
codepoint, and that data receivers are properly reporting to the
sender the receipt of packets with the CE codepoint set, as required
by the transport protocol. Guidelines for the senders and receivers
to differentiate between the ECT(0) and ECT(1) codepoints will be
addressed in separate documents, for each transport protocol. In
particular, this document does not address mechanisms for TCP end-
nodes to differentiate between the ECT(0) and ECT(1) codepoints.
Protocols and senders that only require a single ECT codepoint SHOULD
use ECT(0).
The not-ECT codepoint '00' indicates a packet that is not using ECN.
The CE codepoint '11' is set by a router to indicate congestion to
the end nodes. Routers that have a packet arriving at a full queue
drop the packet, just as they do in the absence of ECN.
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 1: The ECN Field in IP.
The Incremental Deployment of ECT(1) in Routers.
ECN has been an Experimental standard since January 1999, and there
are already implementations of ECN in routers that do not understand
the ECT(1) codepoint. When the use of the ECT(1) codepoint is
standardized for TCP or for other transport protocols, this could
mean that a data sender is using the ECT(1) codepoint, but that this
codepoint is not understood by a congested router on the path.
If allowed by the transport protocol, a data sender would be free not
to make use of ECT(1) at all, and to send all ECN-capable packets
with the codepoint ECT(0). However, if an ECN-capable sender is
using ECT(1), and the congested router on the path did not understand
the ECT(1) codepoint, then the router would end up marking some of
the ECT(0) packets, and dropping some of the ECT(1) packets, as
indications of congestion. Since TCP is required to react to both
marked and dropped packets, this behavior of dropping packets that
could have been marked poses no significant threat to the network,
and is consistent with the overall approach to ECN that allows
routers to determine when and whether to mark packets as they see fit.
ECN (Explicit Congestion Notification)
This document specifies that the Internet provide a congestion
indication for incipient congestion (as in RED and earlier work
[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 codepoints, '00' to '11'. The
ECN-Capable Transport (ECT) codepoints '10' and '01' are set by the
data sender to indicate that 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
two ECT codepoints. Routers treat the ECT(0) and ECT(1) codepoints
as equivalent. Senders are free to use either the ECT(0) or the
ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.
The use of both the two codepoints for ECT, ECT(0) and ECT(1), is
motivated primarily by the desire to allow mechanisms for the data
sender to verify that network elements are not erasing the CE
codepoint, and that data receivers are properly reporting to the
sender the receipt of packets with the CE codepoint set, as required
by the transport protocol. Guidelines for the senders and receivers
to differentiate between the ECT(0) and ECT(1) codepoints will be
addressed in separate documents, for each transport protocol. In
particular, this document does not address mechanisms for TCP end-
nodes to differentiate between the ECT(0) and ECT(1) codepoints.
Protocols and senders that only require a single ECT codepoint SHOULD
use ECT(0).
The not-ECT codepoint '00' indicates a packet that is not using ECN.
The CE codepoint '11' is set by a router to indicate congestion to
the end nodes. Routers that have a packet arriving at a full queue
drop the packet, just as they do in the absence of ECN.
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 1: The ECN Field in IP.
The Incremental Deployment of ECT(1) in Routers.
ECN has been an Experimental standard since January 1999, and there
are already implementations of ECN in routers that do not understand
the ECT(1) codepoint. When the use of the ECT(1) codepoint is
standardized for TCP or for other transport protocols, this could
mean that a data sender is using the ECT(1) codepoint, but that this
codepoint is not understood by a congested router on the path.
If allowed by the transport protocol, a data sender would be free not
to make use of ECT(1) at all, and to send all ECN-capable packets
with the codepoint ECT(0). However, if an ECN-capable sender is
using ECT(1), and the congested router on the path did not understand
the ECT(1) codepoint, then the router would end up marking some of
the ECT(0) packets, and dropping some of the ECT(1) packets, as
indications of congestion. Since TCP is required to react to both
marked and dropped packets, this behavior of dropping packets that
could have been marked poses no significant threat to the network,
and is consistent with the overall approach to ECN that allows
routers to determine when and whether to mark packets as they see fit.
Comments