Thus, for packets sent with the CE codepoint set, the TCP end-nodes
could not determine if some router intended to set the CE codepoint
in these packets. For this reason, sending packets with the CE
codepoint would have to be done sparingly, and would be a less
effective check against misbehaving network elements and receivers
than would be the ECN nonce.
The assignment of the fourth ECN codepoint to ECT(1) precludes the
use of this codepoint for some other purposes. For clarity, we
briefly list other possible purposes here.
One possibility might have been for the data sender to use the fourth
ECN codepoint to indicate an alternate semantics for ECN. However,
this seems to us more appropriate to be signaled using a
differentiated services codepoint in the DS field.
A second possible use for the fourth ECN codepoint would have been to
give the router two separate codepoints for the indication of
congestion, CE(0) and CE(1), for mild and severe congestion
respectively. While this could be useful in some cases, this
certainly does not seem a compelling requirement at this point. If
there was judged to be a compelling need for this, the complications
of incremental deployment would most likely necessitate more that
just one codepoint for this function.
A third use that has been informally proposed for the ECN codepoint
is for use in some forms of multicast congestion control, based on
randomized procedures for duplicating marked packets at routers.
Some proposed multicast packet duplication procedures are based on a
new ECN codepoint that (1) conveys the fact that congestion occurred
upstream of the duplication point that marked the packet with this
codepoint and (2) can detect congestion downstream of that
duplication point. ECT(1) can serve this purpose because it is both
distinct from ECT(0) and is replaced by CE when ECN marking occurs in
response to congestion or incipient congestion. Explanation of how
this enhanced version of ECN would be used by multicast congestion
control is beyond the scope of this document, as are ECN-aware
multicast packet duplication procedures and the processing of the ECN
field at multicast receivers in all cases (i.e., irrespective of the
multicast packet duplication procedure(s) used).
The specification of IP tunnel modifications for ECN in this document
assumes that the only change made to the outer IP header's ECN field
between tunnel endpoints is to set the CE codepoint to indicate
congestion. This is not consistent with some of the proposed uses of
ECT(1) by the multicast duplication procedures in the previous
paragraph, and such procedures SHOULD NOT be deployed unless this
inconsistency between multicast duplication procedures and IP tunnels
with full ECN functionality is resolved. Limited ECN functionality
may be used instead, although in practice many tunnel protocols
(including IPsec) will not work correctly if multicast traffic
duplication occurs within the tunnel
21. Why use Two Bits in the IP Header?
Given the need for an ECT indication in the IP header, there still
remains the question of whether the ECT (ECN-Capable Transport) and
CE (Congestion Experienced) codepoints should have been overloaded on
a single bit. This overloaded-one-bit alternative, explored in
[Floyd94], would have involved a single bit with two values. One
value, "ECT and not CE", would represent an ECN-Capable Transport,
and the other value, "CE or not ECT", would represent either
Congestion Experienced or a non-ECN-Capable transport.
One difference between the one-bit and two-bit implementations
concerns packets that traverse multiple congested routers. Consider
a CE packet that arrives at a second congested router, and is
selected by the active queue management at that router for either
marking or dropping. In the one-bit implementation, the second
congested router has no choice but to drop the CE packet, because it
cannot distinguish between a CE packet and a non-ECT packet. In the
two-bit implementation, the second congested router has the choice of
either dropping the CE packet, or of leaving it alone with the CE
codepoint set.
Another difference between the one-bit and two-bit implementations
comes from the fact that with the one-bit implementation, receivers
in a single flow cannot distinguish between CE and non-ECT packets.
Thus, in the one-bit implementation an ECN-capable data sender would
have to unambiguously indicate to the receiver or receivers whether
each packet had been sent as ECN-Capable or as non-ECN-Capable. One
possibility would be for the sender to indicate in the transport
header whether the packet was sent as ECN-Capable. A second
possibility that would involve a functional limitation for the one-
bit implementation would be for the sender to unambiguously indicate
that it was going to send *all* of its packets as ECN-Capable or as
non-ECN-Capable. For a multicast transport protocol, this
unambiguous indication would have to be apparent to receivers joining
an on-going multicast session.
Another concern that was described earlier (and recommended in this
document) is that transports (particularly TCP) should not mark pure
ACK packets or retransmitted packets as being ECN-Capable. A pure
ACK packet from a non-ECN-capable transport could be dropped, without
necessarily having an impact on the transport from a congestion
control perspective (because subsequent ACKs are cumulative). An
ECN-capable transport reacting to the CE codepoint in a pure ACK
packet by reducing the window would be at a disadvantage in
comparison to a non-ECN-capable transport. For this reason (and for
reasons described earlier in relation to retransmitted packets), it
is desirable to have the ECT codepoint set on a per-packet basis.
Another advantage of the two-bit approach is that it is somewhat more
robust. The most critical issue, discussed in Section 8, is that the
default indication should be that of a non-ECN-Capable transport. In
a two-bit implementation, this requirement for the default value
simply means that the not-ECT codepoint should be the default. In
the one-bit implementation, this means that the single overloaded bit
should by default be in the "CE or not ECT" position. This is less
clear and straightforward, and possibly more open to incorrect
implementations either in the end nodes or in the routers.
In summary, while the one-bit implementation could be a possible
implementation, it has the following significant limitations relative
to the two-bit implementation. First, the one-bit implementation has
more limited functionality for the treatment of CE packets at a
second congested router. Second, the one-bit implementation requires
either that extra information be carried in the transport header of
packets from ECN-Capable flows (to convey the functionality of the
second bit elsewhere, namely in the transport header), or that
senders in ECN-Capable flows accept the limitation that receivers
must be able to determine a priori which packets are ECN-Capable and
which are not ECN-Capable. Third, the one-bit implementation is
possibly more open to errors from faulty implementations that choose
the wrong default value for the ECN bit. We believe that the use of
the extra bit in the IP header for the ECT-bit is extremely valuable
to overcome these limitations.
22. Historical Definitions for the IPv4 TOS Octet
RFC791 [RFC791] defined the ToS (Type of Service) octet in the IP
header. In RFC791, bits 6 and 7 of the ToS octet are listed as
"Reserved for Future Use", and are shown set to zero. The first two
fields of the ToS octet were defined as the Precedence and Type of
Service (TOS) fields.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | 0 | 0 | RFC791
+-----+-----+-----+-----+-----+-----+-----+-----+
RFC1122 included bits 6 and 7 in the TOS field, though it did not
discuss any specific use for those two bits:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | RFC1122
+-----+-----+-----+-----+-----+-----+-----+-----+
The IPv4 TOS octet was redefined in RFC1349 [RFC1349] as follows:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ | RFC1349
+-----+-----+-----+-----+-----+-----+-----+-----+
Bit 6 in the TOS field was defined in RFC1349 for "Minimize Monetary
Cost". In addition to the Precedence and Type of Service (TOS)
fields, the last field, MBZ (for "must be zero") was defined as
currently unused. RFC1349 stated that "The originator of a datagram
sets [the MBZ] field to zero (unless participating in an Internet
protocol experiment which makes use of that bit)."
RFC1455 [RFC1455] defined an experimental standard that used all
four bits in the TOS field to request a guaranteed level of link
security.
RFC1349 and RFC1455 have been obsoleted by "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers" [RFC2474] in which bits 6 and 7 of the DS field are listed
as Currently Unused (CU). RFC2780 [RFC2780] specified ECN as an
experimental use of the two-bit CU field. RFC2780 updated the
definition of the DS Field to only encompass the first six bits of
this octet rather than all eight bits; these first six bits are
defined as the Differentiated Services CodePoint (DSCP):
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | CU | RFCs 2474,
+-----+-----+-----+-----+-----+-----+-----+-----+ 2780
Because of this unstable history, the definition of the ECN field in
this document cannot be guaranteed to be backwards compatible with
all past uses of these two bits.
Prior to RFC2474, routers were not permitted to modify bits in
either the DSCP or ECN field of packets forwarded through them, and
hence routers that comply only with RFCs prior to 2474 should have no
effect on ECN. For end nodes, bit 7 (the second ECN bit) must be
transmitted as zero for any implementation compliant only with RFCs
prior to 2474. Such nodes may transmit bit 6 (the first ECN bit) as
one for the "Minimize Monetary Cost" provision of RFC1349 or the
experiment authorized by RFC1455; neither this aspect of RFC1349
nor the experiment in RFC1455 were widely implemented or used. The
damage that could be done by a broken, non-conformant router would
include "erasing" the CE codepoint for an ECN-capable packet that
arrived at the router with the CE codepoint set, or setting the CE
codepoint even in the absence of congestion. This has been discussed
in the section on "Non-compliance in the Network".
The damage that could be done in an ECN-capable environment by a
non-ECN-capable end-node transmitting packets with the ECT codepoint
set has been discussed in the section on "Non-compliance by the End
Nodes".
23. IANA Considerations
This section contains the namespaces that have either been created in
this specification, or the values assigned in existing namespaces
managed by IANA.
23.1. IPv4 TOS Byte and IPv6 Traffic Class Octet
The codepoints for the ECN Field of the IP header are specified by
the Standards Action of this RFC, as is required by RFC2780.
When this document is published as an RFC, IANA should create a new
registry, "IPv4 TOS Byte and IPv6 Traffic Class Octet", with the
namespace as follows:
IPv4 TOS Byte and IPv6 Traffic Class Octet
Description: The registrations are identical for IPv4 and IPv6.
Bits 0-5: see Differentiated Services Field Codepoints Registry
(http://www.iana.org/assignments/dscp-registry)
Bits 6-7, ECN Field:
Binary Keyword References
------ ------- ----------
00 Not-ECT (Not ECN-Capable Transport) [RFC3168]
01 ECT(1) (ECN-Capable Transport(1)) [RFC3168]
10 ECT(0) (ECN-Capable Transport(0)) [RFC3168]
11 CE (Congestion Experienced) [RFC3168]
23.2. TCP Header Flags
The codepoints for the CWR and ECE flags in the TCP header are
specified by the Standards Action of this RFC, as is required by RFC
2780.
When this document is published as an RFC, IANA should create a new
registry, "TCP Header Flags", with the namespace as follows:
TCP Header Flags
The Transmission Control Protocol (TCP) included a 6-bit Reserved
field defined in RFC793, reserved for future use, in bytes 13 and 14
of the TCP header, as illustrated below. The other six Control bits
are defined separately by RFC793.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RFC3168 defines two of the six bits from the Reserved field to be
used for ECN, as follows:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TCP Header Flags
Bit Name Reference
--- ---- ---------
8 CWR (Congestion Window Reduced) [RFC3168]
9 ECE (ECN-Echo) [RFC3168]
23.3. IPSEC Security Association Attributes
IANA allocated the IPSEC Security Association Attribute value 10 for
the ECN Tunnel use described in Section 9.2.1.2 above at the request
of David Black in November 1999. The IANA has changed the Reference
for this allocation from David Black's request to this RFC.
24. Authors' Addresses
K. K. Ramakrishnan
TeraOptic Networks, Inc.
Phone: +1 (408) 666-8650
EMail: kk@teraoptic.com
Sally Floyd
ACIRI
Phone: +1 (510) 666-2989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
David L. Black
EMC Corporation
42 South St.
Hopkinton, MA 01748
Phone: +1 (508) 435-1000 x75140
EMail: black_david@emc.com
25. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.