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

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/