draft-ietf-tsvwg-ecn-alternates-00.txt   draft-ietf-tsvwg-ecn-alternates-01.txt 
Internet Engineering Task Force S. Floyd Internet Engineering Task Force S. Floyd
INTERNET-DRAFT ICIR INTERNET-DRAFT ICIR
Expires: January 2007
Specifying Alternate Semantics for the Explicit Congestion Specifying Alternate Semantics for the Explicit Congestion
Notification (ECN) Field Notification (ECN) Field
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 30 skipping to change at page 1, line 33
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 July 2006. This Internet-Draft will expire on January 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
There have been a number of proposals for alternate semantics for There have been a number of proposals for alternate semantics for
the ECN field in the IP header [ECN]. This document discusses some the ECN field in the IP header [RFC3168]. This document discusses
of the issues in defining alternate semantics for the ECN field, and some of the issues in defining alternate semantics for the ECN
specifies requirements for a safe co-existence in an Internet that field, and specifies requirements for a safe co-existence in an
could include routers that do not understand the defined alternate Internet that could include routers that do not understand the
semantics. This document evolved as a result of discussions with defined alternate semantics. This document evolved as a result of
the authors of one recent proposal for such alternate semantics. discussions with 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-ietf-tsvwg-ecn-alternates-01.txt:
* Updated references, moved a paragraph to the Introduction.
Based on feedback from the IESG.
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: Changes from draft-floyd-ecn-alternates-02.txt:
* Added a subsection on proposals for edge-to-edge ECN. * Added a subsection on proposals for edge-to-edge ECN.
* Changed name to draft-ietf-tsvwg-ecn-alternates-00. * Changed name to draft-ietf-tsvwg-ecn-alternates-00.
Changes from draft-floyd-ecn-alternates-01.txt: Changes from draft-floyd-ecn-alternates-01.txt:
* Changed requirement for TCP friendliness, to a requirement of * Changed requirement for TCP friendliness, to a requirement of
friendliness with IETF-conformant congestion control. From email friendliness with IETF-conformant congestion control. From email
skipping to change at page 2, line 48 skipping to change at page 3, line 12
* 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 . . . . . . . . . . . . . . . . . . 4
3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 5 3. Signalling the Use of Alternate ECN Semantics . . . . . . . . 5
3.1. Using the Diffserv Field for Signalling. . . . . . . . . 5 3.1. Using the Diffserv Field for Signalling. . . . . . . . . 6
4. Issues of Incremental Deployment. . . . . . . . . . . . . . . 6 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. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Option 2: Verification that Routers Under- 4.2. Option 2: Verification that Routers Under-
stand the Alternate Semantics . . . . . . . . . . . . . . . . 8 stand the Alternate Semantics . . . . . . . . . . . . . . . . 8
4.3. Option 3: Friendly Co-existence with Com- 4.3. Option 3: Friendly Co-existence with Com-
peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 8 peting Traffic. . . . . . . . . . . . . . . . . . . . . . . . 9
5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 11 5. Evaluation of the Alternate-ECN Semantics . . . . . . . . . . 11
5.1. Verification of Feedback from the Router . . . . . . . . 11 5.1. Verification of Feedback from the Router . . . . . . . . 11
5.2. Co-existence with Competing Traffic. . . . . . . . . . . 11 5.2. Co-existence with Competing Traffic. . . . . . . . . . . 12
5.3. Proposals for Alternate-ECN with Edge-to- 5.3. Proposals for Alternate-ECN with Edge-to-
Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . . 12 Edge Semantics. . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. A General Evaluation of the Alternate-ECN 5.4. A General Evaluation of the Alternate-ECN
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Who Wants to Use Alternate Semantics for the ECN 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Codepoint? . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 13
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Normative References. . . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . 13 10. Informative References . . . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . 13 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 15
IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 14 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 15
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 15
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.
that arise in specifying such alternate semantics for the ECN field,
and gives requirements for a safe co-existence in a world using the There have been a number of proposals in the IETF and in the
default ECN semantics (or using no ECN at all). research community for alternate semantics for the ECN codepoint.
One such proposal, [BCF05], proposes an alternate-ECN semantics for
real-time inelastic traffic such as voice, video conferencing, and
multimedia streaming in DiffServ networks. In this proposal, the
alternate-ECN semantics would provide information about two levels
of congestion experienced along the path [BCF05]. Another research
proposal, [XSSK05], proposes a low-complexity protocol, Variable-
structure congestion Control Protocol (VCP), that uses the two bits
in the ECN field to indicate low-load, high-load, and overload
(congestion), where transport protocols can increase more rapidly
during the low-load regime. Some of the proposals for alternate-ECN
semantics are for ECN used in an edge-to-edge context between
gateways at the edge of a network region, e.g., for pre-congestion
notification for admissions control [BESFC06]. Other proposals for
alternate ECN semantics are listed on the ECN Web Page [ECN].
This document describes some of the issues that arise in specifying
alternate semantics for the ECN field, and gives requirements for a
safe co-existence in a world using the default ECN semantics (or
using no ECN at all).
2. An Overview of the Issues 2. An Overview of the Issues
In this section we discuss some of the issues that arise if some of In this section we discuss some of the issues that arise if some of
the traffic in a network consists of alternate-ECN traffic (i.e., the traffic in a network consists of alternate-ECN traffic (i.e.,
traffic using alternate semantics for the ECN field). The issues traffic using alternate semantics for the ECN field). The issues
include the following: (1) how routers know which ECN semantics to include the following: (1) how routers know which ECN semantics to
use with which packets; (2) incremental deployment in a network use with which packets; (2) incremental deployment in a network
where some routers use only the default ECN semantics, or no ECN at where some routers use only the default ECN semantics, or no ECN at
all; (3) co-existence of alternate-ECN traffic with competing all; (3) co-existence of alternate-ECN traffic with competing
skipping to change at page 4, line 16 skipping to change at page 4, line 43
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 are
using alternate-ECN semantics? Is the specification of alternate- using alternate-ECN semantics? Is the specification of alternate-
ECN semantics robust and unambiguous? If not, is this a problem? 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 semantics,
a diffserv field is used to specify the use of alternate-ECN a diffserv field is used to specify the use of alternate-ECN
semantics. Do all routers that understand this diffserv codepoint semantics. Do all routers that understand this diffserv codepoint
understand that it uses alternate-ECN semantics, or not? Diffserv understand that it uses alternate-ECN semantics, or not? Diffserv
allows routers to re-mark DiffServ Code Point [DSCP] values within allows routers to re-mark DiffServ Code Point (DSCP) values within
the network; what is the effect of this on the alternate-ECN the network; what is the effect of this on the alternate-ECN
semantics? 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 that
skipping to change at page 9, line 23 skipping to change at page 9, line 47
"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 essentially the same as the congestion control response to a be essentially the same as the congestion control response to a
*single* dropped packet. For example, for ECN-Capable TCP the *single* dropped packet. For example, for ECN-Capable TCP the
source TCP is required to halve its congestion window for any window source TCP is required to halve its congestion window for any window
of data containing either a packet drop or an ECN indication." of data 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
[DCCP]), and TCP-Friendly Rate Control (TFRC) and protocols with ([RFC4340], [RFC4341])), and TCP-Friendly Rate Control (TFRC)
TFRC-like congestion control (e.g., DCCP using CCID-3 [DCCP]). TCP [RFC3448] and protocols with TFRC-like congestion control (e.g.,
uses Additive-Increase Multiplicative-Decrease congestion control, DCCP using CCID-3 [RFC4342]). TCP uses Additive-Increase
and responds to the loss or ECN-marking of a single packet by Multiplicative-Decrease congestion control, and responds to the loss
halving its congestion window. In contrast, the equation-based or ECN-marking of a single packet by halving its congestion window.
congestion control mechanism in TFRC estimates the loss event rate In contrast, the equation-based congestion control mechanism in TFRC
over some period of time, and uses a sending rate that would be estimates the loss event rate over some period of time, and uses a
comparable, in packets per round-trip-time, to that of a TCP sending rate that would be comparable, in packets per round-trip-
connection experiencing the same loss event rate. time, to that of a TCP connection experiencing the same loss event
rate.
So what are the requirements in order for alternate-ECN traffic to So what are the requirements in order for alternate-ECN traffic to
compete appropriately with other traffic on a path through an old compete appropriately with other traffic on a path through an old
router that doesn't understand the alternate ECN semantics (and router that doesn't understand the alternate ECN semantics (and
therefore might be using the default ECN semantics)? The first and therefore might be using the default ECN semantics)? The first and
second requirements below concern compatibility between traffic second requirements below concern compatibility between traffic
using alternate ECN semantics and routers using default ECN using 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
skipping to change at page 12, line 25 skipping to change at page 12, line 49
this should be addressed in the specification of the diffserv this should be addressed in 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* dropped packet" [RFC3168, Section 5]. In contrast, some of *single* dropped packet" ([RFC3168], Section 5). In contrast, some
the proposals for alternate-ECN semantics are for ECN used in an of the proposals for alternate-ECN semantics are for ECN used in an
edge-to-edge context between gateways at the edge of a network edge-to-edge context between gateways at the edge of a network
region, e.g., for pre-congestion notification for admissions control region, e.g., [BESFC06].
[BESFC05].
When alternate-ECN is defined with edge-to-edge semantics, this When alternate-ECN is defined with edge-to-edge semantics, this
definition needs to ensure that the edge-to-edge semantics do not definition needs to ensure that the edge-to-edge semantics do not
conflict with a connection using other ECN semantics end-to-end. conflict with a connection using other ECN semantics end-to-end.
One way to avoid conflict would be for the edge-to-edge ECN proposal One way to avoid conflict would be for the edge-to-edge ECN proposal
to include some mechanism to ensure that the edge-to-edge ECN is not to include some mechanism to ensure that the edge-to-edge ECN is not
used for connections that are using other ECN semantics (standard or used for connections that are using other ECN semantics (standard or
otherwise) end-to-end. Alternately, the edge-to-edge semantics otherwise) end-to-end. Alternately, the edge-to-edge semantics
could be defined so that they do not conflict with a connection could be defined so that they do not conflict with a connection
using other ECN semantics end-to-end. using other ECN semantics end-to-end.
5.4. A General Evaluation of the Alternate-ECN Semantics 5.4. 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. Who Wants to Use Alternate Semantics for the ECN Codepoint? 6. Security Considerations
There have been a number of proposals in the IETF and in the
research community for alternate semantics for the ECN codepoint
[ECN]. One such proposal, [BCF05], proposes an alternate-ECN
semantics for real-time inelastic traffic such as voice, video
conferencing, and multimedia streaming in DiffServ networks. In
this proposal, the alternate-ECN semantics would provide information
about two levels of congestion experienced along the path [BCF05].
Some of the other proposals for alternate ECN semantics are listed
on the ECN Web Page [ECN].
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.
7. Conclusions
This document has discussed some of the issues to be considered in
the specification of alternate semantics for the ECN field in the IP
header.
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. Conclusions 9. Normative References
This document has discussed some of the issues to be considered in
the specification of alternate semantics for the ECN field in the IP
header.
10. Normative References [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition
of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed
Standard, September 2001.
11. Informative References 10. 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, expired internet-draft draft-babiarz-
rtecn-04, work in progress, July 2005. tsvwg-rtecn-04, work in progress, July 2005.
[BESFC05] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A. [BESFC06] B. Briscoe, P. Eardley, D. Songhurst, F. Le Faucheur, A.
Charny, J. Barbiaz, K. Chan, A Framework for Admission Control over Charny, J. Barbiaz, K. Chan, A Framework for Admission Control over
DiffServ using Pre-Congestion Notification, internet-draft draft- DiffServ using Pre-Congestion Notification, internet-draft draft-
briscoe-tsvwg-cl-architecture-01.txt, work in progress, October briscoe-tsvwg-cl-architecture-03.txt, work in progress, June 2006.
2005.
[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] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, Quick-
"http://www.icir.org/floyd/quickstart.html". Start for TCP and IP, Internet-draft draft-ietf-tsvwg-
quickstart-05.txt, work in progress, July 2006.
[RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion
Control, RFC 2581, Proposed Standard, April 1999. Control, RFC 2581, Proposed Standard, April 1999.
[RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best
Current Practice, September 2000. Current Practice, September 2000.
[RFC2960] R. Stewart et al, Stream Control Transmission Protocol, [RFC2960] R. Stewart et al, Stream Control Transmission Protocol,
RFC 2960, October 2000. RFC 2960, October 2000.
[RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The Addition [RFC3448] Handley, M., Floyd, S., Pahdye, J., and Widmer, J. TCP
of Explicit Congestion Notification (ECN) to IP, RFC 3168, Proposed Friendly Rate Control (TFRC): Protocol Specification. RFC 3448,
Standard, September 2001. Proposed Standard, January 2003.
[RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit [RFC3540] N. Spring, D. Wetherall, and D. Ely, Robust Explicit
Congestion Notification (ECN) Signaling with Nonces, RFC 3540, Congestion Notification (ECN) Signaling with Nonces, RFC 3540,
Experimental, June 2003. Experimental, June 2003.
[RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding [RFC3714] S. Floyd and J. Kempf, Editors, IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet, RFC 3714, Congestion Control for Voice Traffic in the Internet, RFC 3714,
Informational, March 2004. Informational, March 2004.
[RFC4340] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
Control Protocol (DCCP), RFC 4340, Proposed Standard, March 2006.
[RFC4341] S. Floyd and E. Kohler, Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion
Control, RFC 4341, Proposed Standard, March 2006.
[RFC4342] S. Floyd, E. Kohler, and J. Padhye, Profile for Datagram
Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-
Friendly Rate Control (TFRC), RFC 4342, Proposed Standard, March
2006.
[XSSK05] Y. Xia, L. Subramanian, I. Stoica, and S. Kalyanaraman,
One More Bit Is Enough, SIGCOMM 2005, September 2005.
IANA Considerations IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Sally Floyd Sally Floyd
Phone: +1 (510) 666-2989 Phone: +1 (510) 666-2989
ICIR (ICSI Center for Internet Research) ICIR (ICSI Center for Internet Research)
Email: floyd@icir.org Email: floyd@icir.org
 End of changes. 26 change blocks. 
70 lines changed or deleted 106 lines changed or added

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