Simulation of Explicit Congestion Notification and Random Early Detection Nadav Amit Teif Dmitry Yurovsky Denis

Simulation of Explicit Simulation of Explicit Congestion Notification and Congestion Notification and Random Early DetectionRandom Early Detection

Nadav Amit

Teif Dmitry

Yurovsky Denis

Presentation OutlinesPresentation Outlines

•General Background (RED, ECN, Satellite )

•RED parameters and configurations

•Chosen topology and configurations

•Results and Conclusion

•Project Goals

Presentation OutlinesPresentation Outlines

Background - GeneralBackground - General

•In today’s networks, transport protocols are the one responsible for congestion avoidance

•When there is congestion in the router and its queue gets over flown , it drops packets from the tail until there is space to receive new packets in the buffer

•The protocol is completely transparent to the hosts, they see it as “Black Box”. Their only indication of congestion is packet loss

Background – General (Cont.)Background – General (Cont.)

•Hosts can understand that the router is congested either by time-out occurred or by receiving three duplicate ACK messages

•The use of this method can bring to synchronization of all hosts: they will all reduce the rate of sending packets at the same time

Background – Queue ManagementBackground – Queue Management

•The traditional technique for managing router is the method known as "tail drop“.

•This method has served the Internet well for years, but it has two important drawbacks:

1. Lock-Out - In some situations tail drop allows a single connection or a few flows to monopolize queue space, preventing other connections from getting room in the queue. This "lock-out" phenomenon is often the result of synchronization or other timing effects.

2. Full Queue - Full Queues The tail drop discipline allows queues to maintain a full (or, almost full) status for long periods of time, since tail drop signals congestion (via a packet drop) only when the queue has become full. It is important to reduce the steady-state queue size, and this is perhaps queue management's most important goal.

Queue Management (Cont.)Queue Management (Cont.)

Two alternative queue disciplines can be applied when the queue becomes full: "random drop on full" and "drop front on full". In “Random Drop on Full”, a router drops a randomly selected packet from the queue when the queue is full and a new packet arrives. Under the “Drop Front on Full“ discipline, the router drops the packet at the front of the queue when the queue is full and a new packet arrives.

Both of these solve the lock-out problem, but neither

solves the full-queues problem described above

Active Queue ManagementActive Queue Management

In summary, an active queue management mechanism can provide the following advantages for responsive flows:

1. Reduce number of packets dropped in routers

By keeping the average queue size small, active queue management will provide greater capacity to absorb naturally- occurring bursts without dropping packets. Without active queue management, more packets will be dropped when a queue does overflow.

2. Provide lower-delay interactive service

By keeping the average queue size small, queue management will reduce the delays seen by flows. This is particularly important for interactive applications such as short Web transfers, Telnet traffic, or interactive audio-video sessions,whose subjective (and objective) performance is better when the end-to-end delay is low.

3. Avoid lock-out behavior

Active queue management can prevent lock-out behavior by ensuring that there will almost always be a buffer available for an incoming packet. For the same reason, active queue management can prevent a router bias against low bandwidth but highly bursty flows.

Background - REDBackground - RED

RED is an AQM mechanism, which is not designed to operatewith any specific protocol, but performs better with protocolsthat perceive drops as indications of congestion (e.g. TCP).

RED gateways require the user to specify five parameters: the maximum buffer size or queue limit (QL), the minimum (minth)

and maximum (maxth) thresholds of the "RED region", the

maximum dropping probability (maxp), and the weight factor

used to calculate the average queue size (wq).

RED – Cont.RED – Cont.

Early packet dropping starts when the average queue size exceeds minth.

RED was specifically designed to use the average queue size (avg), instead of the current queue size, as a measure of incipientcongestion, because the latter proves to be rather intolerant of packet bursts.

avg is calculated as an exponentially weighted moving average using the following formula:

avg i = (1 - wq) × avgi-1 + wq × q

RED - AlgorithmRED - Algorithm

Background - ECNBackground - ECN

Dropping packets as an indication of congestion is not intended to help applications that are in fact sensitive to the delay or loss of one or more individual packets.

Interactive traffic such as telnet, web-browsing, and transfer of audio and video data can be sensitive to packet losses or to the increased latency of the packet caused by the need to retransmit the packet after a loss (for reliable data delivery such as TCP).

Explicit Congestion Explicit Congestion Notification Notification

The idea is to provide a congestion indication for incipient congestion where the notification can sometimes be through marking packets rather than dropping them.

The ECN-Capable Transport (ECT) bit would be set by the data sender to indicate that the end-points of the transport protocol are ECN-capable.

The CE bit would be set by the router to indicate congestionto the end nodes. Routers that have a packet arriving at a full queue would drop the packet, just as they do now.

ECN – IP LevelECN – IP Level

Two bits from the IP header will be used for congestion notification

Routers that have a packet arriving at a full queue drop the packet, just as they do in the absence of ECN.

Upon the receipt by an ECN-Capable transport of a single CE packet

ECN-capable TCP source halve its congestion window for either a

packet drop or an ECN indication.

If there were different congestion control responses, this could result

in unfair treatment for different flows.

Bits 6 and 7 in the TOS (Type of Service) octet are designated as the ECN field:0 0 – Not ECN-Capable Transport0 1 – ECN-Capable Transport (ECT(0))1 0 – ECN-Capable Transport (ECT(1))1 1 – Congestion Experienced (CE)

ECN – IP Level (Cont.)ECN – IP Level (Cont.)

ECT(0)

Congested router Not congested router

CE

CE CE

ECT(0) ECT(0)

CE CE

May also drop the packet

not-ECT

not-ECT

not-ECTDrops the

packet

ECN – TCP LevelECN – TCP Level

When using ECN, TCP adds three functionalitiesWhen using ECN, TCP adds three functionalities

to the protocol: to the protocol:

Negotiation between the endpoints during connection setup to determine if they are both ECN-capable

ECN-Echo flag in the TCP header so that the data receiver can inform the data sender when a CE packet has been received

Congestion Window Reduced flag in the TCP header so that the data sender can inform the data receiver that the congestion window has been reduced

ECN – The Whole ThingECN – The Whole Thing

An ECT codepoint is set in packets transmitted by the sender to indicate that ECN is

supported by the transport entities for these packets.

The router detects congestion and instead of dropping the packet, sets the CE codepoint in the IP header and forwards the packet

The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo

flag in its next TCP ACK sent to the sender.

The sender receives the TCP ACK with ECN-Echo set, and reacts to the congestion

as if a packet had been dropped (sstresh=cwnd=old_cwnd/2).

The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag.

Project GoalsProject Goals

1. Use NS2 Simulator to simulate congested network that uses RED

2. Test and compare throughput and congestion window behavior using different parameters :

•With ECN or without it

•Different types of links: usual and satellite

•Variable number of connections

Project DescriptionProject Description

•Creating topology suitable for testing network parameters, which has bottle neck and can be easily altered form one configuration to another.

•Choosing parameters for RED to get the optimal performance

•Results elaboration and comparison

•Analysis and contemplation of results

•Visual presentation of results in graphs and tables

Tests PerformedTests Performed

Two simulations were performed during our project:

1. FTP connections which transfer infinite information. This simulation can be seen as big files transfer.

2. The second simulation was FTP transfer of files with average file size of 500KB (i.e. 500 packets), and average of 2 seconds pause between one file transfer to another. Exponential distribution was used for the file sizes, and Pareto distribution for the pause.

Additional Information…Additional Information…

Simulation time was set to 700 seconds, yet we discarded the first 200 seconds, which we regarded as initialization time (time for the TCP connections to load and throughput to reach steady state).

Results – Infinite InformationResults – Infinite Information

Throughput in infinite information transfer:

Results – Infinite InformationResults – Infinite Information

Goodput in Kb/s of infinite information transfer :

Results – Small FilesResults – Small Files

Throughput in small files transfer:

Results – Small FilesResults – Small Files

Goodput in Kb/s of small files transfer :

Results – Queue SizeResults – Queue Size



No ECN ECN

Average 8.7 8.85

STD 14.08 14.47

Utilized 57.75% 61.15%90 0.05% 0.25%

Queue statistics (satellite link, 50 nodes, small files):

Analysis - Part 1Analysis - Part 1

When the bottleneck of the TCP transfer is the long propagation delay which limits the maximum usable bandwidth, both RED with and without ECN performs the same. This corresponds with the case in which the queue size is always below minth. In the

small files simulation this can be seen as the result of 8 TCP connections or less.

When congestion is severe due to bursty communication ECN can hurt the goodput rate due to higher probability for drop-tail queue-like behavior due to exceeding 2 times maxth. The problem can be solved by using higher qweight, yet since non-bursty communication will suffer from such settings optimal solution is usage of higher maxth and bigger queue.


Disregarding the previous case, when infinite (or large enough) amount of data is transferred, ECN improves TCP throughput. The improvement is more significant on satellite links, in which more packets are dropped or marked more recently and therefore more congestion windows are reduced.

On satellite links additional packet drops are unavoidable even with ECN, since the variability of the number of dropped or marked packets is greater due to the higher number of packets "on the fly" while congestion occurs. Setting the maxp to low value might cause frequent queue overflow. Setting maxp to higher value might cause massive throughput reduction since too many TCP connections reduce their congestion window. The negative results of the variability can be solved using bigger queue.


ECN does provide a more significant advantage on small files transfer. This advantage is more significant on satellite links – even more than in the infinite information transfer simulation.

Since some of the connections are on slow-start phase, temporary high congestion can occur, unlike in the previous simulation.

For example: once the last packet on the last window is marked by ECN, yet the whole window is delivered successfully, the same packet is dropped by RED without ECN – causing a delivery of one packet on the next RTT and delaying the next file transfer on the TCP connection.


Configuring RED gateways is tricky, and even trickier on high RTT environment like the satellite environment. Larger queue makes this task easier, yet such queues are usually unavailable.

We will note we did not check the responses times of connections (variability of transfer times), which is also an indication of fairness. When setting RED parameters, fairness is known to be in inverse to the link utilization.

ConclusionsConclusions

RED with ECN provides the biggest advantage from the throughput perspective for heterogeneous interactive-like TCP connections, when one transfer start time is dependant on the previous transfer finish time. ECN advantages play even a greater role on satellite and other high propagation delay environments, when the avoidable retransmissions time is longer.

Related DocumentsRelated Documents

1. Sally Floyd's discussion

2. A Control Theoretic Analysis of RED

3. RED Parameters in Satellite Networks

Additional: ECN in NS2Additional: ECN in NS2

When working on the project, we encountered a weird bug in the NS2 implementation :

During the simulation with one TCP connection (which is reset in the middle) no congestion took place – the CE bit was not set at all, and therefore no congestion ECN echo bit was set. Yet, our debugging showed that the TCP agent thought for some reason the bit was set on the last ACK, and move immediately into congestion avoidance phase – resulting in low throughput

Chosen TopologyChosen Topology

Sn

S2

S1

G0

G1

Sat D

Multiple TCP sources in this node

In satellite simulations this node functions as satellite

S1 to Sn (depending on the tested params) – TCP destinations

All packets going to and from Si must go through G0

Choosing Optimal ParametersChoosing Optimal Parameters

If a RED’s queue is always not-empty, the throughput of RED, and RED with ECN are the same (since the line is in its peak throughput)

If the queue size is always below minth then both

the goodput and throughput are the same in both situations - since no drops / marks take place.

If max_p is too small then queue overflows frequently, which causes drop-tail queue like behavior.

We will not regard those cases!!! When choosing configuration we We will not regard those cases!!! When choosing configuration we tried to avoid the ideal case in which the queue is always not empty. tried to avoid the ideal case in which the queue is always not empty.

Therefore we've chosen the following parameters (hybrid of the RED thumb rules a and control theory recommendations)

wq was computed using , log 1eK

maxp=0.1, minth=5, maxth=15, markp=0.5

when K=0.005

Queue limit was set to 1000 (infinite)

Parameters (Cont.)Parameters (Cont.)