Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks
RFC 2884

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                     J. Hadi Salim
Request for Comments: 2884                              Nortel Networks
Category: Informational                                        U. Ahmed
                                                    Carleton University
                                                              July 2000

   Performance Evaluation of Explicit Congestion Notification (ECN)
                             in IP Networks

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo presents a performance study of the Explicit Congestion
   Notification (ECN) mechanism in the TCP/IP protocol using our
   implementation on the Linux Operating System. ECN is an end-to-end
   congestion avoidance mechanism proposed by [6] and incorporated into
   RFC 2481[7]. We study the behavior of ECN for both bulk and
   transactional transfers. Our experiments show that there is
   improvement in throughput over NON ECN (TCP employing any of Reno,
   SACK/FACK or NewReno congestion control) in the case of bulk
   transfers and substantial improvement for transactional transfers.

   A more complete pdf version of this document is available at:
   http://www7.nortel.com:8080/CTL/ecnperf.pdf

   This memo in its current revision is missing a lot of the visual
   representations and experimental results found in the pdf version.

1. Introduction

   In current IP networks, congestion management is left to the
   protocols running on top of IP. An IP router when congested simply
   drops packets.  TCP is the dominant transport protocol today [26].
   TCP infers that there is congestion in the network by detecting
   packet drops (RFC 2581). Congestion control algorithms [11] [15] [21]
   are then invoked to alleviate congestion.  TCP initially sends at a
   higher rate (slow start) until it detects a packet loss. A packet
   loss is inferred by the receipt of 3 duplicate ACKs or detected by a

Salim & Ahmed                Informational                      [Page 1]
RFC 2884                   ECN in IP Networks                  July 2000

   timeout. The sending TCP then moves into a congestion avoidance state
   where it carefully probes the network by sending at a slower rate
   (which goes up until another packet loss is detected).  Traditionally
   a router reacts to congestion by dropping a packet in the absence of
   buffer space. This is referred to as Tail Drop. This method has a
   number of drawbacks (outlined in Section 2). These drawbacks coupled
   with the limitations of end-to-end congestion control have led to
   interest in introducing smarter congestion control mechanisms in
   routers.  One such mechanism is Random Early Detection (RED) [9]
   which detects incipient congestion and implicitly signals the
   oversubscribing flow to slow down by dropping its packets. A RED-
   enabled router detects congestion before the buffer overflows, based
   on a running average queue size, and drops packets probabilistically
   before the queue actually fills up. The probability of dropping a new
   arriving packet increases as the average queue size increases above a
   low water mark minth, towards higher water mark maxth. When the
   average queue size exceeds maxth all arriving packets are dropped.

   An extension to RED is to mark the IP header instead of dropping
   packets (when the average queue size is between minth and maxth;
   above maxth arriving packets are dropped as before). Cooperating end
   systems would then use this as a signal that the network is congested
   and slow down. This is known as Explicit Congestion Notification
   (ECN).  In this paper we study an ECN implementation on Linux for
   both the router and the end systems in a live network.  The memo is
   organized as follows. In Section 2 we give an overview of queue
   management in routers. Section 3 gives an overview of ECN and the
   changes required at the router and the end hosts to support ECN.
   Section 4 defines the experimental testbed and the terminologies used
   throughout this memo. Section 5 introduces the experiments that are
   carried out, outlines the results and presents an analysis of the
   results obtained.  Section 6 concludes the paper.

2. Queue Management in routers

   TCP's congestion control and avoidance algorithms are necessary and
   powerful but are not enough to provide good service in all
   circumstances since they treat the network as a black box. Some sort
   of control is required from the routers to complement the end system
   congestion control mechanisms. More detailed analysis is contained in
   [19].  Queue management algorithms traditionally manage the length of
   packet queues in the router by dropping packets only when the buffer