Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000003484D
Original Publication Date: 2000-Jul-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 15 page(s) / 42K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

U. Ahmed: AUTHOR [+2]

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 7% of the total text.

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

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 s...