Network Working Group S. Floyd
Request for Comments: 4774 ICIR
BCP: 124 November 2006
Category: Best Current Practice
Specifying Alternate Semantics for
the Explicit Congestion Notification (ECN) Field
Status of This Memo
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 (C) The IETF Trust (2006).
Abstract
There have been a number of proposals for alternate semantics for the
Explicit Congestion Notification (ECN) field in the IP header RFC
3168. This document discusses some of the issues in defining
alternate semantics for the ECN field, and specifies requirements for
a safe coexistence in an Internet that could include routers that do
not understand the defined alternate semantics. This document
evolved as a result of discussions with the authors of one recent
proposal for such alternate semantics.
Floyd Best Current Practice [Page 1]
RFC 4774 Alternate Semantics for the ECN Field November 2006
Table of Contents
1. Introduction ....................................................2
2. An Overview of the Issues .......................................3
3. Signalling the Use of Alternate ECN Semantics ...................4
3.1. Using the Diffserv Field for Signalling ....................5
4. Issues of Incremental Deployment ................................6
4.1. Option 1: Unsafe for Deployment in the Internet ...........7
4.2. Option 2: Verification that Routers Understand the
Alternate ..................................................8
4.3. Option 3: Friendly Coexistence with Competing Traffic .....8
5. Evaluation of the Alternate ECN Semantics ......................10
5.1. Verification of Feedback from the Router ..................10
5.2. Coexistence with Competing Traffic ........................11
5.3. Proposals for Alternate ECN with Edge-to-Edge Semantics ...12
5.4. Encapsulated Packets ......................................12
5.5. A General Evaluation of the Alternate ECN Semantics .......12
6. Security Considerations ........................................12
7. Conclusions ....................................................13
8. Acknowledgements ...............................................13
9. Normative References ...........................................13
10. Informative References ........................................13
1. Introduction
[RFC3168], a Proposed Standard document, defines the ECN field in the
IP header, and specifies the semantics for the codepoints for the ECN
field. However, end nodes could specify the use of alternate
semantics for the ECN field, e.g., using codepoints in the diffserv
field of the IP header.
There have been a number of proposals in the IETF and in the research
community for alternate semantics for the ECN codepoint. One such
proposal, [BCF05], proposes 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 when ECN is 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].
Floyd Best Current Practice [Page 2]
RFC 4774 Alternate Semantics for the ECN Field November 2006
The definition of multiple semantics for the ECN field could have
significant implications on both host and router implementations.
There is a huge base of installed hosts and routers in the Internet,
and in other IP networks, and updating these is an enormous and
potentially expensive undertaking. Some existing devices might be
able to support the new ECN semantics with only a software upgrade
datatracker.ietf.org