RWM and Network Congestion Management

Transcription

1 Department of Computer Science and Engineering University of Texas at Arlington Arlington, TX 769 Complementing Current Active Queue Management Schemes with Receiver- Window Modification (RWM) Visvasuresh Victor Govindaswamy, Gergely Záruba and G. Balasekaran {govindas, Technical Report CSE-5-6

2 Complementing Current Active Queue Management Schemes with Receiver-Window Modification (RWM) Visvasuresh Victor Govindaswamy a,*, Gergely Záruba a, G. Balasekaran b a University of Texas at Arlington, Arlington, Texas, U.S.A. b University of Pittsburgh, Pennslyvania, U.S.A. Abstract Explicit Congestion Notification (ECN) and Active Queue Management Schemes such as Random Early Detection (RED), Adaptive Random Early Detection (ARED) and BLUE queues have been proposed for TCP/IP networks to compensate network congestion. However, using ECN requires that ECN be supported by both TCP senders and receivers. This paper presents a novel AQM modification called Receiver-Window Modification (RWM). RWM can be used together with RED, ARED and BLUE queues, to provide congestion avoidance in packet switched networks, especially at ingress and gateway routers. RWM does not require modification to all end system TCP/IP stacks but can be solely implemented in routers. Our RWM scheme helps in reducing the average queue sizes of RED, ARED and even ARED-ECN and RED-ECN queues. By reducing the average queue sizes, RWM queues reduce the queuing delay resulting in significant improvements in one-way end-to-end packet delays and dropped packets. It is also shown that the performance of RED-ECN, ARED-ECN and BLUE-ECN queues is heavily dependent on the queues of the downstream routers. RWM modified queues in ingress or gateway routers are not influenced by the number and state of the downstream router as they will piggyback congestion information to the source in the next available acknowledgement packet. We carry out extensive ns simulations to show our results and to support our claims. Keywords: Active Queue Management (AQM), Buffer Management, Random Early Detection (RED), Congestion Control, Congestion Avoidance.. Introduction TCP (Transmission Control Protocol) is the connection oriented transport layer protocol used in today s Internet. TCP uses the services provided by the IP (Internet Protocol) layer, responsible for end-to-end transfer of datagrams. IP has been designed to work with almost any underlying physical layer thus it does not inherently provide reliable service to applications. TCP provides reliability and transmission rate control to applications. The two transmission control features embedded in TCP are flow control and congestion control: Flow control is responsible to provide means for transmitting nodes to reduce (increase) their transmission rate in order to prevent buffer overload at the receiving node. In TCP, flow.

3 control is enabled by the receiving node directly informing the transmitter about the available buffer size using designated fields in the TCP header. Congestion control on the other hand is a process to deal with buffer overload at each router along the transmission path. If the buffer of a router on the relay path is saturated then the router may drop packets determined by its congestion control policy. In common TCP implementations congestion control employs indirect feedback [], i.e., the transmitting node will assume that a segment was dropped due to congestion if no (within a time period) or negative (in the form of duplicate positive acknowledgments) acknowledgment has been received. The transmission rate of the TCP sender is then drastically reduced to help the routers to recover. More precisely, TCP congestion control consists of two phases called Congestion Avoidance (CA) and Slow Start (SS) []. The CA algorithm slows down the transmission rate of segments, by reducing the allowable number of pending (unacknowledged) segments on the network. More precisely, the congestion window (determining the number of pending packets) will be halved. To increase the transmission rate the SS algorithm is then invoked to exponentially (and after reaching a threshold linearly) increase the load on the network until congestion occurs again, i.e., a packet is dropped again. This drop is detected again by TCP either in a form of a timeout by the transmit timer or by the reception of three duplicate acknowledgements (ACKs). This unique combined behavior of the CA and SS algorithms may lead to what is known as the Global Synchronization Problem []. This problem occurs whenever multiple flows lose packets at the bottleneck router, leading to the flows restarting concurrently, resulting in reduced aggregate throughput. It has also been shown that the sudden changes in the TCP transmission window caused by the interaction of SS and CA create a chaotic process introducing self-similarity in the traffic []. Present day, queue management solutions, such as RED [5] use more sophisticated solutions in the queues of routers to determine which packets to drop thus trying to compensate for the Global Synchronization Problem. We give a detailed description of applying techniques in Section. In the presence of bursty Internet traffic, routers along the path may buffer packets in their queues to absorb/reduce the burstiness. Queuing theory implies that the bigger the queue s capacity is, the more a queue can deal with the burstiness without dropping a packet. Furthermore, recent results have also shown that queuing and aggregation of packets can reduce the order of self-similarity of Internet traffic [6]. Unfortunately, TCP s congestion control can introduce a high variance (resulting in a high delay jitter) in the current buffer sizes. On the other hand, if the maximum buffer size of routers is increased, the TCP senders will be notified about congestion much later. The end-to-end packet delay includes the sum of the queuing delays at each router along the path. In fact, the end-to-end packet delay is the sum of two components: i) the transmission, propagation and processing delays (which can be considered fixed delays); ii) the queuing delays at the routers (which is variable). Hence, the greater the current queue size, the greater the queuing delay will be, increasing the end-to-end packet delay. On the other hand, if the queue size is too small, packets will be dropped regularly due to buffer overflows. Hence, there is a need for solutions to determine an optimal (or sub-optimal) queue sizes. The research area dealing with the above phenomenon is called TCP Queue Management (QM). The aim of QM is to minimize the congestion at the queue; QM needs to differentiate between transient and long-term congestion. Transient congestion takes place when the congestion period is shorter than the reaction time needed for the TCP congestion control mechanisms to kick in. On the other hand, long-term congestion is due to overall heavy traffic load. QM approaches can be divided into two categories: i) passive queue management algorithms, where the queue of the routers needs to fill up before corrective action is taken; and ii) active queue management (AQM) [7], where preventive action is taken before the queue is saturated. AQM algorithms can again be subdivided into:

4 Load based AQM approaches, including Random Exponential Marking (REM) [8], Adaptive Virtual Queue (AVQ) [9] and PI controller [] algorithms. Load based approaches are out of the focus of this paper they are merely mentioned for completeness of discussion. Queue-based AQM, including Random Early Detection (RED) [5], Stabilized RED (SRED) [], Flow RED (FRED) [], Adaptive RED (ARED) [], and Blue []. This paper deals with queue-based AQM, presenting a novel approach called Receiver Window Modification (RWM) for congestion avoidance in TCP. RWM may work with RED and Blue algorithms together relaxing their need for a modified TCP layer at servers and clients. Our approach is specifically designed for egress and gateway routers. The main idea of the approach is to restrict the TCP transmission window with the flow control window instead of the congestion control window, thus controlling the transmission window with a finer granularity. Results from simulations show that the RWM modified queues improve on the average queue size, the one-way packet delay and throughput as compared to RED, RED-ECN, and Blue queues (explained in detail later), especially in paths that have non-ecn compliant routers. Moreover, RWM does not require modification to TCP implementations at servers or clients, i.e., no RWM-compliancy is needed. The rest of the paper is organized as follows: Section covers the necessary background information and previous work. In Section, the RWM scheme is introduced; simulation details, results as well as analysis are covered in Section. The paper is concluded and future research directions are outlined in Section 5.. Background Information This section gives an overview of the various major topics involved in active queue management research. After a short general introduction, section. provide a review of conventional queue management techniques; section.5 provides an overview of the ECN mechanism while sections.,. and. provide brief insight into RED, ARED and BLUE AQMs respectively. Section.5 then outlines various previous works using the TCP flow control receiver advertised window for congestion control purposes. As outlined in the previous sections current TCP implementations [][] contain a number of algorithms aimed at controlling network congestion. The algorithms used by TCP include SS, CA, fast-retransmit, and fast recovery. For the purpose of this paper, only SS and CA algorithm is investigated. These algorithms depend on the senders and receivers buffers. The sender has a congestion window, called cwnd, which is initialized to a single segment (maximum segment size is announced by the receiving side) at the start of a new connection. During the slow-start, each time an acknowledgement packet, ACK, is received from the receiver, the cwnd is increased by a segment. The sender transmits packets (bytes) up to the minimum of the congestion and the advertised received window sizes. The advertised receiver window is the actual flow control imposed by the receiver based on the amount of available buffer space at the receiver for the connection whereas the congestion window is a flow control imposed by the sender based on its assessment of perceived network congestion. SS is used to initiate data flow across a connection. After some point, the limit of a queue in an intervening router is reached thus packets may be dropped at that router. Congestion avoidance is a way to deal with lost packets. There are two indications to packet losses: timeout occurring and the receipt of duplicate ACKs. When congestion occurs, the transmission rate of packets into the network needs to be reduced, when the congestion is resolved SS is activated to increase the transmission rate again. The CA and SS algorithms are meant to work together. The CA algorithm has a variable called ssthresh which determining the actual SS threshold size. At the start of a transmission, the cwnd is initialized to one segment size while ssthresh to 6Kbytes. When congestion occurs (indicated by timeout or reception of duplicate ACKs), half of the

5 current window size (the minimum of cwnd and the receiver s advertised window, but at least two segments) is saved in ssthresh. Additionally, if the congestion is indicated by a timeout, cwnd is set to one segment size. When new data is acknowledged by the other end, the cwnd is increased depending on whether SS or CA is being performed. If the cwnd is less or equal to ssthresh, then SS is activated otherwise CA continues. SS lasts until it reaches the ssthresh (half of where it was when congestion occurred), and then CA takes over. SS increments the cwnd by one segment, every time an ACK is received (thus increasing the cwnd approximately binary exponentially within a roundtrip time). On the other hand, CA dictates that cwnd be incremented by /cwnd each time an ACK is received (thus increasing the cwnd by approximately one segment size in each round trip delay). Thus, packet drops are important indication of congestion for the TCP layer to decrease the transmission rate of flows... Conventional Queue Management Techniques Initial congestion queue management research has dealt with Tail Drop (Drop Tail) [], Drop-from-front [5] Random Drop [6] and Early Random Drop [][5] techniques. In Drop Tail queues, packets arriving after the queue becomes saturated are dropped. Packets will continue to be dropped until buffer space becomes available in the queue. The advantages of this type of QM are that it is simple, fast and easy to implement. However, on the downside, Drop Tail:. Congestion control is not invoked until queues become saturated, thus congestion is not signaled until queues are full;. Leads to global synchronization, i.e., it does not allow maximal utilization of link capacity because of synchronous oscillation of the TCP transmission rate;. has no control over which packets are dropped;. has fairness problems since a sudden traffic burst from one source may fill up all the available buffer space and as a consequence 5. suffers from the lockout phenomenon whereby a single flow may not be able to get any packets through, if a window of segments arrives just when the queue gets saturated. To solve the fairness problem, the queue could be subdivided into many sub-queues with different service classes. However, this will lead to packets being discarded even if there is available buffer space in the queue. In Drop-from-front, congestion is signaled earlier to the TCP sources by dropping the packets at the front of the queue when the queue becomes saturated. This will lead to acknowledgements being sent back to the sender quicker which, in turn, results in faster invocation of congestion control action by TCP. However Drop-from-front introduces a major fairness-flaw. In Random Drop, the packet to be dropped is randomly selected, when the queue becomes saturated. This helps avoid global synchronization since it is highly unlikely that it will drop packets from most or all of the flows at the same time, as was in the case of the Drop Tail. It also prevents the lockout problem since the dropping probability of packets is proportional to the bandwidth consumption of the flow the packet belongs to. One of the first solutions that reacted to congestion before the queue became saturated was the Early Random Drop (ERD) mechanism. This scheme defines a queue length threshold value at some fraction of the total available queue size. Segments arriving after the queue size has reached this threshold will be randomly dropped (with a fixed probability). The disadvantage of this scheme is that it does not guarantee a fair treatment between flows nor does it guarantee that the contents of the queue will reflect the flow distribution of different sources. Moreover, ERD is bias against large bursts [7] since it favors flows with small amounts of segments. 5

6 .. Random Early Detection Random Early Detection (RED) [5] employs a dual-threshold approach defining a minimum threshold value (MIN th ), a maximum threshold value (MAX th ), and a variable dropping probability P a P max. RED prevents global synchronization by sacrificing a specific data flow whenever the average queue length increases to a point where the overflow may soon occur. It picks a flow fairly and discards a packet, forcing the flow into congestion avoidance and hence, decreasing its aggregate transmission rate. It does this continuously until the average queue length decreases to a stable level, thus providing a bound to its average queue length. The probability that the gateway chooses a particular flow to mark or drop during congestion is roughly proportional to that flow's share of the bandwidth at the router. In short, it is valid to say that if a flow has a large fraction of the recently dropped packets, then it has also most likely received a large portion of the recent bandwidth. (RED also avoids biasness against bursty traffic.) However, despite these advantages, there are some well-documented problems with RED [] [][8][9][]. The level of congestion with its immediate links (neighbors), compounded with its complex parameter tuning [9][] induces large variations in the queue size. The queue size is near MIN th, whenever the link is lightly congested or the P max is high. However, the queue size increases to around MAX th with an increase in the congestion levels or if P max is set to a low value. Both these situations result in a degraded throughput, i.e., RED may underperform even the Drop-Tail mechanism []. RED may also introduce jitter into non-bursty streams. All these disadvantages have generated more research using RED as a starting point for further improvements [8][][][][]. There are two parts to the RED algorithm; the estimation of average queue size (see pseudocode in Figure ) and the decision on which packet to drop (see pseudo-code in Figure ). The purpose of RED is to make the network more capable of accommodating bursty traffic rather than shaping bursty traffic to accommodate the needs of the network. It uses FIFO scheduling due to FIFO s: i) low overhead, ii) lack of scaling problems, and iii) reduction of weight of the tail of the delay distribution. If the average queue length is smaller than MIN th, then the arriving segment is accepted. If the average queue length is between MIN th and MAX th, then the segment is dropped with probability P a. P a is a linear function of the average queue length, possibly increasing to a pre-determined maximum value P max. However, if the calculated average queue length is larger than MAX th, then incoming segments are dropped with probability one. This behavior results in a larger virtual queue size for short-term bursts compared to long-term bursts. There are a number of variations of RED, such as Adaptive RED (ARED) [], Random Exponential Marking (REM) [8], Blue [], Balanced RED [] and RED with Preferential Dropping []. We are going to outline ARED and Blue in subsequent section as they are the most advanced AQM schemes available today. Figure. Average queue size estimation algorithm 6

7 Figure. Dropped packet selection algorithm.. Adaptive Random Early Detection (ARED) Adaptive RED (ARED) [] is one of the many versions of RED with modifications to the original Adaptive RED proposal of Feng et al. [], []. It is geared to achieve a predefined target queue length and hence lower packet loss and minimum variance in queuing delay. More importantly, it aims to solve the complex parameter setting problem in RED. In ARED, P max is not constant but is changed (adapted) at.5s intervals to keep the average queue around (MIN th + MAX th )/. (P max is bounded between. and.5.) The pseudo code of P max adaptation is shown in Figure (an additive increase multiplicative decrease (AIMD) technique is used for adapting P max ). Figure. Algorithm to adapt Pmax.. BLUE The BLUE active queue management algorithm [5] uses packet loss and link utilization history to manage congestion by detecting and adjusting the rate of packets being dropped or marked. It uses the probability, P m, to mark (by using ECN) or drop queued packets. P m is increased whenever packets are dropped from the queue and decreased when the link is underutilized. The amount of increase by P m is denoted by δ while δ represents its amount of decrease. This update on P m takes place, whenever the queue length exceeds a certain threshold L, at the rate of /freeze_time. The parameter freeze_time represent the time interval between successive updates on Pm. Figure shows a sample pseudo code of the BLUE algorithm. 7

8 Figure. BLUE algorithm.5. Explicit Congestion Notification Explicit Congestion Notification (ECN) has been suggested in [6][7] as an addition to the RED, ARED and BLUE AQMs. The ECN mechanism is used to notify the sender TCP process about congestion, before it actually happens thus preventing unnecessary packet drops. Whenever the average queue size is between MIN th and MAX th, RED is modified to mark instead of drop segments. An ECN-compliant TCP source, on receiving the marked ACK packets (echoed from the ECN-compliant TCP receiver), will behave in a manner similar to as if it had encountered a dropped packet. This collaborative effort between the TCP sender and its receiver decreases average queuing delay and increases throughput. The response of TCP source to the congestion should happen at most once per round trip time (RTT). ECN avoids unnecessary packet drops and accelerates the detection of congestion by the source, without having to wait to detect a dropped packet (a timeout from the transmit timer or on receiving three duplicate ACKs). However, as a downside: i) ECN messages may get lost; and ii) TCP implementations at both the source and the destination have to be ECN-compliant (which presents a significant problem in today s implementations). Currently there is no practical benefit in setting ECN bits in Internet packets; as this requires ECN capable routers (at least at bottleneck points), servers and clients throughout a network. In [8], experiments were conducted using TBIT (the TCP Behavior Inference Tool) showing that in Sept., results, out of 67 (.7%) sites positively responded with an appropriate SYN/ACK. In March, only 7 out of 6 sites (.5%) responded positively. These tests included nearly all types of operating systems, including Windows and Linux. A TCP sender reacts to an ECN flagged segment by halving both the congestion window cwnd and the slow-start threshold ssthresh at most once per RTT, while ignoring succeeding ECNs within that particular RTT. This is to ensure that the TCP source does not reduce its window repeatedly within that particular RTT. However, when the ECN-compliant TCP sender receives three duplicate ACKs without any ECNs, it will undergo Fast Retransmit and Fast Recovery procedures (see TCP Reno []). On the other hand, if the ECN-compliant TCP sender receives three duplicate ACKs after a reaction to an ECN notification within the RTT, it will not react since it has already reacted to the ECN notification. To facilitate the ECN scheme, TCP uses a -bit ECN field [7] in the IP header (see Figure 5), with a possibility of marking four ECN codepoints from to. Bit sequence is known as the Congestion Experienced (CE) codepoint which is used to indicate congestion to the end nodes. Codepoints and, (also known as ECT() and ECT() respectively,) are used by the TCP sender to denote that it is ECN-capable. An ECN-compliant sender will use both of these codepoints to ensure that the routers along the path are not erasing the CE codepoint and that an ECN-compliant receiver is not erroneously reporting to the ECN-compliant sender the reception 8

9 of packets with CE codepoints. Routers (that are ECN compliant) along the path treat both of these codepoints similarly. The codepoint (default assignment in any IP datagram) indicates that the packet is not using ECN. ECN Version Header Length Identification Time To Live Type of Service Protocol Flags 8 Source IP Address Destination IP Address Options (if any) Data (if any) 9 Figure 5. ECN bit in IP header 5 Total Length 6 7 Fragment Offset Header Checksum The TCP header will also have to contain information for ECN. Flags: Congestion Window Reduced (CWR) and ECN-Echo (ECE) are introduced into the TCP header as shown in Figure 6. ECE is used for negotiating ECN-capability between TCP senders and receiver, whereas the CWR is used by the TCP sender to inform the TCP receiver that the congestion window has been reduced (so that the TCP receiver can determine when to stop setting the ECN-Echo flag). 8 9 CWR ECE Data Offset 5 6 Reserved Source Port ECN Checksum Acknowledgment Number Control Bits Sequence Number Options (if any) Data (if any) Destination Port Window Size Urgent Pointer Figure 6. The CWR and ECE bits (in bytes and ) of the TCP header A typical sequence of events is as follows. After positive negotiation between the sender and the receiver about using ECN, the sender sets the ECT codepoint in the packet s IP header. When an ECN-capable router detects congestion, it selects a packet. If the packet had its ECT codepoint set, instead of dropping it, the router sets the packet s CE codepoint in its IP header, to indicate to its sender of the impending congestion. On receiving this packet, the TCP receiver sets the ECE flag in its next ACK packet to the TCP sender. When the TCP sender receives this ACK packet, it will react as if it had encountered a packet dropped. It will also set the CWR flag in the TCP header of the next packet it sends to the receiver acknowledging the reception of the ACK with its ECE flag set (and that it had reacted to the impending congestion)..6. Rate Control/Enforcement Techniques As outlined in the introduction, a TCP stream may either be constrained by flow or congestion control (i.e., whichever window is smaller). Flow control compared to congestion control is a direct feedback process where the TCP receiver tells the TCP sender explicitly what its transmission window should be set at. Modifying the receiver window (the corresponding TCP header field) at intermediate routers can thus provide a mean to set TCP senders transmission

10 window explicitly. To improve overall communication latency an intermediate network element may modify the receiver s advertised window in the returned TCP acknowledgments. This rate control or enforcement technique has been used in [9][][][8][9] and was made popular by Packeteer, Inc. [] in 995. This technique is referred to as Explicit Window Adaptation in [9], where the objective is to match the sum of the windows of active TCP connections sharing the buffer in the edge router to the effective network bandwidth delay product, thus avoiding packet losses whenever possible. Hence, the receiver s advertised windows in TCP acknowledgments are modified at the edge router. The feedback loop in their scheme extends only from the ATM Access Points (AAPs) to the sources of the TCP connections. In [8], Karandikar et al use a similar technique, as part of their TCP Rate Control, to achieve high throughput, fairness and low delay. They calculate the rate feedback to fit ATMs Available Bit Rate (ABR) service [][6][8]; and then translate the rate into a window value to give feedback to the TCP source. Siu et al in [] extend [8] by defining a complex TCP emulation engine at the rate-controller using an acknowledgment bucket scheme In [9], Satyavolu et al suggest a rate-to-window translation scheme based upon another ATM ABR algorithm, ERICA [6]. All these authors explored such ideas from the point of view of TCP/IP-ATM internetworking, i.e. extending ATM ABR type rate control from ATM edges to TCP end systems.. Receiver-Window Modification (RWM) AQM solutions use packet drops at router queues to manipulate the TCP sender into decreasing its transmission rate. RED, ARED and BLUE prevent a queue in any intervening router from reaching its limit. With ECN-compliant RED, ARED or BLUE queues, packets are not unnecessarily dropped but marked as if they were dropped. We denote these types of queues as RED-ECN, ARED-ECN and BLUE-ECN respectively. We are proposing to use flow control feedback to reduce congestion at routers. Instead of setting ECN related bit in the chosen packets of RED, ARED and BLUE queues, we propose the use of receiver window modification (RWM). RWM sets the receiver window field to one maximum segment size (MSS) in the ACK packets that are going towards the sender from the receiver. We denote RWM modification to AQM schemes by affixing RWM after the name of the AQM, thus we will be talking about RED-RWM, ARED-RWM and BLUE-RWM respectively. For example, the RED algorithm (as shown in Figure ), is modified to what is shown in Figure 7. (Whenever the TCP header of an ACK packet is modified, the checksum in the TCP header needs to be adjusted for error control.) Figure 7. RED-RWM Algorithm The advantages of RWM queues are that they work with the current implementation of TCP in end systems and do not require drastic changes to the existing network schemes. Hence, Some researchers claim that routers in general should not look at layer- headers as their function is limited to layer-. Yet, enabling them to do so can provide significant benefits (see e.g., NAT).

11 they overcome the disadvantages of the ECN queues since TCP/IP stacks will not require modifications to be ECN-compliant. Since, the feedback loop extends from the RWM queue on a router to the sender; the response of the algorithm is determined by the delay between the router and the sender rather than the RTT of the connection, which is true in the case for the queues using the ECN mechanism (assuming that there are other ACK packets flowing from the receiver to the sender). The delayed response of the sender to an ECN is further compounded if the congestion worsens at the other routers lying between the router and the receiver. The response time will also be heavily dependent on the types of queue implementations in these routers. The queues using the RWM mechanism enjoy the advantage of faster response times to the impending congestion since the notification of congestion arrives at the source quicker when compared to those using ECN mechanism.. Simulation Results We have conducted an extensive simulation experiment to evaluate and compare AQM algorithms without ECN, with ECN and with our proposed RWM scheme. Our simulations were based on an extended and corrected (the receiver window congestion window interaction in NS does not follow a common linux-type TCP implementation) NS [] simulator. The subsequent subsections explain the details and discuss the results of the different simulation scenarios. We compare AQM schemes on the simple network topology of sources connected to a sink via routers as shown in Figure 8; the nearest router to the sources employs the AQM to be investigated while the other routers contain Drop Tail queues which are kept large enough not to discard any packets... Scenario RED AQM We first study the performance of TCP with RED, RED-ECN and RED-RWM using the During the interval (, 5) seconds, four File Transfer Protocol (FTP) connections are started at time t = s with the size of the RED queue set at 5 packets. The end systems use the TCP-Reno implementation of NS-. The RED parameters were set as follows (conforming to [7]): Queue weight given to current queue size sample =. Minimum threshold of average queue size (MIN th ) = 5 Maximum threshold of average queue size (MAX th ) = 5 Max probability of dropping a packet = /linterm, where linterm = FTP Sources M RED Queue Drop Tail Queues M.5M M M M Sink M Figure 8. Simulation network topology for scenario Simulation results were obtained for RED, RED-ECN and RED-RWM AQMs employed in the first router. Figure 9 depicts the average queue size versus the simulation time of the

12 investigated AQMs. RED-RWM reduces the average queue size by about 5% compared to RED and RED-ECN. In the case of the RED-ECN queues, the larger queue sizes are partly due to marked packets suffering congestion, increasing the delay along their way to the destination and then being echoed back to the source via ACK packets. On the other hand, the feedback loop for the RED-RWM is much shorter and hence, the average queue sizes are closer to the minimum threshold of average queue size (MIN th ) of 5 packets. Smaller queue sizes imply smaller queuing delay and as a result, there is an improvement in the one-way delay with RED-RWM as compared to those obtained with RED-ECN and RED queues. 6 Number of Packets Time (s) RED RED-ECN RED-RWM Figure 9. The average queue sizes for RED, RED-ECN and RED-RWM Keeping the same topology and RED parameters but varying the number of sources, RED, RED-ECN and RED-RWM we investigate their performance by collecting essential data and analyzing them in terms of i) delay jitter (the variation in the time taken for packets to be transmitted from the source to the destination in a network.); ii) average packet delay, iii) number of packets dropped; and iv) throughput. Figure, Figure, Figure and Figure show the respective results obtained for seconds of simulation time. The results confirm that RED- RWM outperforms both RED and RED-ECN in all of the above metrics. The average packet delay of RED-RWM is 5-% less than that of RED-ECN and RED. Moreover, RWM significantly and consistently reduces the variation of the delay by about 5%. Our scheme also outperforms its counterparts in terms of overall throughput and packet drops.

13 6 5.5 Time (ms) RED RED-ECN RED-RWM Figure. Average packet delay for RED, RED-ECN and RED-RWM.5 Time (ms) RED RED-ECN RED-RWM Figure. Delay Jitter for RED, RED-ECN and RED-RWM Link Utilization (%) RED RED-ECN RED-RWM Figure. Throughput for RED, RED-ECN and RED-RWM

14 Number of Packets RED RED-ECN RED-RWM Figure. Total packet drops for RED, RED-ECN and RED-RWM.. Scenario ARED AQM Here, we investigate the performance of an ARED, ARED-ECN and ARED-RWM queues using the network topology and RED parameters of Scenario. The average queue sizes for ARED, ARED-ECN and ARED-RWM are compared with each. Generally, it can be observed that the average queue size for ARED-RWM is smaller than those of ARED (Figure - The average queue size curves of ARED and ARED-ECN are comparable and semi-overlapping) and ARED-ECN. This is due to faster response times to the impending congestions since the notification of congestion for ARED-RWM queue arrives at the source faster when compared to the ECN (in the case of ARED-ECN) and the timeout (in the case of ARED) mechanisms. Note, that for the ARED-ECN queue the notification is delayed by all of the queuing delays of the downstream routers. The average queue sizes for ARED-RWM are about 5% smaller compared to those of ARED-ECN and ARED. 6 ARED ARED-ECN ARED-RWM Number of Packets Time (s) Figure. The average queue sizes for ARED, ARED-ECN and ARED-RWM Keeping the same topology and RED parameters but varying the number of sources (increasing the duration of the experiments to s), ARED, ARED-ECN and ARED-RWM queues were compared on their one-way packet delay, delay jitter, number of packet drops and

15 throughput. Figure 5, Figure 6, Figure 7 and Figure 8 show the results that confirm that ARED-RWM outperforms ARED and ARED-ECN in all of these categories. Time (ms) ARED ARED-ECN ARED-RWM Figure 5. Average packet delay for ARED, ARED-ECN and ARED-RWM.5.5 Time (ms) ARED ARED-ECN ARED-RWM Figure 6. Delay jitter for ARED, ARED-ECN and ARED-RWM Link Utilization (%) ARED ARED-ECN ARED-RWM Figure 7. Throughput for ARED, ARED-ECN and ARED-RWM 5

16 Number of Packets ARED ARED-ECN ARED-RWM Figure 8. Total packet drops for ARED, ARED-ECN and ARED-RWM.. Scenario - Blue AQM Here, we investigate the performance of BLUE, BLUE-ECN and BLUE-RWM queues using the network topology of scenario. We use the following BLUE parameters [5]: Freeze_time = ms δ =. δ =. threshold L = 5 packets The average queue sizes for BLUE, BLUE-ECN and BLUE-RWM are shown in Figure 9. There is little difference between BLUE, BLUE-ECN and BLUE-RWM. BLUE BLUE-ECN BLUE-RWM Number of Packets Time (s) Figure 9. The average queue sizes for BLUE, BLUE-ECN and BLUE-RWM Keeping the same topology and BLUE parameters but varying the number of sources, BLUE, BLUE-ECN and BLUE-RWM queues are evaluated in terms of their one-way packet delay, delay jitter, number of packet drops and throughput; Figure, Figure, Figure and Figure show the respective results. In terms of packet delay, BLUE-RWM outperforms BLUE-ECN as the number of sources is growing. In terms of the delay jitter, number of packet drops and throughput, BLUE-RWM significantly outperforms BLUE and BLUE-ECN. 6

17 Time (ms) BLUE BLUE-ECN BLUE-RWM Figure. Average packet delay for BLUE, BLUE-ECN and BLUE-RWM.5. Time (ms)..9.7 BLUE BLUE-ECN BLUE-RWM Figure. Delay jitter for BLUE, BLUE-ECN and BLUE-RWM Link Utilization (%) BLUE BLUE-ECN BLUE-RWM Figure. Throughput for BLUE, BLUE-ECN and BLUE-RWM 7

18 5 Number of Packets 5 5 BLUE BLUE-ECN BLUE-RWM Figure. Total packet drops for BLUE, BLUE-ECN and BLUE-RWM.. Comparing RED-RWM, ARED-RWM, and BLUE-RWM In this subsection we are comparing RED-RWM, ARED-RWM, and BLUE-RWM AQMS in terms of average packet delay, delay jitter, number of packet drops and throughput Figure, Figure 5, Figure 6 and Figure 7 show the respective simulation results. Overall, BLUE-RWM outperforms both RED-RWM and ARED-RWM as the number of sources increases. There is only slight difference between RED-RWM and ARED-RWM. 6 5 Time (ms) RED-RWM ARED-RWM BLUE-RWM Figure. Average packet delay for RED-RWM, ARED-RWM and BLUE-RWM Time (ms) RED-RWM ARED-RWM BLUE-RWM Figure 5. Delay jitter for RED-RWM, ARED-RWM and BLUE-RWM 8

19 Link Utilization (%) RED-RWM ARED-RWM BLUE-RWM Figure 6. Throughput for RED-RWM, ARED-RWM and BLUE-RWM Number of Packets 5 5 RED-RWM ARED-RWM BLUE-RWM Figure 7. Total packet drops for RED-RWM, ARED-RWM and BLUE-RWM 5. Conclusions and Future Work In this paper we have proposed a modification to existing adaptive queue management protocols (AQM) called Receiver Window Modification (RWM). RWM does not require modification to all end system TCP/IP stacks but can be solely implemented in routers (especially gateway routers). This means that RWM does not require both the sources and receivers to be RWM-compliant as was the case for ECN-compliant queues. Our RWM scheme helps to reduce the average queue sizes of the ARED-ECN and RED-ECN queues. By reducing the average queue sizes, RWM queues reduce the queuing delay resulting in significant improvements in one-way end-to-end packet delays and dropped packets. It is also shown that the performance of RED-ECN, ARED-ECN and BLUE-ECN queues is heavily dependent on the queues of the downstream routers. RWM queues in gateway routers are not influenced by the number and state of the downstream router as they will piggyback congestion information to the source in the next available acknowledgement packet. We have used the NS simulator to carry out simulation experiments validating the RWM scheme. Research is underway to implement RWM in Linux based packet routers and to mathematically model RWM s behavior. References [] V. Jacobson, Congestion Avoidance and Control, Proceedings of ACM SIGCOMM 988, pp. - 9, August, 988. [] W. Stevens, TCP/IP Illustrated, Volume : The Protocols, Addison-Wesley, 99. 9

20 [] L. Zhang, and D. Clark, Oscillating Behavior of Network Traffic: A Case Study Simulation, Internetworking: Research and Experience, pp. -, vol., June, 99. [] A. Veres and M. Boda, The Chaotic Nature of TCP Congestion Control, Proceedings of INFOCOM, pp. 75-7, vol., March,. [5] S. Floyd and V. Jacobson, Random early detection gateways for congestion avoidance, IEEE/ACM Transactions on Networking, pp. 97-, vol., no., August, 99. [6] R. Huang, and G.V. Záruba, Effect of Ingress Buffering on Self-Similarity of Optical Burst traffic, Proceedings of OptiComm, October,. [7] M. Kwon, and S. Fahmy, A comparison of load-based and queue-based active queue management algorithms, Proceedings of the International Society for Optical Engineering, pp. 5-6, vol. 866, July/August,. [8] S. Athuraliya, S.H. Low, V.H. Li and Y. Qinghe, REM: Active Queue Management, IEEE Network, pp. 8-5, vol. 5, issue, May,. [9] S. Kunniyur and R. Srikant, Analysis and Design of an Adaptive Virtual Queue (AVQ) Algorithm for Active Queue Management, Proceedings of the conference on applications, technologies, architectures, and protocols for computer communications, pp., August,. [] C.V. Hollot, V. Misra, D. Towsley and W.B. Gong, On Designing Improved Controllers for AQM Routers Supporting TCP Flows, Proceedings of INFOCOM, pp. 76-7, vol., April,. [] T.J. Ott, T.V. Lakshman, and L.H. Wong, SRED: Stabilized RED, Proceedings of the IEEE INFOCOM 999, pp. 6-55, vol., March, 999. [] D. Lin and R. Morris, Dynamics of random early detection, Proceedings of SIGCOMM 997, pp. 7 6, vol. 7, September, 997. [] S. Floyd, R. Gummadi, and S. Shenker. Adaptive RED: an algorithm for increasing the robustness of RED's Active Queue Management. [] W. Feng, D. D. Kandlur, D. Saha and K. G. Shin, BLUE: an alternative approach to active queue management, Proceedings of the th international workshop on Network and operating systems support for digital audio and video (NOSSDAV ), pp. 5, June,. [5] T.V. Lakshman, A. Neidhardt, and T.J. Ott, The drop from front strategy in TCP and in TCP over ATM, Proceedings of INFOCOM 996, pp. -5, vol., March, 996. [6] V. Firoiu and M. Borden, A study of active queue management for congestion control, Proceedings of INFOCOM, pp. 5 -, vol., March,. [7] S. Floyd and V. Jacobson, On Traffic Phase Effects in Packet-Switched Gateways, Internetworking: Research and Experience, pp. 5-56, vol., September, 99. [8] M. May, J. Bolot, C. Diot and B. Lyles, Reasons Not to Deploy RED, Proceedings of 7 th International Workshop on Quality of Service (IWQoS 99), pp. 6 6, June, 999. [9] M. May, T. Bonald and J. Bolot, Analytic Evaluation of RED Performance, Proceedings of INFOCOM, pp. 5 -, vol., March,. [] V. Misra, W.B. Gong and D. Towsley, Fluid-based Analysis of a Network of AQM Routers Supporting TCP Flows with an Application to RED, Proceedings of SIGCOMM, pp. 5 6, August,. [] W. Feng, D.D. Kandlur, D. Saha and K.G. Shin, A Self-Configuring RED Gateway, Proceedings of INFOCOM 999, pp -8, March, 999. [] J. Aweya, M. Oullete, and D.Y. Montuno, Service differentiation using a multi-level RED mechanism, International Journal of Network Management archive, pp. 8-98, vol., March/April,. [] R. Mahajan, S. Floyd and D. Wetherall, Controlling high-bandwidth flows at the congested router, Ninth International Conference on Network Protocols, pp. 9-, November,. [] W. Feng, D. Kandlur, D. Saha, and K. Shin, Techniques for Eliminating Packet Loss in Congested TCP/IP Network,U. Michigan CSE-TR-9-97, November 997. [5] W. Feng, D. Kandlur, D. Saha, and K. Shin, The BLUE active queue management algorithms, IEEE/ACM Transactions on Networking (TON) Volume, Issue (August ) Pages: 5 58,. [6] S. Floyd, TCP and Explicit Congestion Notification, ACM Computer Communication Review, pp. -, vol., October, 99.

21 [7] K. Ramakrishnan, S. Floyd and D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 68, September,. [8] TBIT, the TCP Behavior Inference Tool. [9] L. Kalampoukas, A. Varma and K.K. Ramakrishnan, Explicit window adaptation: a method to enhance TCP performance, IEEE/ACM Transactions on Networking (TON), pp. 8-5, vol., June,. [] A. Koike, TCP flow control with ACR information, ATM Forum/97-998, December, 997. [] P. Narvaez and K.Y. Siu, An Acknowledgment Bucket Scheme for Regulating TCP Flow over ATM, IEEE GLOBECOM 997, pp 88-8, vol., November, 997. [] B. Wydrowski and M. Zukerman, GREEN: An Active Queue Management Algorithm for a Self Managed Internet, Proceedings of ICC, New York, vol., pp. 68-7,. [] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski and L. Zhang, Recommendations on Queue Management and Congestion Avoidance in the Internet, RFC 9, April, 998. [] R. Jain, S. Kalyanaraman, R. Goyal, S. Fahmy and R. Viswanathan, The ERICA Switch Algorithm for ABR Traffic Management in ATM Networks, IEEE/ACM Transactions on Networking, pp , vol. 8, no., February,. [5] S. Kalyanaraman, R. Jain, S. Fahmy and R. Goyal, Performance and Buffering Requirement of Internet Protocols over ATM ABR and UBR Services, IEEE Communications Magazine, pp. 5-57, vol. 6, no. 6, June 998. [6] S. Kalyanaraman, Traffic Management for the Available Bit Rate (ABR) Service in Asynchronous Transfer Mode (ATM) networks, Ph.D. Dissertation, Department of Computer Science and Information Services, Ohio State University, August, 997. [7] S. Floyd, Ns Simulator Tests for Random Early Detection (RED) Gateways, Technical report, October [8] S. Karandikar, S. Kalyanaraman, P. Bagal and B. Packer, TCP rate control, ACM SIGCOMM Computer Communication Review, pp. 5-58, vol., no., January,. [9] R. Satyavolu, K. Duvedi and S. Kalyanaraman, Explicit rate control of TCP applications, Unpublished Manuscript papers/iwqos99-rate.ps [] Packeteer Inc., [] NS simulator