< draft-floyd-ecn-alternates-01.txt   draft-floyd-ecn-alternates-02.txt >
Internet Engineering Task Force S. Floyd Internet Engineering Task Force S. Floyd
INTERNET-DRAFT ICIR INTERNET-DRAFT ICIR
draft-floyd-ecn-alternates-01.txt 11 July 2005 draft-floyd-ecn-alternates-02.txt 18 August 2005
Expires: January 2006 Expires: February 2006
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
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 2006. This Internet-Draft will expire on February 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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 [ECN]. This document discusses some the ECN field in the IP header [ECN]. This document discusses some
of the issues in defining alternate semantics for the ECN field, and of the issues in defining alternate semantics for the ECN field, and
specifies requirements for a safe co-existence in an Internet that specifies requirements for a safe co-existence in an Internet that
could include routers that do not understand the defined alternate could include routers that do not understand the defined alternate
semantics. This document evolved as a result of discussions with semantics. This document evolved as a result of discussions with
the authors of one recent proposal for such alternate semantics. the authors of one recent proposal for such 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-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: Changes from draft-floyd-ecn-alternates-00.txt:
* Added requirements for compatibility between traffic using default * Added requirements for compatibility between traffic using default
ECN semantics and routers using alternate ECN semantics, to the ECN semantics and routers using alternate ECN semantics, to the
section on "Option 3: Friendly Co-existence with Competing section on "Option 3: Friendly Co-existence with Competing
Traffic". From email from Gorry Fairhurst. Traffic". From email from Gorry Fairhurst.
* 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. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 3 2. An Overview of the Issues . . . . . . . . . . . . . . . . . . 3
3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 4 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 4
3.1. Using the Diffserv Field for Signalling. . . . . . . . . 5 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 5
4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 5 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. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Option 2: Verification that Routers Under- 4.2. Option 2: Verification that Routers Under-
stand the Alternate Semantics . . . . . . . . . . . . . . . . 7 stand the Alternate Semantics . . . . . . . . . . . . . . . . 8
4.3. Option 3: Friendly Co-existence with Com- 4.3. Option 3: Friendly Co-existence with Com-
peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 8 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 8
5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 10 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 11
5.1. Verification of Feedback from the Router . . . . . . . . 10 5.1. Verification of Feedback from the Router . . . . . . . . 11
5.2. Co-existence with Competing Traffic. . . . . . . . . . . 11 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 11
5.3. A General Evaluation of the Alternate-ECN 5.3. A General Evaluation of the Alternate-ECN
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Who Wants to Use Alternate Semantics for the ECN 6. Who Wants to Use Alternate Semantics for the ECN
Codepoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Codepoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Normative References . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . 13
11. Informative References . . . . . . . . . . . . . . . . . . . 12 11. Informative References . . . . . . . . . . . . . . . . . . . 13
IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 13 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 14
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 13 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 14
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. This document describes some of the issues field of the IP header. This document describes some of the issues
that arise in specifying such alternate semantics for the ECN field, that arise in specifying such alternate semantics for the ECN field,
skipping to change at page 6, line 26 skipping to change at page 7, line 4
routers along the path don't understand the alternate-ECN semantics? routers along the path don't understand the alternate-ECN semantics?
These issues have to be answered in the context of each specific These issues have to be answered in the context of each specific
proposal for alternate ECN semantics. proposal for alternate ECN semantics.
A second specific problem is that of possible unfair competition A second specific problem is that of possible unfair competition
with other traffic along the path. If there is an old router along 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 the path that doesn't use ECN, that old router could drop packets
from the alternate-ECN traffic, and expect the alternate-ECN traffic from the alternate-ECN traffic, and expect the alternate-ECN traffic
to reduce its sending rate as a result. Does the alternate-ECN to reduce its sending rate as a result. Does the alternate-ECN
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 with an old router using RFC-3168 ECN. Figure 1: Alternate-ECN traffic, an old router using RFC-3168 ECN.
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 the presence of old routers along the path results in the where the presence of old routers along the path results in the
alternate-ECN traffic competing unfairly with other traffic along alternate-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
skipping to change at page 8, line 13 skipping to change at page 8, line 37
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.
Such a mechanism should be robust in the presence of paths with load Such a mechanism should be robust in the presence of paths with
balancing, and in the presence of routing changes in the middle of a multi-path routing, and in the presence of routing or configuration
connection. 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 4.3. Option 3: Friendly Co-existence 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 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, routers that use only the default ECN semantics. In this scenario,
a connection sending alternate-ECN traffic would have to respond a 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
skipping to change at page 9, line 22 skipping to change at page 9, line 50
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 is that the end-nodes respond in a TCP-friendly manner to ECN is that the end-nodes respond to packets that are marked with
packets received that are marked with the ECN codepoint "11" the ECN codepoint "11" in a way that is friendly to flows using
(because these packets might have come from a congested router that IETF-conformant congestion control. This requirement is needed
understands only the default ECN semantics). This would ensure that because the "11"-marked packets might have come from a congested
the traffic using the alternate semantics does not `bully' competing router that understands only the default ECN semantics, and that
traffic that it might encounter along the path, and does not drive expects that end-nodes will respond appropriately to CE packets.
up congestion on the shared link inappropriately. 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 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 diff-serv codepoint using default
ECN semantics is redefined to use alternate ECN semantics, and ECN semantics is redefined to use alternate ECN semantics, and
traffic from an "old" source traverses a "new" router. If the traffic from an "old" source traverses a "new" router. If the
router "knows" that a packet is from a sender using alternate router "knows" that a packet is from a sender using alternate
semantics (e.g., because the packet is using a certain diff-serv semantics (e.g., because the packet is using a certain diff-serv
codepoint, and all packets with that diff-serv codepoint use codepoint, and all packets with that diff-serv codepoint use
alternate semantics for the ECN field), then the requirements below alternate semantics for the ECN field), then the requirements below
skipping to change at page 9, line 51 skipping to change at page 10, line 34
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].
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 that 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, and would require a consideration of issues of packet transmission, 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:
skipping to change at page 10, line 44 skipping to change at page 11, line 30
receiver has more incentives for lying about the congestion receiver has more incentives for lying about the congestion
experienced along the path. experienced 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 for ECN-Capable(0) and ECN-Capable(1). The use of two used for ECN-Capable(0) and ECN-Capable(1). The use of two
codepoints for ECN-Capable, instead of one, permits the data sender codepoints for ECN-Capable, instead of one, permits the data sender
to verify receiver's reports that packets were actually received to verify receiver's reports that packets were actually received
unmarked at the receiver. In particular, the sender can specify unmarked at the receiver. In particular, the sender can specify
that the receiver report to the sender whether each unmarked packet that the receiver report to the sender whether each unmarked packet
was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC was received ECN-Capable(0) or ECN-Capable(1), as discussed in RFC
3540 [RFC 3540]. 3540 [RFC 3540]. This use of ECN-Capable(0) and ECN-Capable(1) is
independent of the semantics of the other ECN codepoints, and could
be used, if desired, with alternate semantics for the other
codepoints.
If alternate semantics for the ECN codepoint don't include the use If alternate semantics for the ECN codepoint don't include the use
of two separate codepoints to indicate ECN-Capable, then the of two separate codepoints to indicate ECN-Capable, then the
connections using those semantics have lost the ability to verify connections using those semantics have lost the ability to verify
that the data receiver is accurately reporting the received ECN that the data receiver is accurately reporting the received ECN
codepoint to the data sender. In this case, it might be necessary codepoint to the data sender. In this case, it might be necessary
for the alternate-ECN framework to include alternate mechanisms for for the alternate-ECN framework to include alternate mechanisms for
ensuring that the data receiver is reporting feedback appropriately ensuring that the data receiver is reporting feedback appropriately
to the sender. 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 5.2. Co-existence with Competing Traffic
A second general issue concerns the co-existence of alternate-ECN A second general issue concerns the co-existence of alternate-ECN
traffic with competing traffic along the path, in a clean traffic with competing traffic along the path, in a clean
environment where all routers understand and are willing to use the environment where all routers understand and are willing to use the
alternate-ECN semantics for the traffic that specifies its use. alternate-ECN 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
skipping to change at page 11, line 42 skipping to change at page 12, line 33
evaluation of alternate-ECN semantics. evaluation of alternate-ECN semantics.
6. Who Wants to Use Alternate Semantics for the ECN Codepoint? 6. Who Wants to Use Alternate Semantics for the ECN Codepoint?
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 community for alternate semantics for the ECN codepoint research community for alternate semantics for the ECN codepoint
[ECN]. One such proposal, [BCF05], proposes an alternate-ECN [ECN]. One such proposal, [BCF05], proposes an alternate-ECN
semantics for real-time inelastic traffic such as voice, video semantics for real-time inelastic traffic such as voice, video
conferencing, and multimedia streaming in DiffServ networks. In conferencing, and multimedia streaming in DiffServ networks. In
this proposal, the alternate-ECN semantics would provide information this proposal, the alternate-ECN semantics would provide information
about two levels of congestion experienced along the path, where "it about two levels of congestion experienced along the path [BCF05].
is left up to the application designers to define how end-systems Some of the other proposals for alternate ECN semantics are listed
should react to ECN bit marking" [BCF05]. Some of the other on the ECN Web Page [ECN].
proposals for alternate ECN semantics are listed on the ECN Web Page
[ECN].
7. Security Considerations 7. 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.
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 Fred Baker, David Black, that need to be addressed. Thanks also to Mark Allman, Fred Baker,
Gorry Fairhurst, and to members of the TSVWG working group for David Black, Gorry Fairhurst, and to members of the TSVWG working
feedback on these issues. group for feedback on these issues.
9. Conclusions 9. 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.
10. Normative References 10. Normative References
11. Informative References 11. Informative References
[BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification [BCF05] J. Babiarz, K. Chan, and V. Firoiu, Congestion Notification
Process for Real-Time Traffic, internet-draft draft-babiarz-tsvwg- Process for Real-Time Traffic, internet-draft draft-babiarz-tsvwg-
rtecn-03, work in progress, February 2005. rtecn-04, work in progress, July 2005.
[DCCP] DCCP Web Page, URL "http://www.icir.org/kohler/dccp/". [DCCP] DCCP Web Page, URL "http://www.icir.org/kohler/dccp/".
[ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html". [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html".
[QuickStart] Quick-Start Web Page, URL [QuickStart] Quick-Start Web Page, URL
"http://www.icir.org/floyd/quickstart.html". "http://www.icir.org/floyd/quickstart.html".
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, Proposed Standard, April 1999. Control, RFC 2581, Proposed Standard, April 1999.
 End of changes. 22 change blocks. 
42 lines changed or deleted 66 lines changed or added

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