datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field
RFC 4774

Document type: RFC - Best Current Practice (November 2006; No errata)
Updated by RFC 6040
Also Known As BCP 124
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: WG Document
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4774 (Best Current Practice)
Responsible AD: Lars Eggert
Send notices to: floyd@icir.org, tsvwg-chairs@tools.ietf.org

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

[include full document text]