the switch, while the ECN decision would need to be made local to the
output buffer. This is not an issue for IPv6, since there is no IPv6
header checksum. The IPv4 TOS octet is the last byte of a 16-bit
half-word.
RFC1141 [RFC1141] discusses the incremental updating of the IPv4
checksum after the TTL field is decremented. The incremental
updating of the IPv4 checksum after the CE bit was set would work as
follows: Let HC be the original header checksum, and let HC' be the
new header checksum after the CE bit has been set. Then for header
checksums calculated with one's complement subtraction, HC' would be
recalculated as follows:
HC' = { HC - 1 HC > 1
{ 0x0000 HC = 1
For header checksums calculated on two's complement machines, HC'
would be recalculated as follows after the CE bit was set:
HC' = { HC - 1 HC > 0
{ 0xFFFE HC = 0
17. The motivation for the ECT bit.
The need for the ECT bit is motivated by the fact that ECN will be
deployed incrementally in an Internet where some transport protocols
and routers understand ECN and some do not. With the ECT bit, the
router can drop packets from flows that are not ECN-capable, but can
*instead* set the CE bit in flows that *are* ECN-capable. Because the
ECT bit allows an end node to have the CE bit set in a packet
*instead* of having the packet dropped, an end node might have some
incentive to deploy ECN.
If there was no ECT indication, then the router would have to set the
CE bit for packets from both ECN-capable and non-ECN-capable flows.
In this case, there would be no incentive for end-nodes to deploy
ECN, and no viable path of incremental deployment from a non-ECN
world to an ECN-capable world. Consider the first stages of such an
incremental deployment, where a subset of the flows are ECN-capable.
At the onset of congestion, when the packet dropping/marking rate
would be low, routers would only set CE bits, rather than dropping
packets. However, only those flows that are ECN-capable would
understand and respond to CE packets. The result is that the ECN-
capable flows would back off, and the non-ECN-capable flows would be
unaware of the ECN signals and would continue to open their
congestion windows.
In this case, there are two possible outcomes: (1) the ECN-capable
flows back off, the non-ECN-capable flows get all of the bandwidth,
and congestion remains mild, or (2) the ECN-capable flows back off,
the non-ECN-capable flows don't, and congestion increases until the
router transitions from setting the CE bit to dropping packets.
While this second outcome evens out the fairness, the ECN-capable
flows would still receive little benefit from being ECN-capable,
because the increased congestion would drive the router to packet-
dropping behavior.
A flow that advertised itself as ECN-Capable but does not respond to
CE bits is functionally equivalent to a flow that turns off
congestion control, as discussed in Sections 8 and 9.
Thus, in a world when a subset of the flows are ECN-capable, but
where ECN-capable flows have no mechanism for indicating that fact to
the routers, there would be less effective and less fair congestion
control in the Internet, resulting in a strong incentive for end
nodes not to deploy ECN.
18. 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) indications should be overloaded on a
single bit. This overloaded-one-bit alternative, explored in
[Floyd94], would involve 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 bit
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 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 ECT bit should be `OFF' by 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.
19. 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 is obsoleted by "Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers" [DIFFSERV], in which
bits 6 and 7 of the DS field are listed as Currently Unused (CU).
The first six bits of the DS field are defined as the Differentiated
Services CodePoint (DSCP):
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | CU |
+-----+-----+-----+-----+-----+-----+-----+-----+
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. The damage that could be done by a
non-ECN-capable router would be to "erase" the CE bit for an ECN-
capable packet that arrived at the router with the CE bit set, or set
the CE bit even in the absence of congestion. This has been
discussed in Section 10 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 bit set
has been discussed in Section 9 on "Non-compliance by the End Nodes".
AUTHORS' ADDRESSES
K. K. Ramakrishnan
AT&T Labs. Research
Phone: +1 (973) 360-8766
EMail: kkrama@research.att.com
URL: http://www.research.att.com/info/kkrama
Sally Floyd
Lawrence Berkeley National Laboratory
Phone: +1 (510) 486-7518
EMail: floyd@ee.lbl.gov
URL: http://www-nrg.ee.lbl.gov/floyd/
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.