doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc4774.txt b/doc/rfc/rfc4774.txt
new file mode 100644
index 0000000..86d3b93
--- /dev/null
+++ b/doc/rfc/rfc4774.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                           S. Floyd
+Request for Comments: 4774                                          ICIR
+BCP: 124                                                   November 2006
+Category: Best Current Practice
+
+
+                  Specifying Alternate Semantics for
+            the Explicit Congestion Notification (ECN) Field
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2006).
+
+Abstract
+
+   There have been a number of proposals for alternate semantics for the
+   Explicit Congestion Notification (ECN) field in the IP header RFC
+   3168.  This document discusses some of the issues in defining
+   alternate semantics for the ECN field, and specifies requirements for
+   a safe coexistence in an Internet that could include routers that do
+   not understand the defined alternate semantics.  This document
+   evolved as a result of discussions with the authors of one recent
+   proposal for such alternate semantics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Floyd                    Best Current Practice                  [Page 1]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. An Overview of the Issues .......................................3
+   3. Signalling the Use of Alternate ECN Semantics ...................4
+      3.1. Using the Diffserv Field for Signalling ....................5
+   4. Issues of Incremental Deployment ................................6
+      4.1. Option 1:  Unsafe for Deployment in the Internet ...........7
+      4.2. Option 2:  Verification that Routers Understand the
+           Alternate ..................................................8
+      4.3. Option 3:  Friendly Coexistence with Competing Traffic .....8
+   5. Evaluation of the Alternate ECN Semantics ......................10
+      5.1. Verification of Feedback from the Router ..................10
+      5.2. Coexistence with Competing Traffic ........................11
+      5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics ...12
+      5.4. Encapsulated Packets ......................................12
+      5.5. A General Evaluation of the Alternate ECN Semantics .......12
+   6. Security Considerations ........................................12
+   7. Conclusions ....................................................13
+   8. Acknowledgements ...............................................13
+   9. Normative References ...........................................13
+   10. Informative References ........................................13
+
+1.  Introduction
+
+   [RFC3168], a Proposed Standard document, defines the ECN field in the
+   IP header, and specifies the semantics for the codepoints for the ECN
+   field.  However, end nodes could specify the use of alternate
+   semantics for the ECN field, e.g., using codepoints in the diffserv
+   field of the IP header.
+
+   There have been a number of proposals in the IETF and in the research
+   community for alternate semantics for the ECN codepoint.  One such
+   proposal, [BCF05], proposes alternate ECN semantics for real-time
+   inelastic traffic such as voice, video conferencing, and multimedia
+   streaming in DiffServ networks.  In this proposal, the alternate ECN
+   semantics would provide information about two levels of congestion
+   experienced along the path [BCF05].  Another research proposal,
+   [XSSK05], proposes a low-complexity protocol, Variable-structure
+   congestion Control Protocol (VCP), that uses the two bits in the ECN
+   field to indicate low-load, high-load, and overload (congestion),
+   where transport protocols can increase more rapidly during the low-
+   load regime.  Some of the proposals for alternate ECN semantics are
+   for when ECN is used in an edge-to-edge context between gateways at
+   the edge of a network region, e.g., for pre-congestion notification
+   for admissions control [BESFC06].  Other proposals for alternate ECN
+   semantics are listed on the ECN Web Page [ECN].
+
+
+
+
+Floyd                    Best Current Practice                  [Page 2]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+   The definition of multiple semantics for the ECN field could have
+   significant implications on both host and router implementations.
+   There is a huge base of installed hosts and routers in the Internet,
+   and in other IP networks, and updating these is an enormous and
+   potentially expensive undertaking.  Some existing devices might be
+   able to support the new ECN semantics with only a software upgrade
+   and without significant degradation in performance.  Some other
+   equipment might be able to support the new semantics, but with a
+   degradation in performance -- which could range from trivial to
+   catastrophic.  Some other deployed equipment might be able to support
+   the new ECN semantics only with a hardware upgrade, which, in some
+   cases, could be prohibitively expensive to deploy on a very wide
+   scale.  For these reasons, it would be difficult and would take a
+   significant amount of time to universally deploy any new ECN
+   semantics.  In particular, routers can be difficult to upgrade, since
+   small routers sometimes are not updated frequently, and large routers
+   commonly have specialized forwarding paths to facilitate high
+   performance.
+
+   This document describes some of the technical issues that arise in
+   specifying alternate semantics for the ECN field, and gives
+   requirements for a safe coexistence in a world using the default ECN
+   semantics (or using no ECN at all).
+
+2.  An Overview of the Issues
+
+   In this section, we discuss some of the issues that arise if some of
+   the traffic in a network consists of alternate-ECN traffic (i.e.,
+   traffic using alternate semantics for the ECN field).  The issues
+   include the following: (1) how routers know which ECN semantics to
+   use with which packets; (2) incremental deployment in a network where
+   some routers use only the default ECN semantics or do not use ECN at
+   all; (3) coexistence of alternate-ECN traffic with competing traffic
+   on the path; and (4) a general evaluation of the alternate ECN
+   semantics.
+
+   (1) The first issue concerns how routers know which ECN semantics to
+       use with which packets in the network:
+
+       How does the connection indicate to the router that its packets
+       are using alternate ECN semantics?  Is the specification of
+       alternate-ECN semantics robust and unambiguous?  If not, is this
+       a problem?
+
+       As an example, in most of the proposals for alternate ECN
+       semantics, a diffserv field is used to specify the use of
+       alternate ECN semantics.  Do all routers that understand this
+       diffserv codepoint understand that it uses alternate ECN
+
+
+
+Floyd                    Best Current Practice                  [Page 3]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+       semantics, or not?  Diffserv allows routers to re-mark DiffServ
+       Code Point (DSCP) values within the network; what is the effect
+       of this on the alternate ECN semantics?
+
+       This is discussed in more detail in Section 3 below.
+
+   (2) A second issue is that of incremental deployment in a network
+       where some routers only use the default ECN semantics, and other
+       routers might not use ECN at all.  In this document, we use the
+       phrase "new routers" to refer to the routers that understand the
+       alternate ECN semantics, and "old routers" to refer to routers
+       that don't understand or aren't willing to use the alternate ECN
+       semantics.
+
+       The possible existence of old routers raises the following
+       question:  How does the possible presence of old routers affect
+       the performance of the alternate-ECN connections?
+
+   (3) The possible existence of old routers also raises the question of
+       how the presence of old routers affects the coexistence of the
+       alternate-ECN traffic with competing traffic on the path.
+
+       Issues (2) and (3) are discussed in Section 4 below.
+
+   (4) A final issue is that of the general evaluation of the alternate
+       ECN semantics:
+
+       How well does the alternate-ECN traffic perform, and how well
+       does it coexist with competing traffic on the path, in a "clean"
+       environment with new routers and with the unambiguous
+       specification of the use of alternate ECN semantics?
+
+       These issues are discussed in Section 5.
+
+3.  Signalling the Use of Alternate ECN Semantics
+
+   This section discusses question (1) from Section 2:
+
+   (1) How does the connection indicate to the router that its packets
+       are using alternate ECN semantics?  Is the specification of
+       alternate ECN semantics robust and unambiguous?  If not, is this
+       a problem?
+
+   The assumption of this document is that when alternate semantics are
+   defined for the ECN field, a codepoint in the diffserv field is used
+   to signal the use of these alternate ECN semantics to the router.
+   That is, the end host sets the codepoint in the diffserv field to
+   indicate to routers that alternate semantics to the ECN field are
+
+
+
+Floyd                    Best Current Practice                  [Page 4]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+   being used.  Routers that understand this diffserv codepoint would
+   know to use the alternate semantics for interpreting and setting the
+   ECN field.  Old ECN-capable routers that do not understand this
+   diffserv codepoint would use the default ECN semantics in
+   interpreting and setting the ECN field.
+
+   In general, the diffserv codepoints are used to signal the per-hop
+   behavior at router queues.  One possibility would be to use one
+   diffserv codepoint to signal a per-hop behavior with the default ECN
+   semantics, and a separate diffserv codepoint to signal a similar
+   per-hop behavior with the alternate ECN semantics.  Another
+   possibility would be to use a diffserv codepoint to signal the use of
+   best-effort per-hop queueing and scheduling behavior, but with
+   alternate ECN semantics.  A detailed discussion of these issues is
+   beyond the scope of this document.
+
+   We note that this discussion does not exclude the possibility of
+   using other methods, including out-of-band mechanisms, for signalling
+   the use of alternate semantics for the ECN field.  The considerations
+   in the rest of this document apply regardless of the method used to
+   signal the use of alternate semantics for the ECN field.
+
+3.1.  Using the Diffserv Field for Signalling
+
+   We note that the default ECN semantics defined in RFC 3168 are the
+   current default semantics for the ECN field, regardless of the
+   contents of any other fields in the IP header.  In particular, the
+   default ECN semantics apply for more than best-effort traffic with a
+   codepoint of '000000' for the diffserv field - the default ECN
+   semantics currently apply regardless of the contents of the diffserv
+   field.
+
+   There are two ways to use the diffserv field to signal the use of
+   alternate ECN semantics.  One way is to use an existing diffserv
+   codepoint, and to modify the current definition of that codepoint,
+   through approved IETF processes, to specify the use of alternate ECN
+   semantics with that codepoint.  A second way is to define a new
+   diffserv codepoint, and to specify the use of alternate ECN semantics
+   with that codepoint.  We note that the first of these two mechanisms
+   raises the possibility that some routers along the path will
+   understand the diffserv codepoint but will use the default ECN
+   semantics with this diffserv codepoint, or won't use ECN at all, and
+   that other routers will use the alternate ECN semantics with this
+   diffserv codepoint.
+
+
+
+
+
+
+
+Floyd                    Best Current Practice                  [Page 5]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+4.  Issues of Incremental Deployment
+
+   This section discusses questions (2) and (3) posed in Section 2:
+
+   (2) How does the possible presence of old routers affect the
+       performance of the alternate-ECN connections?
+
+   (3) How does the possible presence of old routers affect the
+       coexistence of the alternate-ECN traffic with competing traffic
+       on the path?
+
+   When alternate semantics are defined for the ECN field, it is
+   necessary to ensure that there are no problems caused by old routers
+   along the path that don't understand the alternate ECN semantics.
+
+   One possible problem is that of poor performance for the alternate-
+   ECN traffic.  Is it essential to the performance of the alternate-ECN
+   traffic that all routers along the path understand the alternate ECN
+   semantics?  If not, what are the possible consequences, for the
+   alternate-ECN traffic itself, when some old routers along the path
+   don't understand the alternate ECN semantics?  These issues have to
+   be answered in the context of each specific proposal for alternate
+   ECN semantics.
+
+   A second specific problem is that of possible unfair competition with
+   other traffic along the path.  If there is an old router along the
+   path that doesn't use ECN, that old router could drop packets from
+   the alternate-ECN traffic, and expect the alternate-ECN traffic to
+   reduce its sending rate as a result.  Does the alternate-ECN traffic
+   respond to packet drops as an indication of congestion?
+
+                                  |--------|
+     Alternate-ECN traffic ---->  |        | ---> CE-marked packet
+                                  |  Old   |
+     Non-ECN traffic ---------->  | Router | ---> dropped packet
+                                  |        |
+     RFC-3168 ECN traffic ----->  |        | ---> CE-marked packet
+                                  |--------|
+
+    Figure 1: Alternate-ECN traffic, an old router, using RFC-3168 ECN,
+     that is congested and ready to drop or mark the arriving packet.
+
+   Similarly, what if there is an old router along the path that
+   understands only the default ECN semantics from RFC 3168, as in
+   Figure 1 above?  In times of congestion, the old default-ECN router
+   could see an alternate-ECN packet with one of the ECN-Capable
+   Transport (ECT) codepoints set in the ECN field in the IP header, as
+   defined in RFC 3168, and set the Congestion Experienced (CE)
+
+
+
+Floyd                    Best Current Practice                  [Page 6]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+   codepoint in the ECN field as an alternative to dropping the packet.
+   The router in this case would expect the alternate-ECN connection to
+   respond, in terms of congestion control, as it would if the packet
+   has been dropped.  If the alternate-ECN traffic fails to respond
+   appropriately to the CE codepoint being set by an old router, this
+   could increase the aggregate traffic arriving at the old router,
+   resulting in an increase in the packet-marking and packet-dropping
+   rates at that router, further resulting in the alternate-ECN traffic
+   crowding out the other traffic competing for bandwidth on that link.
+
+   Basically, there are three possibilities for avoiding scenarios where
+   the presence of old routers along the path results in the alternate-
+   ECN traffic competing unfairly with other traffic along the path:
+
+   Option 1:  Alternate-ECN traffic is clearly understood as unsafe for
+   deployment in the global Internet; or
+
+   Option 2:  All alternate-ECN traffic deploys some mechanism for
+   verifying that all routers on the path understand and agree to use
+   the alternate ECN semantics for this traffic; or
+
+   Option 3:  The alternate ECN semantics are defined in such a way as
+   to ensure the fair and peaceful coexistence of the alternate-ECN
+   traffic with best-effort and other traffic, even in environments that
+   include old routers that do not understand the alternate ECN
+   semantics.
+
+   Each of these alternatives is explored in more detail below.
+
+4.1.  Option 1:  Unsafe for Deployment in the Internet
+
+   The first option specified above is for the alternate-ECN traffic to
+   be clearly understood as only suitable for enclosed environments, and
+   as unsafe for deployment in the global Internet.  Specifically, this
+   would mean that it would be unsafe for packets using the alternate
+   ECN semantics to be unleashed in the global Internet.  This
+   restriction would prevent the alternate-ECN traffic from traversing
+   an old router outside of the enclosed environment that didn't
+   understand the alternate semantics.  This document doesn't comment on
+   whether a mechanism would be required to ensure that the alternate
+   ECN semantics would not be let loose on the global Internet.  This
+   document also doesn't comment on the chances that this scenario would
+   be considered acceptable for standardization by the IETF community.
+
+
+
+
+
+
+
+
+Floyd                    Best Current Practice                  [Page 7]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+4.2.  Option 2:  Verification that Routers Understand the Alternate
+      Semantics
+
+   The second option specified above is for the alternate-ECN traffic to
+   include a mechanism for ensuring that all routers along the path
+   understand and agree to the use of the alternate ECN semantics for
+   this traffic.  As an example, such a mechanism could consist of a
+   field in an IP option that all routers along the path decrement if
+   they agree to use the alternate ECN semantics with this traffic.  (A
+   similar mechanism is proposed for Quick-Start, for verifying that all
+   of the routers along the path understand the Quick-Start IP Option
+   [QuickStart].)  Using such a mechanism, a sender could have
+   reasonable assurance that the packets that are sent specifying the
+   use of alternate ECN semantics only traverse routers that, in fact,
+   understand and agree to use these alternate semantics for these
+   packets.  Note, however, that most existing routers are optimized for
+   IP packets with no options, or with only some very well-known and
+   simple IP options.  Thus, the definition and use of any new IP option
+   may have a serious detrimental effect on the performance of many
+   existing IP routers.
+
+   Such a mechanism should be robust in the presence of paths with
+   multi-path routing, and in the presence of routing or configuration
+   changes along the path while the connection is in use.  In
+   particular, if this option is used, connections could include some
+   form of monitoring for changes in path behavior and/or periodic
+   monitoring that all routers along the path continue to understand the
+   alternate ECN semantics.
+
+4.3.  Option 3:  Friendly Coexistence with Competing Traffic
+
+   The third option specified above is for the alternate ECN semantics
+   to be defined so that traffic using the alternate semantics would
+   coexist safely in the Internet on a path with one or more old routers
+   that use only the default ECN semantics.  In this scenario, a
+   connection sending alternate-ECN traffic would have to respond
+   appropriately to a CE packet (a packet with the ECN codepoint "11")
+   received at the receiver, using a conformant congestion control
+   response.  Hopefully, the connection sending alternate-ECN traffic
+   would also respond appropriately to a dropped packet, which could be
+   a congestion indication from a router that doesn't use ECN.
+
+   RFC 3168 defines the default ECN semantics as follows:
+
+   "Upon the receipt by an ECN-Capable transport of a single CE packet,
+   the congestion control algorithms followed at the end-systems MUST be
+   essentially the same as the congestion control response to a *single*
+   dropped packet.  For example, for ECN-Capable TCP the source TCP is
+
+
+
+Floyd                    Best Current Practice                  [Page 8]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+   required to halve its congestion window for any window of data
+   containing either a packet drop or an ECN indication."
+
+   The only conformant congestion control mechanisms currently
+   standardized in the IETF are TCP [RFC2581] and protocols using TCP-
+   like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2
+   ([RFC4340], [RFC4341])), and TCP-Friendly Rate Control (TFRC)
+   [RFC3448], and protocols with TFRC-like congestion control (e.g.,
+   DCCP using CCID-3 [RFC4342]).  TCP uses Additive-Increase
+   Multiplicative-Decrease congestion control, and responds to the loss
+   or ECN-marking of a single packet by halving its congestion window.
+   In contrast, the equation-based congestion control mechanism in TFRC
+   estimates the loss event rate over some period of time, and uses a
+   sending rate that would be comparable, in packets per round-trip-
+   time, to that of a TCP connection experiencing the same loss event
+   rate.
+
+   So what are the requirements for alternate-ECN traffic to compete
+   appropriately with other traffic on a path through an old router that
+   doesn't understand the alternate ECN semantics (and therefore might
+   be using the default ECN semantics)?  The first and second
+   requirements below concern compatibility between traffic using
+   alternate ECN semantics and routers using default ECN semantics.
+
+   The first requirement for compatibility with routers using default
+   ECN is that if a packet is marked with the ECN codepoint "11" in the
+   network, this marking is not changed on the packet's way to the
+   receiver (unless the packet is dropped before it reaches the
+   receiver).  This requirement is necessary to ensure that congestion
+   indications from a default-ECN router make it to the transport
+   receiver.
+
+   A second requirement for compatibility with routers using default ECN
+   is that the end-nodes respond to packets that are marked with the ECN
+   codepoint "11" in a way that is friendly to flows using IETF-
+   conformant congestion control.  This requirement is needed because
+   the "11"-marked packets might have come from a congested router that
+   understands only the default ECN semantics, and that expects that
+   end-nodes will respond appropriately to CE packets.  This requirement
+   would ensure that the traffic using the alternate semantics does not
+   `bully' competing traffic that it might encounter along the path, and
+   that it does not drive up congestion on the shared link
+   inappropriately.
+
+   Additional requirements concern compatibility between traffic using
+   default ECN semantics and routers using alternate ECN semantics.
+   This situation could occur if a diffserv codepoint using default ECN
+   semantics is redefined to use alternate ECN semantics, and traffic
+
+
+
+Floyd                    Best Current Practice                  [Page 9]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+   from an "old" source traverses a "new" router.  If the router "knows"
+   that a packet is from a sender using alternate semantics (e.g.,
+   because the packet is using a certain diffserv codepoint, and all
+   packets with that diffserv codepoint use alternate semantics for the
+   ECN field), then the requirements below are not necessary, and the
+   rules for the alternate semantics apply.
+
+   A requirement for compatibility with end-nodes using default ECN is
+   that if a packet that *could* be using default semantics is marked
+   with the ECN codepoint "00", this marking must not be changed to
+   "01", "10", or "11" in the network.  This prevents the packet from
+   being represented incorrectly to a default-ECN router downstream as
+   ECN-Capable.  Similarly, if a packet that *could* be using default
+   semantics is marked with the ECN codepoint "01", then this codepoint
+   should not be changed to "10" in the network (and a "10" codepoint
+   should not be changed to "01").  This requirement is necessary to
+   avoid interference with the transport protocol's use of the ECN nonce
+   [RFC3540].
+
+   As discussed earlier, the current conformant congestion control
+   responses to a dropped or default-ECN-marked packet consist of TCP
+   and TCP-like congestion control, and of TFRC (TCP-Friendly Rate
+   Control).  Another possible response considered in RFC 3714, but not
+   standardized in a standards-track document, is that of simply
+   terminating an alternate-ECN connection for a period of time if the
+   long-term sending rate is higher than would be that of a TCP
+   connection experiencing the same packet dropping or marking rates
+   [RFC3714].  We note that the use of such a congestion control
+   response to CE-marked packets would require specification of time
+   constants for measuring the loss rates and for stopping transmission,
+   and would require a consideration of issues of packet size.
+
+5.  Evaluation of the Alternate ECN Semantics
+
+   This section discusses question (4) posed in Section 2:
+
+   (4) How well does the alternate-ECN traffic perform, and how well
+       does it coexist with competing traffic on the path, in a "clean"
+       environment with new routers and with the unambiguous
+       specification of the use of alternate ECN semantics?
+
+5.1.  Verification of Feedback from the Router
+
+   One issue in evaluating the alternate ECN semantics concerns
+   mechanisms to discourage lying from the transport receiver to the
+   transport sender.  In many cases, the sender is a server that has an
+   interest in using the alternate ECN semantics correctly, while the
+
+
+
+
+Floyd                    Best Current Practice                 [Page 10]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+   receiver has more incentive to lie about the congestion experienced
+   along the path.
+
+   In the default ECN semantics, two of the four ECN codepoints are used
+   for ECN-Capable(0) and ECN-Capable(1).  The use of two codepoints for
+   ECN-Capable, instead of one, permits the data sender to verify the
+   receiver's reports that packets were actually received unmarked at
+   the receiver.  In particular, the sender can specify that the
+   receiver report to the sender whether each unmarked packet was
+   received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC 3540
+   [RFC3540].  This use of ECN-Capable(0) and ECN-Capable(1) is
+   independent of the semantics of the other ECN codepoints, and could
+   be used, if desired, with alternate semantics for the other
+   codepoints.
+
+   If alternate semantics for the ECN codepoint don't include the use of
+   two separate codepoints to indicate ECN-Capable, then the connections
+   using those semantics have lost the ability to verify that the data
+   receiver is accurately reporting the received ECN codepoint to the
+   data sender.  In this case, it might be necessary for the alternate-
+   ECN framework to include alternate mechanisms for ensuring that the
+   data receiver is reporting feedback appropriately to the sender.  As
+   one possibility, policers could be used in routers to ensure that end
+   nodes are responding appropriately to marked packets.
+
+5.2.  Coexistence with Competing Traffic
+
+   A second general issue concerns the coexistence of alternate-ECN
+   traffic with competing traffic along the path, in a clean environment
+   where all routers understand and are willing to use the alternate ECN
+   semantics for the traffic that specifies its use.
+
+   If the traffic using the alternate ECN semantics is best-effort
+   traffic, then it is subject to the general requirement of fair
+   competition with TCP and other traffic along the path [RFC2914].
+
+   If the traffic using the alternate ECN semantics is diffserv traffic,
+   then the requirements are governed by the overall guidelines for that
+   class of diffserv traffic.  It is beyond the scope of this document
+   to specify the requirements, if any, for the coexistence of diffserv
+   traffic with other traffic on the link; this should be addressed in
+   the specification of the diffserv codepoint itself.
+
+
+
+
+
+
+
+
+
+Floyd                    Best Current Practice                 [Page 11]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+5.3.  Proposals for Alternate ECN with Edge-to-Edge Semantics
+
+   RFC 3168 specifies the use of the default ECN semantics by an end-
+   to-end transport protocol, with the requirement that "upon the
+   receipt by an ECN-Capable transport of a single CE packet, the
+   congestion control algorithms followed at the end-systems MUST be
+   essentially the same as the congestion control response to a *single*
+   dropped packet" ([RFC3168], Section 5).  In contrast, some of the
+   proposals for alternate ECN semantics are for ECN used in an edge-
+   to-edge context between gateways at the edge of a network region,
+   e.g., [BESFC06].
+
+   When alternate ECN is defined with edge-to-edge semantics, this
+   definition needs to ensure that the edge-to-edge semantics do not
+   conflict with a connection using other ECN semantics end-to-end.  One
+   way to avoid conflict would be for the edge-to-edge ECN proposal to
+   include some mechanism to ensure that the edge-to-edge ECN is not
+   used for connections that are using other ECN semantics (standard or
+   otherwise) end-to-end.  Alternately, the edge-to-edge semantics could
+   be defined so that they do not conflict with a connection using other
+   ECN semantics end-to-end.
+
+5.4.  Encapsulated Packets
+
+   RFC 3168 has an extensive discussion of the interactions between ECN
+   and IP tunnels, including IPsec and IP in IP.  Proposals for
+   alternate ECN semantics might interact with IP tunnels differently
+   than default ECN.  As a result, proposals for alternate ECN semantics
+   must explicitly consider the issue of interactions with IP tunnels.
+
+5.5.  A General Evaluation of the Alternate ECN Semantics
+
+   A third general issue concerns the evaluation of the general merits
+   of the proposed alternate ECN semantics.  Again, it would be beyond
+   the scope of this document to specify requirements for the general
+   evaluation of alternate ECN semantics.
+
+6.  Security Considerations
+
+   This document doesn't propose any new mechanisms for the Internet
+   protocol, and therefore doesn't introduce any new security
+   considerations.
+
+
+
+
+
+
+
+
+
+Floyd                    Best Current Practice                 [Page 12]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+7.  Conclusions
+
+   This document has discussed some of the issues to be considered in
+   the specification of alternate semantics for the ECN field in the IP
+   header.
+
+   Specifications of alternate ECN semantics must clearly state how they
+   address the issues raised in this document, particularly the issues
+   discussed in Section 2.  In addition, specifications for alternate
+   ECN semantics must meet the requirements in Section 5.2 for
+   coexistence with competing traffic.
+
+8.  Acknowledgements
+
+   This document is based in part on conversations with Jozef Babiarz,
+   Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate
+   use of the ECN field in DiffServ environments.  Many thanks to
+   Francois Le Faucheur for feedback recommending that the document
+   include a section at the beginning discussing the potential issues
+   that need to be addressed.  Thanks also to Mark Allman, Fred Baker,
+   David Black, Gorry Fairhurst, and to members of the TSVWG working
+   group for feedback on these issues.
+
+9.  Normative References
+
+   [RFC3168]    Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+                of Explicit Congestion Notification (ECN) to IP", RFC
+                3168, September 2001.
+
+10.  Informative References
+
+   [BCF05]      Babiarz, J., Chan, K., and V. Firoiu, "Congestion
+                Notification Process for Real-Time Traffic", Work in
+                Progress, July 2005.
+
+   [BESFC06]    Briscoe, B., et al., "An edge-to-edge Deployment Model
+                for Pre-Congestion Notification: Admission Control over
+                a DiffServ Region", Work in Progress, June 2006.
+
+   [ECN]        ECN Web Page, URL <www.icir.org/floyd/ecn.html>.
+
+   [QuickStart] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, "Quick-
+                Start for TCP and IP", Work in Progress, October 2006.
+
+   [RFC2581]    Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
+                Control", RFC 2581, April 1999.
+
+
+
+
+
+Floyd                    Best Current Practice                 [Page 13]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+   [RFC2914]    Floyd, S., "Congestion Control Principles", BCP 41, RFC
+                2914, September 2000.
+
+   [RFC2960]    Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
+                Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
+                Zhang, L., and V. Paxson, "Stream Control Transmission
+                Protocol", RFC 2960, October 2000.
+
+   [RFC3448]    Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
+                Friendly Rate Control (TFRC): Protocol Specification",
+                RFC 3448, January 2003.
+
+   [RFC3540]    Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
+                Congestion Notification (ECN) Signaling with Nonces",
+                RFC 3540, June 2003.
+
+   [RFC3714]    Floyd, S. and J. Kempf, "IAB Concerns Regarding
+                Congestion Control for Voice Traffic in the Internet",
+                RFC 3714, March 2004.
+
+   [RFC4340]    Kohler, E., Handley, M., and S. Floyd, "Datagram
+                Congestion Control Protocol (DCCP)", RFC 4340, March
+                2006.
+
+   [RFC4341]    Floyd, S. and E. Kohler, "Profile for Datagram
+                Congestion Control Protocol (DCCP) Congestion Control ID
+                2: TCP-like Congestion Control", RFC 4341, March 2006.
+
+   [RFC4342]    Floyd, S., Kohler, E., and J. Padhye, "Profile for
+                Datagram Congestion Control Protocol (DCCP) Congestion
+                Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC
+                4342, March 2006.
+
+   [XSSK05]     Y. Xia,  L. Subramanian, I. Stoica, and S. Kalyanaraman,
+                One More Bit Is Enough, SIGCOMM 2005, September 2005.
+
+Author's Address
+
+   Sally Floyd
+   ICIR (ICSI Center for Internet Research)
+
+   Phone: +1 (510) 666-2989
+   EMail: floyd@icir.org
+   URL: http://www.icir.org/floyd/
+
+
+
+
+
+
+
+Floyd                    Best Current Practice                 [Page 14]
+
+RFC 4774         Alternate Semantics for the ECN Field     November 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
+   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Floyd                    Best Current Practice                 [Page 15]
+