draft-ietf-tsvwg-ecn-alternates-01.txt   draft-ietf-tsvwg-ecn-alternates-02.txt 
Internet Engineering Task Force S. Floyd Internet Engineering Task Force S. Floyd
INTERNET-DRAFT ICIR INTERNET-DRAFT ICIR
Expires: January 2007
Specifying Alternate Semantics for the Explicit Congestion Specifying Alternate Semantics for the Explicit Congestion
Notification (ECN) Field Notification (ECN) Field
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 33 skipping to change at page 1, line 30
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2007. This Internet-Draft will expire on March 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
There have been a number of proposals for alternate semantics for There have been a number of proposals for alternate semantics for
the ECN field in the IP header [RFC3168]. This document discusses the ECN field in the IP header [RFC3168]. This document discusses
some of the issues in defining alternate semantics for the ECN some of the issues in defining alternate semantics for the ECN
skipping to change at page 2, line 16 skipping to change at page 2, line 16
discussions with the authors of one recent proposal for such discussions with the authors of one recent proposal for such
alternate semantics. alternate semantics.
NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION. NOTE TO RFC EDITOR: PLEASE DELETE THIS NOTE UPON PUBLICATION.
Changes from draft-ietf-tsvwg-ecn-alternates-01.txt: Changes from draft-ietf-tsvwg-ecn-alternates-01.txt:
* Updated references, moved a paragraph to the Introduction. * Updated references, moved a paragraph to the Introduction.
Based on feedback from the IESG. 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: Changes from draft-ietf-tsvwg-ecn-alternates-00.txt:
* Added a pointer to the SIGCOMM 2005 paper on "One More Bit * Added a pointer to the SIGCOMM 2005 paper on "One More Bit
is Enough". is Enough".
Changes from draft-floyd-ecn-alternates-02.txt: Changes from draft-floyd-ecn-alternates-02.txt:
* Added a subsection on proposals for edge-to-edge ECN. * Added a subsection on proposals for edge-to-edge ECN.
* Changed name to draft-ietf-tsvwg-ecn-alternates-00. * Changed name to draft-ietf-tsvwg-ecn-alternates-00.
skipping to change at page 3, line 11 skipping to change at page 3, line 27
* Added to the discussion of using the diffserv code point to signal * Added to the discussion of using the diffserv code point to signal
alternate ECN semantics. From email from Gorry Fairhurst. alternate ECN semantics. From email from Gorry Fairhurst.
* Minor editing for clarity, also from email from Gorry Fairhurst. * Minor editing for clarity, also from email from Gorry Fairhurst.
END OF NOTE TO RFC EDITOR. END OF NOTE TO RFC EDITOR.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 4 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 5
3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 5 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 6
3.1. Using the Diffserv Field for Signalling. . . . . . . . . 6 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 7
4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 6 4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 7
4.1. Option 1: Unsafe for Deployment in the 4.1. Option 1: Unsafe for Deployment in the
Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Option 2: Verification that Routers Under- 4.2. Option 2: Verification that Routers Under-
stand the Alternate Semantics . . . . . . . . . . . . . . . . 8 stand the Alternate Semantics . . . . . . . . . . . . . . . . 9
4.3. Option 3: Friendly Co-existence with Com- 4.3. Option 3: Friendly Co-existence with Com-
peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 9 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 10
5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 11 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 12
5.1. Verification of Feedback from the Router . . . . . . . . 11 5.1. Verification of Feedback from the Router . . . . . . . . 12
5.2. Co-existence with Competing Traffic. . . . . . . . . . . 12 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 13
5.3. Proposals for Alternate-ECN with Edge-to- 5.3. Proposals for Alternate-ECN with Edge-to-
Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . . 12 Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. A General Evaluation of the Alternate-ECN 5.4. Encapsulated Packets . . . . . . . . . . . . . . . . . . 14
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. A General Evaluation of the Alternate-ECN
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 13 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Normative References. . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . 14 9. Normative References. . . . . . . . . . . . . . . . . . . . . 15
IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 15 10. Informative References . . . . . . . . . . . . . . . . . . . 15
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 15 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
RFC 3168, a Proposed Standard document, defines the ECN field in the RFC 3168, a Proposed Standard document, defines the ECN field in the
IP header, and specifies the semantics for the codepoints for the IP header, and specifies the semantics for the codepoints for the
ECN field. However, end nodes could specify the use of alternate ECN field. However, end nodes could specify the use of alternate
semantics for the ECN field, e.g., using codepoints in the diffserv semantics for the ECN field, e.g., using codepoints in the diffserv
field of the IP header. field of the IP header.
There have been a number of proposals in the IETF and in the There have been a number of proposals in the IETF and in the
skipping to change at page 4, line 15 skipping to change at page 4, line 32
proposal, [XSSK05], proposes a low-complexity protocol, Variable- proposal, [XSSK05], proposes a low-complexity protocol, Variable-
structure congestion Control Protocol (VCP), that uses the two bits structure congestion Control Protocol (VCP), that uses the two bits
in the ECN field to indicate low-load, high-load, and overload in the ECN field to indicate low-load, high-load, and overload
(congestion), where transport protocols can increase more rapidly (congestion), where transport protocols can increase more rapidly
during the low-load regime. Some of the proposals for alternate-ECN during the low-load regime. Some of the proposals for alternate-ECN
semantics are for ECN used in an edge-to-edge context between 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 gateways at the edge of a network region, e.g., for pre-congestion
notification for admissions control [BESFC06]. Other proposals for notification for admissions control [BESFC06]. Other proposals for
alternate ECN semantics are listed on the ECN Web Page [ECN]. alternate ECN semantics are listed on the ECN Web Page [ECN].
This document describes some of the issues that arise in specifying The definition of multiple semantics for the ECN field could have
alternate semantics for the ECN field, and gives requirements for a significant implications on both host and router implementations.
safe co-existence in a world using the default ECN semantics (or There is a huge base of installed hosts and routers in the Internet,
using no ECN at all). 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
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 2. An Overview of the Issues
In this section we discuss some of the issues that arise if some of 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., the traffic in a network consists of alternate-ECN traffic (i.e.,
traffic using alternate semantics for the ECN field). The issues traffic using alternate semantics for the ECN field). The issues
include the following: (1) how routers know which ECN semantics to include the following: (1) how routers know which ECN semantics to
use with which packets; (2) incremental deployment in a network use with which packets; (2) incremental deployment in a network
where some routers use only the default ECN semantics, or no ECN at where some routers use only the default ECN semantics, or no ECN at
all; (3) co-existence of alternate-ECN traffic with competing all; (3) co-existence of alternate-ECN traffic with competing
skipping to change at page 7, line 36 skipping to change at page 8, line 24
traffic respond to packet drops as an indication of congestion? traffic respond to packet drops as an indication of congestion?
|--------| |--------|
Alternate-ECN traffic ----> | | ---> CE-marked packet Alternate-ECN traffic ----> | | ---> CE-marked packet
| Old | | Old |
Non-ECN traffic ----------> | Router | ---> dropped packet Non-ECN traffic ----------> | Router | ---> dropped packet
| | | |
RFC-3168 ECN traffic -----> | | ---> CE-marked packet RFC-3168 ECN traffic -----> | | ---> CE-marked packet
|--------| |--------|
Figure 1: Alternate-ECN traffic, an old router using RFC-3168 ECN. 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 Similarly, what if there is an old router along the path that
understands only the default ECN semantics from RFC-3168, as in understands only the default ECN semantics from RFC-3168, as in
Figure 1 above? In times of congestion, the old default-ECN router Figure 1 above? In times of congestion, the old default-ECN router
could see an alternate-ECN packet with one of the ECN-Capable 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 Transport (ECT) codepoints set in the ECN field in the IP header, as
defined in RFC 3168, and set the Congestion Experienced (CE) defined in RFC 3168, and set the Congestion Experienced (CE)
codepoint in the ECN field as an alternative to dropping the packet. codepoint in the ECN field as an alternative to dropping the packet.
The router in this case would expect the alternate-ECN connection to The router in this case would expect the alternate-ECN connection to
respond, in terms of congestion control, as it would if the packet respond, in terms of congestion control, as it would if the packet
skipping to change at page 8, line 36 skipping to change at page 9, line 24
Each of these alternatives is explored in more detail below. Each of these alternatives is explored in more detail below.
4.1. Option 1: Unsafe for Deployment in the Internet 4.1. Option 1: Unsafe for Deployment in the Internet
The first option specified above is for the alternate-ECN traffic to The first option specified above is for the alternate-ECN traffic to
be clearly understood as only suitable for enclosed environments, be clearly understood as only suitable for enclosed environments,
and as unsafe for deployment in the global Internet. This would and as unsafe for deployment in the global Internet. This would
mean that it would be unsafe for packets using the alternate ECN mean that it would be unsafe for packets using the alternate ECN
semantics to be unleashed in the global Internet, in order to avoid semantics to be unleashed in the global Internet, in order to avoid
the chance of the alternate-ECN traffic traversing an old router the chance of the alternate-ECN traffic traversing an old router
that don't understand the alternate semantics. This document that doesn't understand the alternate semantics. This document
doesn't comment on whether a mechanism would be required to ensure doesn't comment on whether a mechanism would be required to ensure
that the alternate-ECN semantics would not be let loose on the that the alternate-ECN semantics would not be let loose on the
global Internet. This document also doesn't comment on the chances global Internet. This document also doesn't comment on the chances
that this scenario would be considered acceptable for that this scenario would be considered acceptable for
standardization by the IETF community. standardization by the IETF community.
4.2. Option 2: Verification that Routers Understand the Alternate 4.2. Option 2: Verification that Routers Understand the Alternate
Semantics Semantics
The second option specified above is for the alternate-ECN traffic The second option specified above is for the alternate-ECN traffic
skipping to change at page 9, line 12 skipping to change at page 9, line 46
understand and agree to the use of the alternate ECN semantics for understand and agree to the use of the alternate ECN semantics for
this traffic. As an example, such a mechanism could consist of a 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 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 they agree to use the alternate ECN semantics with this traffic. (A
similar mechanism is proposed for Quick-Start, for verifying that similar mechanism is proposed for Quick-Start, for verifying that
all of the routers along the path understand the Quick-Start IP all of the routers along the path understand the Quick-Start IP
Option [QuickStart].) Using such a mechanism, a sender could have Option [QuickStart].) Using such a mechanism, a sender could have
reasonable assurance that the packets that are sent specifying the reasonable assurance that the packets that are sent specifying the
use of alternate ECN semantics only traverse routers that in fact use of alternate ECN semantics only traverse routers that in fact
understand and agree to use these alternate semantics for these understand and agree to use these alternate semantics for these
packets. 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 Such a mechanism should be robust in the presence of paths with
multi-path routing, and in the presence of routing or configuration multi-path routing, and in the presence of routing or configuration
changes along the path while the connection is in use. In changes along the path while the connection is in use. In
particular, if this option is used, connections could include some particular, if this option is used, connections could include some
form of monitoring for changes in path behavior, and/or periodic form of monitoring for changes in path behavior, and/or periodic
monitoring that all routers along the path continue to understand monitoring that all routers along the path continue to understand
the alternate-ECN semantics. the alternate-ECN semantics.
4.3. Option 3: Friendly Co-existence with Competing Traffic 4.3. Option 3: Friendly Co-existence with Competing Traffic
skipping to change at page 13, line 18 skipping to change at page 14, line 10
When alternate-ECN is defined with edge-to-edge semantics, this When alternate-ECN is defined with edge-to-edge semantics, this
definition needs to ensure that the edge-to-edge semantics do not definition needs to ensure that the edge-to-edge semantics do not
conflict with a connection using other ECN semantics end-to-end. 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 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 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 used for connections that are using other ECN semantics (standard or
otherwise) end-to-end. Alternately, the edge-to-edge semantics otherwise) end-to-end. Alternately, the edge-to-edge semantics
could be defined so that they do not conflict with a connection could be defined so that they do not conflict with a connection
using other ECN semantics end-to-end. using other ECN semantics end-to-end.
5.4. A General Evaluation of the Alternate-ECN Semantics 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 A third general issue concerns the evaluation of the general merits
of the proposed alternate-ECN semantics. Again, it would be beyond of the proposed alternate-ECN semantics. Again, it would be beyond
the scope of this document to specify requirements for the general the scope of this document to specify requirements for the general
evaluation of alternate-ECN semantics. evaluation of alternate-ECN semantics.
6. Security Considerations 6. Security Considerations
This document doesn't propose any new mechanisms for the Internet This document doesn't propose any new mechanisms for the Internet
protocol, and therefore doesn't introduce any new security protocol, and therefore doesn't introduce any new security
considerations. considerations.
7. Conclusions 7. Conclusions
This document has discussed some of the issues to be considered in This document has discussed some of the issues to be considered in
the specification of alternate semantics for the ECN field in the IP the specification of alternate semantics for the ECN field in the IP
header. 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.
8. Acknowledgements 8. Acknowledgements
This document is based in part on conversations with Jozef Babiarz, This document is based in part on conversations with Jozef Babiarz,
Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate Kwok Ho Chan, and Victor Firoiu on their proposal for an alternate
use of the ECN field in DiffServ environments. Many thanks to use of the ECN field in DiffServ environments. Many thanks to
Francois Le Faucheur for feedback recommending that the document Francois Le Faucheur for feedback recommending that the document
include a section at the beginning discussing the potential issues include a section at the beginning discussing the potential issues
that need to be addressed. Thanks also to Mark Allman, Fred Baker, that need to be addressed. Thanks also to Mark Allman, Fred Baker,
David Black, Gorry Fairhurst, and to members of the TSVWG working David Black, Gorry Fairhurst, and to members of the TSVWG working
group for feedback on these issues. group for feedback on these issues.
 End of changes. 14 change blocks. 
35 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/