The Benefits 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 2015-03-23
Replaces draft-welzl-ecn-benefits
Stream IETF
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized 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                                       G. Fairhurst
Internet-Draft                                    University of Aberdeen
Intended status: Informational                                  M. Welzl
Expires: September 23, 2015                           University of Oslo
                                                          March 22, 2015

      The Benefits of using Explicit Congestion Notification (ECN)


   This document describes the potential benefits 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 identifies some
   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 September 23, 2015.

Copyright Notice

   Copyright (c) 2015 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
   publication of this document.  Please review these documents

Fairhurst & Welzl      Expires September 23, 2015               [Page 1]
Internet-Draft               Benefits of ECN                  March 2015

   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]).

   A network device (router, middlebox, or other device that forwards
   packets through the network) that does not support AQM, typically
   uses a drop-tail policy to discard excess IP packets when its queue
   becomes full.  The discard of packets serves as a signal to the end-
   to-end transport that there may be congestion on the network path
   being used.  This triggers a congestion control reaction to reduce
   the maximum rate permitted by the sending endpoint.

   When an application uses a transport that 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.  This indicates to network devices 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 does not need to be known
   by the transport endpoints.  The focus of this document is on usage
   of ECN by transport and application layer flows, not its
   implementation in hosts, routers and other network devices.

   ECN makes it possible for the network to signal the presence of
   congestion without incurring packet loss.  This lets the network
   deliver some packets to an application that would otherwise have been
   dropped if the application or transport did not support ECN.  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
Show full document text