[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 4774

Internet Engineering Task Force                                 S. Floyd
INTERNET-DRAFT                                                      ICIR
draft-ietf-tsvwg-ecn-alternates-02.txt                 12 September 2006
Expires: March 2007


       Specifying Alternate Semantics for the Explicit Congestion
                        Notification (ECN) Field


Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    This Internet-Draft will expire on March 2007.

Copyright Notice

    Copyright (C) The Internet Society (2006).

Abstract

    There have been a number of proposals for alternate semantics for
    the ECN field in the IP header [RFC3168].  This document discusses
    some of the issues in defining alternate semantics for the ECN
    field, and specifies requirements for a safe co-existence in an



Floyd                                                           [Page 1]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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.

    NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.

    Changes from draft-ietf-tsvwg-ecn-alternates-01.txt:

    * Updated references, moved a paragraph to the Introduction.
      Based on feedback from the IESG.

    * Modified the caption to Figure 1, to clarify that this
      is a congested router.  Feedback from the Gen-ART
      review.

    * Added a paragraph to the conclusions about the role
      of this document.  From IESG review.

    * Added a new Section 5.4 on Encapsulated Packets.
      From IESG review.

    * Added text to the introduction about the difficulties of
      modifying routers.  From IESG review.

    * Added text to Section 4.2 on the difficulties of
      IP Options.  From IESG review.

    Changes from draft-ietf-tsvwg-ecn-alternates-00.txt:

    * Added a pointer to the SIGCOMM 2005 paper on "One More Bit
      is Enough".

    Changes from draft-floyd-ecn-alternates-02.txt:

    * Added a subsection on proposals for edge-to-edge ECN.

    * Changed name to draft-ietf-tsvwg-ecn-alternates-00.

    Changes from draft-floyd-ecn-alternates-01.txt:

    * Changed requirement for TCP friendliness, to a requirement of
    friendliness with IETF-conformant congestion control.  From email
    from Mark Allman.

    * Added to discussion of robustness to route changes.  From email
    from Mark Allman.




Floyd                                                           [Page 2]

INTERNET-DRAFT             Expires: March 2007            September 2006


    * Added an explicit note that the ECN nonce is agnostic to the
    semantics of the other codepoints, and could be used with alternate
    ECN semantics.

    * Minor editing, from email from Mark Allman.

    Changes from draft-floyd-ecn-alternates-00.txt:

    * Added requirements for compatibility between traffic using default
    ECN semantics and routers using alternate ECN semantics, to the
    section on "Option 3:  Friendly Co-existence with Competing
    Traffic".  From email from Gorry Fairhurst.

    * Added to the discussion of using the diffserv code point to signal
    alternate ECN semantics.  From email from Gorry Fairhurst.

    * Minor editing for clarity, also from email from Gorry Fairhurst.

    END OF NOTE TO RFC EDITOR.

                             Table of Contents

    1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   4
    2. An Overview of the Issues . . . . . . . . . . . . . . . . . .   5
    3. Signalling the Use of Alternate ECN Semantics . . . . . . . .   6
       3.1. Using the Diffserv Field for Signalling. . . . . . . . .   7
    4. Issues of Incremental Deployment. . . . . . . . . . . . . . .   7
       4.1. Option 1:  Unsafe for Deployment in the
       Internet. . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.2. Option 2:  Verification that Routers Under-
       stand the Alternate Semantics . . . . . . . . . . . . . . . .   9
       4.3. Option 3:  Friendly Co-existence with Com-
       peting Traffic. . . . . . . . . . . . . . . . . . . . . . . .  10
    5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . .  12
       5.1. Verification of Feedback from the Router . . . . . . . .  12
       5.2. Co-existence with Competing Traffic. . . . . . . . . . .  13
       5.3. Proposals for Alternate-ECN with Edge-to-
       Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . .  13
       5.4. Encapsulated Packets . . . . . . . . . . . . . . . . . .  14
       5.5. A General Evaluation of the Alternate-ECN
       Semantics . . . . . . . . . . . . . . . . . . . . . . . . . .  14
    6. Security Considerations . . . . . . . . . . . . . . . . . . .  14
    7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  14
    8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  14
    9. Normative References. . . . . . . . . . . . . . . . . . . . .  15
    10. Informative References . . . . . . . . . . . . . . . . . . .  15
    IANA Considerations. . . . . . . . . . . . . . . . . . . . . . .  16
    AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . .  16



Floyd                                                           [Page 3]

INTERNET-DRAFT             Expires: March 2007            September 2006


    Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  16
    Intellectual Property. . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

    RFC 3168, 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 an 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 ECN 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].

    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 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



Floyd                                               Section 1.  [Page 4]

INTERNET-DRAFT             Expires: March 2007            September 2006


    specifying alternate semantics for the ECN field, and gives
    requirements for a safe co-existence 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 no ECN at
    all; (3) co-existence 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 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 co-existence of the



Floyd                                               Section 2.  [Page 5]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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 co-exist 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 below.


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
    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



Floyd                                               Section 3.  [Page 6]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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.


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 co-
    existence 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



Floyd                                               Section 4.  [Page 7]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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)
    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



Floyd                                               Section 4.  [Page 8]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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 co-existence 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.  This would
    mean that it would be unsafe for packets using the alternate ECN
    semantics to be unleashed in the global Internet, in order to avoid
    the chance of the alternate-ECN traffic traversing an old router
    that doesn'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.


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



Floyd                                             Section 4.2.  [Page 9]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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 Co-existence 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
    co-exist 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, that 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 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 in order for alternate-ECN traffic to



Floyd                                            Section 4.3.  [Page 10]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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 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 diff-serv codepoint using default
    ECN semantics is redefined to use alternate ECN semantics, and
    traffic 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 diff-serv
    codepoint, and all packets with that diff-serv 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



Floyd                                            Section 4.3.  [Page 11]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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 co-exist 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
    receiver has more incentives for lying 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 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.




Floyd                                            Section 5.1.  [Page 12]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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.  Co-existence with Competing Traffic

    A second general issue concerns the co-existence 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
    co-existence of diffserv traffic with other traffic on the link;
    this should be addressed in the specification of the diffserv
    codepoint itself.


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



Floyd                                            Section 5.3.  [Page 13]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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.


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 co-existence with competing traffic.








Floyd                                              Section 7.  [Page 14]

INTERNET-DRAFT             Expires: March 2007            September 2006


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.K., Floyd, S., and Black, D., The Addition
    of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed
    Standard, September 2001.


10.  Informative References

    [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification
    Process for Real-Time Traffic, expired internet-draft draft-babiarz-
    tsvwg-rtecn-04, work in progress, July 2005.

    [BESFC06] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A.
    Charny, J.  Barbiaz, K. Chan, A Framework for Admission Control over
    DiffServ using Pre-Congestion Notification, internet-draft draft-
    briscoe-tsvwg-cl-architecture-03.txt, 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, Internet-draft draft-ietf-tsvwg-
    quickstart-05.txt, work in progress, July 2006.

    [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
    Control, RFC 2581, Proposed Standard, April 1999.

    [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best
    Current Practice, September 2000.

    [RFC2960] R. Stewart et al, Stream Control Transmission Protocol,
    RFC 2960, October 2000.

    [RFC3448] Handley, M., Floyd, S., Pahdye, J., and Widmer, J.  TCP
    Friendly Rate Control (TFRC): Protocol Specification.  RFC 3448,
    Proposed Standard, January 2003.



Floyd                                             Section 10.  [Page 15]

INTERNET-DRAFT             Expires: March 2007            September 2006


    [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit
    Congestion Notification (ECN) Signaling with Nonces, RFC 3540,
    Experimental, June 2003.

    [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding
    Congestion Control for Voice Traffic in the Internet, RFC 3714,
    Informational, March 2004.

    [RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
    Control Protocol (DCCP), RFC 4340, Proposed Standard, March 2006.

    [RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion
    Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion
    Control, RFC 4341, Proposed Standard, March 2006.

    [RFC4342] S. Floyd, E. Kohler, and J. Padhye, Profile for Datagram
    Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-
    Friendly Rate Control (TFRC), RFC 4342, Proposed Standard, March
    2006.

    [XSSK05] Y. Xia,  L. Subramanian, I. Stoica, and S. Kalyanaraman,
    One More Bit Is Enough, SIGCOMM 2005, September 2005.


IANA Considerations

    There are no IANA considerations in this document.


AUTHORS' ADDRESSES


    Sally Floyd
    Phone: +1 (510) 666-2989
    ICIR (ICSI Center for Internet Research)
    Email: floyd@icir.org
    URL: http://www.icir.org/floyd/


Full Copyright Statement

    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 AND THE



Floyd                                                          [Page 16]

INTERNET-DRAFT             Expires: March 2007            September 2006


    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.























Floyd                                                          [Page 17]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/