rfc2481.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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



Ramakrishnan & Floyd          Experimental                     [Page 21]

RFC 2481                       ECN to IP                    January 1999


   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

   RFC 791 [RFC791] defined the ToS (Type of Service) octet in the IP
   header.  In RFC 791, 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  |    RFC 791
         +-----+-----+-----+-----+-----+-----+-----+-----+

   RFC 1122 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                   |    RFC 1122
         +-----+-----+-----+-----+-----+-----+-----+-----+

   The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:

            0     1     2     3     4     5     6     7
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |   PRECEDENCE    |       TOS             | MBZ |    RFC 1349
         +-----+-----+-----+-----+-----+-----+-----+-----+



Ramakrishnan & Floyd          Experimental                     [Page 22]

RFC 2481                       ECN to IP                    January 1999


   Bit 6 in the TOS field was defined in RFC 1349 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.  RFC 1349 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)."

   RFC 1455 [RFC 1455] defined an experimental standard that used all
   four bits in the TOS field to request a guaranteed level of link
   security.

   RFC 1349 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".


















Ramakrishnan & Floyd          Experimental                     [Page 23]

RFC 2481                       ECN to IP                    January 1999


AUTHORS' ADDRESSES

   K. K. Ramakrishnan
   AT&T Labs. Research

   Phone: [phone]
   EMail: [e-mail]
   URL: http://www.research.att.com/info/kkrama


   Sally Floyd
   Lawrence Berkeley National Laboratory

   Phone: [phone]
   EMail: [e-mail]
   URL: http://www-nrg.ee.lbl.gov/floyd/



































Ramakrishnan & Floyd          Experimental                     [Page 24]

RFC 2481                       ECN to IP                    January 1999


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.
























Ramakrishnan & Floyd          Experimental                     [Page 25]