Aug 22, 2007

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.

Aug 20, 2007

Canonical vs Non-canonical

Canonical Form

Canonical form(also known as "LSB format" and "Ethernet format") is the name given to the format of a LAN adapter address as it should be presented to the user according to the 802 LAN standard. It is best defined as how the bit order of an adapter address on the LAN media maps to the bit order of an adapter address in memory: The first bit of each byte that appears on the LAN maps to the least significant(i.e., right-most) bit of each byte in memory (the figure below illustrates this). This puts the group address indicator (i.e., the bit that defines whether an address is unicast or multicast) in the least significant bit of the first byte. Ethernet and 802.3 hardware behave consistently with this definition. Unfortunately, Token Ring (and some FDDI) hardware does not behave consistently with this definition; it maps the first bit of each byte of the adapter address to the most significant(i.e., left-most) bit of each byte in memory, which puts the group address indicator in the most significant bit of the first byte. This mapping is variously called "MSB format", "IBM format", "Token-Ring format", and "non-canonical form".

The figure below illustrates the difference between canonical and canonicalform using the canonical form address 12-34-56-78-9A-BC as an example:

In memory, 12 34 56 78 9A BC
canonical: 00010010 00110100 01010110 01111000 10011010 10111100

non-canonical: 01001000 00101100 01101010 00011110 01011001 00111101
48 2C 6A 1E 59 3D