RFC relevance of congestion

As per Relevance of the word congestion, we have this rfc below:

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

Performance Evaluation of Explicit Congestion Notification (ECN
in IP

Status of this

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

Copyright

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

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

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

1.

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

Salim & Ahmed Informational [Page 1]

RFC 2884 ECN in IP Networks July 2000

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

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

2. Queue Management in

TCP's congestion control and avoidance algorithms are necessary
powerful but are not enough to provide good service in
circumstances since they treat the network as a black box. Some
of control is required from the routers to complement the end
congestion control mechanisms. More detailed analysis is contained
[19]. Queue management algorithms traditionally manage the length
packet queues in the router by dropping packets only when the
overflows. A maximum length for each queue is configured. The
will accept packets till this maximum size is exceeded, at
point it will drop incoming packets. New packets are accepted
buffer space allows. This technique is known as Tail Drop.
method has served the Internet well for years, but has the
drawbacks. Since all arriving packets (from all flows) are

Salim & Ahmed Informational [Page 2]

RFC 2884 ECN in IP Networks July 2000

when the buffer overflows, this interacts badly with the
control mechanism of TCP. A cycle is formed with a burst of
after the maximum queue size is exceeded, followed by a period
underutilization at the router as end systems back off. End
then increase their windows simultaneously up to a point where
burst of drops happens again. This phenomenon is called
Synchronization. It leads to poor link utilization and lower
throughput [19] Another problem with Tail Drop is that a
connection or a few flows could monopolize the queue space, in
circumstances. This results in a lock out phenomenon leading
synchronization or other timing effects [19]. Lastly, one of
major drawbacks of Tail Drop is that queues remain full for
periods of time. One of the major goals of queue management is
reduce the steady state queue size[19]. Other queue
techniques include random drop on full and drop front on full [13].

2.1. Active Queue

Active queue management mechanisms detect congestion before the
overflows and provide an indication of this congestion to the
nodes [7]. With this approach TCP does not have to rely only
buffer overflow as the indication of congestion since
happens before serious congestion occurs. One such active
technique is RED

2.1.1. Random Early

Random Early Detection (RED) [9] is a congestion avoidance
implemented in routers which works on the basis of active
management. RED addresses the shortcomings of Tail Drop. A
router signals incipient congestion to TCP by dropping
probabilistically before the queue runs out of buffer space.
drop probability is dependent on a running average queue size
avoid any bias against bursty traffic. A RED router randomly
arriving packets, with the result that the probability of dropping
packet belonging to a particular flow is approximately
to the flow's share of bandwidth. Thus, if the sender is
relatively more bandwidth it gets penalized by having more of
packets dropped. RED operates by maintaining two levels
thresholds minimum (minth) and maximum (maxth). It drops a
probabilistically if and only if the average queue size lies
the minth and maxth thresholds. If the average queue size is
the maximum threshold, the arriving packet is always dropped.
the average queue size is between the minimum and the
threshold, each arriving packet is dropped with probability pa,
pa is a function of the average queue size. As the average
length varies between minth and maxth, pa increases linearly
a configured maximum drop probability, maxp. Beyond maxth, the

Salim & Ahmed Informational [Page 3]

RFC 2884 ECN in IP Networks July 2000

probability is 100%. Dropping packets in this way ensures that
some subset of the source TCP packets get dropped and they
congestion avoidance algorithms that will ease the congestion at
gateway. Since the dropping is distributed across flows, the
of global synchronization is avoided

3. Explicit Congestion

Explicit Congestion Notification is an extension proposed to
which marks a packet instead of dropping it when the average
size is between minth and maxth [7]. Since ECN marks packets
congestion actually occurs, this is useful for protocols like
that are sensitive to even a single packet loss. Upon receipt of
congestion marked packet, the TCP receiver informs the sender (in
subsequent ACK) about incipient congestion which will in turn
the congestion avoidance algorithm at the sender. ECN
support from both the router as well as the end hosts, i.e. the
hosts TCP stack needs to be modified. Packets from flows that are
ECN capable will continue to be dropped by RED (as was the
before ECN).

3.1. Changes at the

Router side support for ECN can be added by modifying current
implementations. For packets from ECN capable hosts, the router
the packets rather than dropping them (if the average queue size
between minth and maxth). It is necessary that the router
that a packet is ECN capable, and should only mark packets that
from ECN capable hosts. This uses two bits in the IP header. The
Capable Transport (ECT) bit is set by the sender end system if
the end systems are ECN capable (for a unicast transport, only
both end systems are ECN-capable). In TCP this is confirmed in
pre-negotiation during the connection setup phase (explained
Section 3.2). Packets encountering congestion are marked by
router using the Congestion Experienced (CE) (if the average
size is between minth and maxth) on their way to the receiver
system (from the sender end system), with a probability
to the average queue size following the procedure used in
(RFC2309) routers. Bits 10 and 11 in the IPV6 header are
respectively for the ECT and CE bits. Bits 6 and 7 of the IPV4
DSCP field are also specified for experimental purposes for the
and CE bits respectively

3.2. Changes at the TCP Host

The proposal to add ECN to TCP specifies two new flags in
reserved field of the TCP header. Bit 9 in the reserved field of
TCP header is designated as the ECN-Echo (ECE) flag and Bit 8

Salim & Ahmed Informational [Page 4]

RFC 2884 ECN in IP Networks July 2000

designated as the Congestion Window Reduced (CWR) flag. These
bits are used both for the initializing phase in which the sender
the receiver negotiate the capability and the desire to use ECN,
well as for the subsequent actions to be taken in case there
congestion experienced in the network during the established state

There are two main changes that need to be made to add ECN to TCP
an end system and one extension to a router running RED

1. In the connection setup phase, the source and destination
have to exchange information about their desire and/or capability
use ECN. This is done by setting both the ECN-Echo flag and the
flag in the SYN packet of the initial connection phase by the sender
on receipt of this SYN packet, the receiver will set the ECN-
flag in the SYN-ACK response. Once this agreement has been reached
the sender will thereon set the ECT bit in the IP header of
packets for that flow, to indicate to the network that it is
and willing to participate in ECN. The ECT bit is set on all
other than pure ACK's

2. When a router has decided from its active queue
mechanism, to drop or mark a packet, it checks the IP-ECT bit in
packet header. It sets the CE bit in the IP header if the IP-ECT
is set. When such a packet reaches the receiver, the
responds by setting the ECN-Echo flag (in the TCP header) in the
outgoing ACK for the flow. The receiver will continue to do this
subsequent ACKs until it receives from the sender an indication
it (the sender) has responded to the congestion notification

3. Upon receipt of this ACK, the sender triggers its
avoidance algorithm by halving its congestion window, cwnd,
updating its congestion window threshold value ssthresh. Once it
taken these appropriate steps, the sender sets the CWR bit on
next data outgoing packet to tell the receiver that it has reacted
the (receiver's) notification of congestion. The receiver reacts
the CWR by halting the sending of the congestion notifications (ECE
to the sender if there is no new congestion in the network

Note that the sender reaction to the indication of congestion in
network (when it receives an ACK packet that has the ECN-Echo
set) is equivalent to the Fast Retransmit/Recovery algorithm (
there is a congestion loss) in NON-ECN-capable TCP i.e. the
halves the congestion window cwnd and reduces the slow
threshold ssthresh. Fast Retransmit/Recovery is still available
ECN capable stacks for responding to three duplicate acknowledgments

Salim & Ahmed Informational [Page 5]

RFC 2884 ECN in IP Networks July 2000

4. Experimental

For testing purposes we have added ECN to the Linux TCP/IP stack
kernels version 2.0.32. 2.2.5, 2.3.43 (there were also
revisions of 2.3 which were tested). The 2.0.32
conforms to RFC 2481 [7] for the end systems only. We have
modified the code in the 2.1,2.2 and 2.3 cases for the router
as well as end system to conform to the RFC. An outdated version
the 2.0 code is available at [18]. Note Linux version 2.0.32
implements TCP Reno congestion control while kernels >= 2.2.0
to New Reno but will opt for a SACK/FACK combo when the remote
understands SACK. Our initial tests were carried out with the 2.0
kernel at the end system and 2.1 (pre 2.2) for the router part.
majority of the test results here apply to the 2.0 tests. We
repeat these tests on a different testbed (move from Pentium
Pentium-II class machines)with faster machines for the 2.2 and 2.3
kernels, so the comparisons on the 2.0 and 2.2/3 are not relative

We have updated this memo release to reflect the tests against
and New Reno

4.1. Testbed

----- ----
| ECN | | ECN |
| ON | | OFF |
data direction ---->> ----- ----
| |
server | |
---- ------ ------ | |
| | | R1 | | R2 | | |
| | -----| | ---- | | ----------------------
---- ------ ^ ------ |
^ |
| -----
congestion point ___| | C |
| |
-----

The figure above shows our test setup

All the physical links are 10Mbps ethernet. Using Class
Queuing (CBQ) [22], packets from the data server are constricted to
1.5Mbps pipe at the router R1. Data is always retrieved from
server towards the clients labelled , "ECN ON", "ECN OFF", and "C".
Since the pipe from the server is 10Mbps, this creates congestion
the exit from the router towards the clients for competing flows.
machines labeled "ECN ON" and "ECN OFF" are running the same

Salim & Ahmed Informational [Page 6]

RFC 2884 ECN in IP Networks July 2000

of Linux and have exactly the same hardware configuration. The
is always ECN capable (and can handle NON ECN flows as well using
standard congestion algorithms). The machine labeled "C" is used
create congestion in the network. Router R2 acts as a path-
controller. With it we adjust the RTT the clients see. Router R
has RED implemented in it and has capability for supporting
flows. The path-delay router is a PC running the Nistnet [16]
package on a Linux platform. The latency of the link for
experiments was set to be 20 millisecs

4.2. Validating the

We spent time validating that the implementation was conformant
the specification in RFC 2481. To do this, the popular
sniffer [24] was modified to show the packets being marked.
visually inspected tcpdump traces to validate the conformance to
RFC under a lot of different scenarios. We also modified
[25] in order to plot the marked packets for visualization
analysis

Both tcpdump and tcptrace revealed that the implementation
conformant to the RFC

4.3. Terminology

This section presents background terminology used in the next
sections

* Congesting flows: These are TCP flows that are started in
background so as to create congestion from R1 towards R2. We use
laptop labeled "C" to introduce congesting flows. Note that "C" as
the case with the other clients retrieves data from the server

* Low, Moderate and High congestion: For the case of low
we start two congesting flows in the background, for
congestion we start five congesting flows and for the case of
congestion we start ten congesting flows in the background

* Competing flows: These are the flows that we are interested in
They are either ECN TCP flows from/to "ECN ON" or NON ECN TCP
from/to "ECN OFF".

* Maximum drop rate: This is the RED parameter that sets the
probability of a packet being marked at the router. This
to maxp as explained in Section 2.1.

Salim & Ahmed Informational [Page 7]

RFC 2884 ECN in IP Networks July 2000

Our tests were repeated for varying levels of congestion with
maximum drop rates. The results are presented in the
sections

* Low, Medium and High drop probability: We use the term
probability to mean a drop probability maxp of 0.02,
probability for 0.2 and high probability for 0.5. We
experimented with drop probabilities of 0.05, 0.1 and 0.3.

* Goodput: We define goodput as the effective data rate as
by the user, i.e., if we transmitted 4 data packets in which two
them were retransmitted packets, the efficiency is 50% and
resulting goodput is 2*packet size/time taken to transmit

* RED Region: When the router's average queue size is between
and maxth we denote that we are operating in the RED region

4.4. RED parameter

In our initial testing we noticed that as we increase the number
congesting flows the RED queue degenerates into a simple Tail
queue. i.e. the average queue exceeds the maximum threshold most
the times. Note that this phenomena has also been observed by [5]
who proposes a dynamic solution to alleviate it by adjusting
packet dropping probability "maxp" based on the past history of
average queue size. Hence, it is necessary that in the course of
experiments the router operate in the RED region, i.e., we have
make sure that the average queue is maintained between minth
maxth. If this is not maintained, then the queue acts like a
Drop queue and the advantages of ECN diminish. Our goal is
validate ECN's benefits when used with RED at the router. To
that we were operating in the RED region we monitored the
queue size and the actual queue size in times of low, moderate
high congestion and fine-tuned the RED parameters such that
average queue zones around the RED region before running
experiment proper. Our results are, therefore, not influenced
operating in the wrong RED region

5. The

We start by making sure that the background flows do not bias
results by computing the fairness index [12] in Section 5.1.
proceed to carry out the experiments for bulk transfer presenting
results and analysis in Section 5.2. In Section 5.3 the results
transactional transfers along with analysis is presented.
details on the experimental results can be found in [27].

Salim & Ahmed Informational [Page 8]

RFC 2884 ECN in IP Networks July 2000

5.1.

In the course of the experiments we wanted to make sure that
choice of the type of background flows does not bias the results
we collect. Hence we carried out some tests initially with both
and NON ECN flows as the background flows. We repeated
experiments for different drop probabilities and calculated
fairness index [12]. We also noticed (when there were equal
of ECN and NON ECN flows) that the number of packets dropped for
NON ECN flows was equal to the number of packets marked for the
flows, showing thereby that the RED algorithm was fair to both
of flows

Fairness index: The fairness index is a performance metric
in [12]. Jain [12] postulates that the network is a multi-
system, and derives a metric to see how fairly each user is treated
He defines fairness as a function of the variability of
across users. For a given set of user throughputs (x1, x2...xn),
fairness index to the set is defined as follows

f(x1,x2,.....,xn) = square((sum[i=1..n]xi))/(n*sum[i=1..n]square(xi))

The fairness index always lies between 0 and 1. A value of 1
indicates that all flows got exactly the same throughput. Each
the tests was carried out 10 times to gain confidence in our results
To compute the fairness index we used FTP to generate traffic

Experiment details: At time t = 0 we start 2 NON ECN FTP sessions
the background to create congestion. At time t=20 seconds we
two competing flows. We note the throughput of all the flows in
network and calculate the fairness index. The experiment was
out for various maximum drop probabilities and for various
levels. The same procedure is repeated with the background flows
ECN. The fairness index was fairly constant in both the cases
the background flows were ECN and NON ECN indicating that there
no bias when the background flows were either ECN or NON ECN

Max Fairness
Drop With BG With
Prob flows ECN flows NON

0.02 0.996888 0.991946
0.05 0.995987 0.988286
0.1 0.985403 0.989726
0.2 0.979368 0.983342

Salim & Ahmed Informational [Page 9]

RFC 2884 ECN in IP Networks July 2000

With the observation that the nature of background flows does
alter the results, we proceed by using the background flows as
ECN for the rest of the experiments

5.2. Bulk

The metric we chose for bulk transfer is end user throughput

Experiment Details: All TCP flows used are RENO TCP. For the case
low congestion we start 2 FTP flows in the background at time 0.
after about 20 seconds we start the competing flows, one
transfer to the ECN machine and the second to the NON ECN machine
The size of the file used is 20MB. For the case of
congestion we start 5 FTP flows in the background and for the case
high congestion we start 10 FTP flows in the background. We
the experiments for various maximum drop rates each repeated for
number of sets

Observation and Analysis

We make three key observations

1) As the congestion level increases, the relative advantage for
increases but the absolute advantage decreases (expected, since
are more flows competing for the same link resource). ECN still
better than NON ECN even under high congestion. Infering a
from the collected results: at maximum drop probability of 0.1,
example, the relative advantage of ECN increases from 23% to 50%
the congestion level increases from low to high

2) Maintaining congestion levels and varying the maximum
probability (MDP) reveals that the relative advantage of
increases with increasing MDP. As an example, for the case of
congestion as we vary the drop probability from 0.02 to 0.5
relative advantage of ECN increases from 10% to 60%.

3) There were hardly any retransmissions for ECN flows (except
occasional packet drop in a minority of the tests for the case
high congestion and low maximum drop probability).

We analyzed tcpdump traces for NON ECN with the help of tcptrace
observed that there were hardly any retransmits due to timeouts
(Retransmit due to timeouts are inferred by counting the number of 3
DUPACKS retransmit and subtracting them from the total
number of retransmits). This means that over a long period of
(as is the case of long bulk transfers), the data-driven
recovery mechanism of the Fast Retransmit/Recovery algorithm is
effective. The algorithm for ECN on congestion notification from

Salim & Ahmed Informational [Page 10]

RFC 2884 ECN in IP Networks July 2000

is the same as that for a Fast Retransmit for NON ECN. Since both
operating in the RED region, ECN barely gets any advantage over
ECN from the signaling (packet drop vs. marking).

It is clear, however, from the results that ECN flows benefit in
transfers. We believe that the main advantage of ECN for
transfers is that less time is spent recovering (whereas NON
spends time retransmitting), and timeouts are avoided altogether
[23] has shown that even with RED deployed, TCP RENO could
from multiple packet drops within the same window of data, likely
lead to multiple congestion reactions or timeouts (these problems
alleviated by ECN). However, while TCP Reno has performance
with multiple packets dropped in a window of data, New Reno and
have no such problems

Thus, for scenarios with very high levels of congestion,
advantages of ECN for TCP Reno flows could be more dramatic than
advantages of ECN for NewReno or SACK flows. An
observation to make from our results is that we do not
multiple drops within a single window of data. Thus, we would
that our results are not heavily influenced by Reno's
problems with multiple packets dropped from a window of data.
repeated these tests with ECN patched newer Linux kernels.
mentioned earlier these kernels would use a SACK/FACK combo with
fallback to New Reno. SACK can be selectively turned off (
to New Reno). Our results indicate that ECN still
performance for the bulk transfers. More results are available in
pdf version[27]. As in 1) above, maintaining a maximum
probability of 0.1 and increasing the congestion level, it
observed that ECN-SACK improves performance from about 5% at
congestion to about 15% at high congestion. In the scenario
high congestion is maintained and the maximum drop probability
moved from 0.02 to 0.5, the relative advantage of ECN-SACK
from 10% to 40%. Although this numbers are lower than the
exhibited by Reno, they do reflect the improvement that ECN
even in the presence of robust recovery mechanisms such as SACK

5.3. Transactional

We model transactional transfers by sending a small request
getting a response from a server before sending the next request.
generate transactional transfer traffic we use Netperf [17] with
CRR (Connect Request Response) option. As an example let us
that we are retrieving a small file of say 5 - 20 KB, then in
we send a small request to the server and the server responds
sending us the file. The transaction is complete when we receive
complete file. To gain confidence in our results we carry
simulation for about one hour. For each test there are a few

Salim & Ahmed Informational [Page 11]

RFC 2884 ECN in IP Networks July 2000

of these requests and responses taking place. Although not
modeling HTTP 1.0 traffic, where several concurrent sessions
opened, Netperf-CRR is nevertheless a close approximation.
Netperf-CRR waits for one connection to complete before opening
next one (0 think time), that single connection could be viewed
the slowest response in the set of the opened concurrent sessions (
HTTP). The transactional data sizes were selected based on [2]
indicates that the average web transaction was around 8 - 10 KB;
smaller (5KB) size was selected to guestimate the size
transactional processing that may become prevalent with
management schemes in the diffserv [4] context. Using Netperf we
able to initiate these kind of transactional transfers for a
length of time. The main metric of interest in this case is
transaction rate, which is recorded by Netperf

* Define Transaction rate as: The number of requests and
responses for a particular requested size that we are able to do
second. For example if our request is of 1KB and the response is 5
then we define the transaction rate as the number of such
transactions that we can accomplish per second

Experiment Details: Similar to the case of bulk transfers we
the background FTP flows to introduce the congestion in the
at time 0. About 20 seconds later we start the
transfers and run each test for three minutes. We record
transactions per second that are complete. We repeat the test
about an hour and plot the various transactions per second,
out over the runs. The experiment is repeated for various
drop probabilities, file sizes and various levels of congestion

Observation and

There are three key observations

1) As congestion increases (with fixed drop probability) the
advantage for ECN increases (again the absolute advantage does
increase since more flows are sharing the same bandwidth).
example, from the results, if we consider the 5KB transactional flow
as we increase the congestion from medium congestion (5
flows) to high congestion (10 congesting flows) for a maximum
probability of 0.1 the relative gain for ECN increases from 42%
62%.

2) Maintaining the congestion level while adjusting the maximum
probability indicates that the relative advantage for ECN
increase. From the case of high congestion for the 5KB flow

Salim & Ahmed Informational [Page 12]

RFC 2884 ECN in IP Networks July 2000

observe that the number of transactions per second increases from 0.8
to 2.2 which corresponds to an increase in relative gain for ECN
20% to 140%.

3) As the transactional data size increases, ECN's
diminishes because the probability of recovering from a
Retransmit increases for NON ECN. ECN, therefore, has a
advantage as the transactional data size gets smaller as is
in the results. This can be explained by looking at TCP
mechanisms. NON ECN in the short flows depends, for recovery,
congestion signaling via receiving 3 duplicate ACKs, or worse by
retransmit timer expiration, whereas ECN depends mostly on the TCP
ECE flag. This is by design in our experimental setup. [3]
that most of the TCP loss recovery in fact happens in timeouts
short flows. The effectiveness of the Fast Retransmit/
algorithm is limited by the fact that there might not be enough
in the pipe to elicit 3 duplicate ACKs. TCP RENO needs at least 4
outstanding packets to recover from losses without going into
timeout. For 5KB (4 packets for MTU of 1500Bytes) a NON ECN flow
always have to wait for a retransmit timeout if any of its
are lost. ( This timeout could only have been avoided if the flow
used an initial window of four packets, and the first of the
packets was the packet dropped). We repeated these experiments
the kernels implementing SACK/FACK and New Reno algorithms.
observation was that there was hardly any difference with what we
with Reno. For example in the case of SACK-ECN enabling:
the maximum drop probability to 0.1 and increasing the
level for the 5KB transaction we noticed that the relative gain
the ECN enabled flows increases from 47-80%. If we maintain
congestion level for the 5KB transactions and increase the
drop probabilities instead, we notice that SACKs
increases from 15%-120%. It is fair to comment that the
in the testbeds (different machines, same topology) might
contributed to the results; however, it is worth noting that
relative advantage of the SACK-ECN is obvious

6.

ECN enhancements improve on both bulk and transactional TCP traffic
The improvement is more obvious in short transactional type of
(popularly referred to as mice).

* Because less retransmits happen with ECN, it means less traffic
the network. Although the relative amount of data retransmitted
our case is small, the effect could be higher when there are
contributing end systems. The absence of retransmits also implies
improvement in the goodput. This becomes very important for

Salim & Ahmed Informational [Page 13]

RFC 2884 ECN in IP Networks July 2000

where bandwidth is expensive such as in low bandwidth links.
implies also that ECN lends itself well to applications that
reliability but would prefer to avoid unnecessary retransmissions

* The fact that ECN avoids timeouts by getting faster
(as opposed to traditional packet dropping inference from 3
ACKs or, even worse, timeouts) implies less time is spent
error recovery - this also improves goodput

* ECN could be used to help in service differentiation where the
user is able to "probe" for their target rate faster.
forwarding [1] in the diffserv working group at the IETF
using RED with varying drop probabilities as a
differentiation mechanism. It is possible that multiple
within a single window in TCP RENO could be dropped even in
presence of RED, likely leading into timeouts [23]. ECN end
ignore multiple notifications, which help in countering this
resulting in improved goodput. The ECN end system also ends
probing the network faster (to reach an optimal bandwidth). [23]
notes that RENO is the most widely deployed TCP implementation today

It is clear that the advent of policy management schemes
new requirements for transactional type of applications,
constitute a very short query and a response in the order of a
packets. ECN provides advantages to transactional traffic as we
shown in the experiments

7.

We would like to thank Alan Chapman, Ioannis Lambadaris, Thomas Kunz
Biswajit Nandy, Nabil Seddigh, Sally Floyd, and Rupinder Makkar
their helpful feedback and valuable suggestions

8. Security

Security considerations are as discussed in section 9 of RFC 2481.

9.

[1] Heinanen, J., Finland, T., Baker, F., Weiss, W. and J
Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.

[2] B.A. Mat. "An empirical model of HTTP network traffic."
proceedings INFOCOMM'97.

Salim & Ahmed Informational [Page 14]

RFC 2884 ECN in IP Networks July 2000

[3] Balakrishnan H., Padmanabhan V., Seshan S., Stemn M. and
H. Katz, "TCP Behavior of a busy Internet Server: Analysis
Improvements", Proceedings of IEEE Infocom, San Francisco, CA
USA, March '98
http://nms.lcs.mit.edu/~hari/papers/infocom98.ps.

[4] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.

[5] W. Feng, D. Kandlur, D. Saha, K. Shin, "Techniques
Eliminating Packet Loss in Congested TCP/IP Networks", U
Michigan CSE-TR-349-97, November 1997.

[6] S. Floyd. "TCP and Explicit Congestion Notification."
Computer Communications Review, 24, October 1994.

[7] Ramakrishnan, K. and S. Floyd, "A Proposal to add
Congestion Notification (ECN) to IP", RFC 2481, January 1999.

[8] Kevin Fall, Sally Floyd, "Comparisons of Tahoe, RENO and
TCP", Computer Communications Review, V. 26 N. 3, July 1996,
pp. 5-21

[9] S. Floyd and V. Jacobson. "Random Early Detection Gateways
Congestion Avoidance". IEEE/ACM Transactions on Networking
3(1), August 1993.

[10] E. Hashem. "Analysis of random drop for gateway
control." Rep. Lcs tr-465, Lav. Fot Comput. Sci., M.I.T., 1989.

[11] V. Jacobson. "Congestion Avoidance and Control." In
of SIGCOMM '88, Stanford, CA, August 1988.

[12] Raj Jain, "The art of computer systems performance analysis",
John Wiley and sons QA76.9.E94J32, 1991.

[13] T. V. Lakshman, Arnie Neidhardt, Teunis Ott, "The Drop
Front Strategy in TCP Over ATM and Its Interworking with
Control Features", Infocom 96, MA28.1.

[14] P. Mishra and H. Kanakia. "A hop by hop rate based
control scheme." Proc. SIGCOMM '92, pp. 112-123, August 1992.

[15] Floyd, S. and T. Henderson, "The NewReno Modification to TCP'
Fast Recovery Algorithm", RFC 2582, April 1999.

Salim & Ahmed Informational [Page 15]

RFC 2884 ECN in IP Networks July 2000

[16] The NIST Network Emulation
http://www.antd.nist.gov/itg/nistnet

[17] The network performance
http://www.netperf.org/netperf/NetperfPage.

[18] ftp://ftp.ee.lbl.gov/ECN/ECN-package.

[19] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S.,
Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge
C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J
and L. Zhang, "Recommendations on Queue Management
Congestion Avoidance in the Internet", RFC 2309, April 1998.

[20] K. K. Ramakrishnan and R. Jain. "A Binary feedback scheme
congestion avoidance in computer networks." ACM Trans. Comput
Syst.,8(2):158-181, 1990.

[21] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "
Selective Acknowledgement Options", RFC 2018, October 1996.

[22] S. Floyd and V. Jacobson, "Link sharing and Resource
Models for packet Networks", IEEE/ACM Transactions
Networking, Vol. 3 No.4, August 1995.

[23] Prasad Bagal, Shivkumar Kalyanaraman, Bob Packer, "
study of RED, ECN and TCP Rate Control".
http://www.packeteer.com/technology/Pdf/packeteer-final.

[24] tcpdump, the protocol packet capture & dumper program
ftp://ftp.ee.lbl.gov/tcpdump.tar.

[25] TCP dump file analysis tool
http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.

[26] Thompson K., Miller, G.J., Wilder R., "Wide-Area
Traffic Patterns and Characteristics". IEEE Networks Magazine
November/December 1997.

[27] http://www7.nortel.com:8080/CTL/ecnperf.

Salim & Ahmed Informational [Page 16]

RFC 2884 ECN in IP Networks July 2000

10. Authors'

Jamal Hadi
Nortel
3500 Carling
Ottawa, ON, K2H 8E

EMail: hadi@nortelnetworks.

Uvaiz
Dept. of Systems and Computer
Carleton

EMail: ahmed@sce.carleton.

Salim & Ahmed Informational [Page 17]

RFC 2884 ECN in IP Networks July 2000

11. Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Salim & Ahmed Informational [Page 18]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX