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

2. Presentation Outlines General Background (RED, ECN, Satellite ) RED parameters and configurations Chosen topology and configurations Results and Conclusion Project Goals Presentation Outlines

3. Background - 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

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

5. Background – 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.

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

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

8. Background - RED RED is an AQM mechanism, which is not designed to operate with any specific protocol, but performs better with protocols that 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 (min th ) and maximum (max th ) thresholds of the "RED region", the maximum dropping probability (max p ), and the weight factor used to calculate the average queue size (w q ).

9. RED – Cont. Early packet dropping starts when the average queue size exceeds min th. RED was specifically designed to use the average queue size (avg), instead of the current queue size, as a measure of incipient congestion, 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 - w q ) × avg i-1 + w q × q

10. RED - Algorithm

11. Background - 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).

12. Explicit Congestion 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 congestion to the end nodes. Routers that have a packet arriving at a full queue would drop the packet, just as they do now.

13. ECN – 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 Transport 0 1 – ECN-Capable Transport (ECT(0)) 1 0 – ECN-Capable Transport (ECT(1)) 1 1 – Congestion Experienced (CE)

14. ECN – IP Level (Cont.) ECT(0) Congested router Not congested router CE ECT(0) CE May also drop the packet not- ECT Drops the packet

15. ECN – TCP Level When using ECN, TCP adds three functionalities 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

16. ECN – 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.

18. Project 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

19. Project 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

20. Tests 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.

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

23. Results – Infinite Information Throughput in infinite information transfer:

24. Results – Infinite Information Goodput in Kb/s of infinite information transfer :

25. Results – Small Files Throughput in small files transfer:

26. Results – Small Files Goodput in Kb/s of small files transfer :

27. Results – Queue Size

29. No ECNECN Average8.78.85 STD14.0814.47 Utilized57.75%61.15%  900.05%0.25% Queue statistics (satellite link, 50 nodes, small files):

30. Analysis - 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 min th. 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 max th. The problem can be solved by using higher q weight, yet since non-bursty communication will suffer from such settings optimal solution is usage of higher max th and bigger queue.

31. Analysis - Part 2 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.

32. Analysis - Part 3 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.

33. Analysis - Part 4 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.

34. Conclusions 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.

35. Related Documents 1. Sally Floyd's discussionSally Floyd's discussion 2. A Control Theoretic Analysis of REDA Control Theoretic Analysis of RED 3. RED Parameters in Satellite NetworksRED Parameters in Satellite Networks

37. Additional: 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

38. Chosen Topology Sn S2 S1 G0G0 G1G1 SatD 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

39. Choosing 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 min th 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 tried to avoid the ideal case in which the queue is always not empty.

40. Therefore we've chosen the following parameters (hybrid of the RED thumb rules a and control theory recommendations) w q was computed using, max p =0.1, min th =5, max th =15, mark p =0.5 when K=0.005 Queue limit was set to 1000 (infinite) Parameters (Cont.)