The Benefits and Pitfalls of using Explicit Congestion Notification (ECN)

The information below is for an old version of the document
Document Type Active Internet-Draft (aqm WG)
Last updated 2014-10-28 (latest revision 2014-10-24)
Replaces draft-welzl-ecn-benefits
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           M. Welzl
Internet-Draft                                        University of Oslo
Intended status: Informational                              G. Fairhurst
Expires: April 27, 2015                           University of Aberdeen
                                                        October 24, 2014

  The Benefits and Pitfalls of using Explicit Congestion Notification


   This document describes the potential benefits and pitfalls when
   applications enable Explicit Congestion Notification (ECN).  It
   outlines the principal gains in terms of increased throughput,
   reduced delay and other benefits when ECN is used over network paths
   that include equipment that supports ECN-marking.  It also lists
   potential problems that might occur when ECN is used.  The document
   does not propose new algorithms that may be able to use ECN or
   describe the details of implementation of ECN in endpoint devices,
   routers and other network devices.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 27, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of

Welzl & Fairhurst        Expires April 27, 2015                 [Page 1]
Internet-Draft               Benefits of ECN                October 2014

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   Internet Transports (such as TCP and SCTP) have two ways to detect
   congestion: the loss of a packet and, if Explicit Congestion
   Notification (ECN) [RFC3168] is enabled, by reception of a packet
   with a Congestion Experienced (CE)-marking in the IP header.  Both of
   these are treated by transports as indications of (potential)
   congestion.  ECN may also be enabled by other transports.  UDP
   applications may enable ECN when they are able to correctly process
   the ECN signals (e.g.  ECN with RTP [RFC6679]).

   When an application enables the use of ECN, the transport layer sets
   the ECT(0) or ECT(1) codepoint in the IP header of packets that it
   sends to indicate to routers that they may mark, rather than drop,
   packets in periods of congestion.  This marking is generally
   performed by Active Queue Management (AQM) [RFC2309.bis] and may be
   the result of various AQM algorithms, where the exact combination of
   AQM/ECN algorithms is generally not known by the transport endpoints.

   ECN makes it possible for the network to signal congestion without
   packet loss.  This lets the network deliver some packets to an
   application that would otherwise have been dropped.  This packet loss
   reduction is the most obvious benefit of ECN, but it is often
   relatively modest.  However, enabling ECN can also result in a number
   of beneficial side-effects, some of which may be much more
   significant than the immediate packet loss reduction from ECN-marking
   instead of dropping packets.  Several of these benefits have to do
   with reducing latency in some way (e.g. reduced Head-of-Line Blocking
   and potentially smaller queuing delay, depending on the marking rules
   in routers).  There are also some potential pitfalls when enabling

   The focus of this document is on usage of ECN, not its implementation
   in endpoint devices, routers and other network devices.  [RFC3168]
   describes a method in which a router sets the CE codepoint of an ECN-
   Capable packet at the time that the router would otherwise have
   dropped the packet.

   While it has often been assumed that routers mark packets at the same
   level of congestion at which they would otherwise drop them, separate

Welzl & Fairhurst        Expires April 27, 2015                 [Page 2]
Show full document text