Predictable Packet Lossand Proportional Buffer Scaling Mechanism

ACEEE Int. J. on Network Security , Vol. 02, No. 04, Oct 2011

Predictable Packet Lossand Proportional Buffer
Scaling Mechanism
Ramesh K, Mahesh S. Nayak
Dept .of PG Studies in Computer Science, Karnataka University Dharwd, Karnataka, India
{rvkkud, mnayak.kud}@ gmail.com

Abstract—Packet losses at IP network are common behavior at terms of load and capacity. The load should be measured as
the time of congestion. The TCP traffic is explained as in number of sender actively competes for a bottleneck link and
terms of load and capacity. The load should be measured as the capacity as the total network buffering available to those
number of sender actively competes for a bottleneck link and
senders. Though there are many congestion mechanism al-
the capacity as the total network buffering available to those
senders. Though there are many congestion mechanism
ready in practice like congestion window, slow start, conges-
already in practice like congestion window, slow start, tion avoidance, Fast transmit but still we see erratic behavior
congestion avoidance, fast transmit but still we see erratic when there is a large traffic.
behavior when there is a large traffic. The TCP protocol that So the router queue lengths should vary with the number
controls sources send rates degrades rapidly if the network of active connections. The TCP protocol that controls sources
cannot store at least a few packets per active connection. Thus send rates degrades rapidly if the network cannot store at
the amount of router buffer space required for good least a few packets per active connection. Thus the amount
performance scales with the number of active connections of router buffer space required for good performance scales
and the bandwidth utilization by each active connections. As
with the number of active connections. If, as in current
in the current practice, the buffer space does not scale in this
practice, the buffer space does not scale in this way, the
way and router drops the packet without looking at bandwidth
utilization of each connections. The result is global result is highly variable delay on a scale perceptible by users.
synchronization and phase effect as well as packet from the Router will provision the buffering mechanism when
unlucky sender will be frequently dropped. The simultaneous processing slows down. Normally there are two types of
requirements of low queuing delay and of large buffer algorithm used to determine the buffer size. First, Delay-
memories for large numbers of connections pose a problem. bandwidth product of memory. This is the minimum amount
Routers should enforce a dropping policy by proportional to of buffering that ensures full utilization when number of TCP
the bandwidth utilization by each active connection. Router connection share drop-tail router. With any less than full
will provision the buffering mechanism when processing slows
delay bandwidth product of router memory the TCP window
down. This study explains the existing problem with drop-tail
would sum to less than delay bandwidth product of memory.
and RED routers and proposes the new mechanism to predict
the effective bandwidth utilization of the clients depending Second is the buffering is only need to absorb transient burst
on their history of utilization and drop the packet in different in the traffic. This is true as long as the traffic sources can be
pattern after analyzing the network bandwidth utilization at persuaded to send at rate that consistently sums to close
each specific interval of time link bandwidth.

Keywords—Random Early Detection; Drop-Tail; packet II. THE PROBLEM
dropping probability;
How much packet buffer memory should router ports
I. INTRODUCTION contain? Previous work suggests two answer. First, one delay-
bandwidth product of packet storage. An abstract
Packet buffers in router/switch interfaces constitute a justification for this is that it allows for the natural delay at
central element of packet networks. The appropriate sizing of which the end system reacts to signals from the network [2,
these buffers is an important and open research problem. 3]. A TCP specific justification is that this is the minimum
Much of the previous work on buffer sizing modeled the amount of buffering that will ensure full utilization when a
traffic as an exogenous process, i.e., independent of the TCP connection shares a drop-tail router [4]. Another answer
network state, ignoring the fact that the offered load from is that buffering is only needed to absorb transient bursts in
TCP flows depends on delays and losses in the network. In traffic[1].This is true as long as the traffic sources can be
TCP-aware work, the objective has often been to maximize persuaded to send at rates that consistently sum to close to
the utilization of the link, without considering the resulting the link bandwidth. RED, with its ability to desynchronize
loss rate. Also, previous TCP-aware buffer sizing schemes TCP window decreases, should be able to achieve this Both
did not distinguish between flows that are bottlenecked at of these answers effectively use packet discard as the only
the given link and flows that are bottlenecked elsewhere, or mechanism to control load. This thesis suggests using a
that are limited by their size or advertised window. combination of queuing delay and discard instead.
The need for buffering is a fundamental “fact of life” for Much of this thesis deals with how a TCP network should
packet switching networks. The TCP traffic is explained as in cope with high load and congestion. Load encompasses le
© 2011 ACEEE 1
DOI: 01.IJNS.02.04. 523


gitimate user action tend to place the network under strain 1. Drop rate (T): When to drop the packet.
and cause it to behave badly. Congestion is bad behavior 2. What to drop: Which packet need to be dropped.
caused by load. This thesis will argue that an important 3. How much packets need to be dropped (Ndrop): At each
source or measure of load in TCP network is the number of trigger when dropping activity started how much packet need
simultaneous active connections sharing a bottleneck, and to be dropped.
that congestion amounts to loss rates high enough to force 4. Queue length need to be processed to drop packets (maxp):
TCPs into timeout. As entire queue can’t be processed to drop the packet which
The idea that window flow control in general has scaling will increase the delay.
limits because the window size can’t fall below one packet Instead of dropping the packet randomly with some
has long been known [5]. Villamizar [4] suggests that this probability as stated by RED algorithm, the proposed method
might limit the number of TCP flows a router could support, will predict the active senders in the network, and then try to
and that increasing router memory or decreasing packet size drop the packets of the senders depending on their bandwidth
could help. Eldridge [6] notes that window flow control cannot utilization which in turn reduce the window size of the active
control the send rate well on very low-delay networks and senders.
advocates use of rate control instead of window control; no To achieve this we need to maintain the log history of the
specific mechanism is presented. Kung and Chang [7] describe processed packets at the head of the queue. These logs are
a system that uses a small constant amount of switch buffer analyzed at particular intervals to find the top recent
space per circuit in order to achieve good scalable contributor for the network traffic/congestion.
performance.
Flow matrix
One drawback of drop-tail and RED routers is that they
must drop packets in order to signal congestion, a problem TABLE I: TABLE SPECIFIES THE TOP CONTRIBUTER FOR THE TRAFFIC AT 2 MS INTERVAL
particularly acute with limited buffer space and large number
of flows. These packets consume bandwidth on the way to
the place they are dropped, and they also cause increased
incidence of TCP timeouts. The router queue lengths should
vary with the number of active connections. The TCP protocol
that controls sources send rates degrades rapidly if the
network cannot store at least a few packets per active In the above table A1, D1 etc represent the flow. After
connection. Thus the amount of router buffer space required analyzing the log which has been updated during the packet
for good performance scales with the number of active processing at the front of the queue, we maintain a table as
connections and the bandwidth utilization by each active shown above where the first row represents the flow with
connections. If, as in current practice, the buffer space does highest packet at interval of 2ms. First column represents the
not scale in this way and router drops the packet without recent packet arrivals. Once logs analyzed and the top rows
looking at bandwidth utilization of each connections. The of the table contents are considered as the highest
result is global synchronization and phase effect as well as contributor for the network traffic. This will help to decide
packet from the unlucky sender will be dropped. The which packet needs to be dropped when there is queue
simultaneous requirements of low queuing delay and of large overflow. The highest packet contributors are predicted to
buffer memories for large numbers of connections pose a be the top contributor for the further interval as well. So
problem. First, routers should have physical memory in these packets are searched in the queue and dropped
proportion to the maximum number of active connections depending on the rate at which queue is growing.
they are likely to encounter. Second, routers should enforce The distribution of the flow across the flow matrix is stated
a dropping policy by proportional to the bandwidth utilization as exclusive flow factor as shown below.
by each active connection. This study explains maintaining
Exclusive Flow Factor (Eff) = Number of Flows
or varying the router buffer queues depending on number of
Number of unique flow
active connections and dropping policy at router depending
on the bandwidth utilization by each active connection. The
current practice limits the buffer space to not more than what
is required for good utilization. So this study should result
some algorithm which helps in varying the buffer size and
dropping policy depending on the bandwidth utilization by
each active connections.

III. OUR SOLUTION
A. Idea
When the queue is getting filled up to drop the packet Fig 2: Router Buffer Queue
following need to be considered
© 2011 ACEEE 2
DOI: 01.IJNS.02.04. 523


ql is the total queue length of the router. Iql is the Avg and two thresholds, maximum threshold Maxth and mini-
instantaneous queue length at a given point of time. mum threshold Minth. As the average queue size Avg is un-
Hmin and Hmax are the minimum and maximum queue der the minimum threshold Minth, all incoming packets are
length respectively, which administrator can set. enqueued sequentially. As the average queue size Avg is
Now once the queue length is exceeded Hmin value, we need over the maximum threshold Maxth, all arriving packet are
to go to end of the queue(Iql) and start processing from there dropped unconditionally. As the average queue size Avg
to drop a packet, but how many packets to be processed to ranges between the minimum threshold Minth and the maxi-
drop the packets from the end of the queue is decided by mum threshold Maxth, the nominal packet dropping prob-
maxp. ability Pb is given by the following equation (2):
Pb = Maxp × ((Avg-Minth)/(Maxth- Minth)) (2)
Maxp = Iql – Hmin
Here, Maxp is the preset packet dropping probability. Pb is
Eff
the nominal packet dropping probability varying from 0 to
where Iql is the instantaneous queue length at the time of
Maxp linearly and evenly, but RED algorithm throws the
processing then we need to process maxp number of packet
packet away by the actual packet dropping probability Pa as
starting from Iql of the queue.
(3):
Once the processing started from Iql we will look at the
flow matrices to decide which packet need to be dropped. Pa = Pb / (1-count×Pb) (3)
Now once started processing from the end of the queue (Iql) where count means the number of enqueued packets since
how many packet need to be dropped is calculated by the the last packet is dropped. The actual packet dropping
factor called Ndrop. probability Pa is used to make the packet dropping probability
Ndrop = Iql-Hmin raise slowly with the increasing count.
(ql-Iql)Eff As for MRED algorit hm [9], it is modified from RED
Once all these three parameters are decided (maxp, Ndrop, algorithm as its name. In addition to the condition of Avg >
flow matrix). We need to find the frequency at which we will Maxth, the primary idea of MRED algorithm takes an extra
drop the packet with above considerations. When we look at condition of q > Maxth into account to decide if packets are
the rate at which the queue grows will decide on when to dropped directly. MRED algorithm can provide higher
drop the packet. So when the queue grows beyond the Hmin transmission throughput and avoid the sensitivity of RED
at each interval of time (T) queue length is calculated and performance to the parameter setting.
decided on packet drop, This is because a few parameters of RED algorithm may
if (Iql > 0.25(ql-Hmin)+Hmin). result in an opposite effect on the queue management
mechanism under various network conditions. Against the
B. Conventional red and mred
inaccuracy and inefficiency above, this paper puts
In conventional RED algorithm [8], it measures the average concentration on regulating the nominal packet dropping
queue size to evaluate the degree of network congestion at probability progressively by applying more parameters and
first. But, due to the quick diversity of network condition, the segmenting the threshold parameters progressively.
average queue size of the gateway sometimes can’t reflect
the network congestion immediately and precisely. For C. Proposed RED
example, if some gateway’s queue buffer is filled up with If (((0.25(Hmax-Hmin)) + Hmin) > Iql > Hmin)
bursty packets and is soon cleared out, the average queue Identify Packet from the Flow to be dropped
size can’t reflect the proper queue buffer status and
Process till Hmin
instantaneous network congestion situation at all. Instead,
conventional RED algorithm evaluates the degree of Drop a Packet
instantaneous network congestion by way of Exponential Else If (Hmax>Iql> = ((0.25(Hmax-Hmin)) Hmin)
Weighted Moving Average (EWMA) of the original average Calculate Ndrop
queue size as (1):
Calculate maxp
Avg = (l-w) × Avg + q×w (1)
Here, Avg means the average queue size and q represents Identify Drop Flow
the instantaneous queue size. In addition, w is the weighted Drop packets
factor and generally equal to negative power of two. The Else If (Iql > Hmax)
weighted factor w is a preset constant that determines the
Drop Packets
sensitivity of RED gateway to the instantaneous queue size.
It is usually set to slightly small in order to prevent the average Else
queue size Avg from varying too rapidly and dynamically. Enque the Packets
RED algorithm makes use of the average queue size to End If
estimate the network congestion condition and determine
the packet drop probability. The packet drop probability de-
pends upon the relationship between the average queue size
© 2011 ACEEE 3
DOI: 01.IJNS.02.04. 523


IV. SIMULATIONS By default, each TCP sender has an unlimited amount of data
to send. This means that most of the simulations focus on
A. Environment
the steady-state behavior of TCP, rather than its start-up
Most of the simulations described in this thesis were behavior. Some of the simulations use finite length transfers
performed on a uniform configuration designed to highlight which the relevant chapters will describe as they arise.
buffering and flow count issues. As pictured in Figure 1, this The simulations include randomness to avoid
configuration involves N TCP senders converging on router deterministic phenomena that would never occur in the real
A. Router A must send what data it can across its link to world [11]. The connection start time are randomly spread
router B, and either buffer or discards the rest. Thus router A over the first 10 seconds of the simulation and the senders’
is the bottleneck router, and the link from B is the bottleneck access link propagation delays are randomly selected over
link. The intent of this configuration is to capture what range of about 10% of the total. Except for the slight
happens on heavily loaded links. For example, the link from A randomization, all connections experience about the same
to B might be the link from an Internet Service Provider’s round-trip time. This avoids unfairness due to TCP’s
backbone to a customer. Such links usually run slower than tendency to use bandwidth in inverse proportion to the
either the backbone or the customer’s LAN, and thus act as round-trip time. Except when noted, no transmission errors
bottlenecks. are simulated. Thus all packet loss is caused by router A
The simulations use the NS 1.4 simulator [10]. Unless discarding packets in response to congestion. The simulated
otherwise noted, they use the parameters given in Figure 2. drop-tail and random drop routers discard packets when the
Note that Fig 2 implies that the average round-trip queue already contains a full 217 packets. The RED router
propagation delay is100 milliseconds. Since a 10 megabit link drops according to the RED algorithm; there is no hard limit
can send 2170 packets per second, the delay-bandwidth on the amount of buffer memory that RED can use.
product is 217 packets. This means that a single TCP with a The TCP version used in the simulations is Tahoe [12].
64 kilobyte window can only use about half the link capacity. The main difference between Tahoe and the later is that Tahoe
In addition, each sender’s link to router A only runs at 10 invokes slow start after a fast retransmit, whereas Reno uses
times its fair share; this means that if more than 90% of the “fast recovery” [13] to continue in congestion avoidance.
senders are timing out or otherwise idle, the remaining senders Section 6.1 will demonstrate that the behavior of Tahoe and
won’t be able to use the whole link capacity. In practice this Reno are similar for the purposes of this work.
doesn’t happen. Many of the graphs in this thesis have number of flows
on the x axis, and some simulation result (such as loss rate)
on the y axis. Each point typically represents the average of
that result over a single 500-second simulation. The upper
bound on the number of flows presented is typically about
1000. This is not an unreasonable number of flows to expect
a 10 megabit link to support, since it results in the per-flow
fair share being somewhat slower than a modem.
B. Simulation results
To evaluate the performance of RED, MRED, and PRED
Figure 1: Standard simulation configuration. Each of N TCP senders algorithms generally and objectively, the experiment tests a
has its own host and its own link to router A. Router A connects to variety of network topologies. The experiment performs
router B over a bottleneck link various n-to-n (n increases from 10 to 100) symmetric network
topologies as shown in Fig. 3. The amount of TCP connections
increases from 10-to-10 (10x10) to 100-to-100(100x100) for
performance comparison between RED, MRED, and PRED
algorithms.

Figure 2: Summary of simulation Parameters
Figure 3. n-to-n network topology for the experiment
© 2011 ACEEE 4
DOI: 01.IJNS.02.04.523


TABLE I. AVERAGE THROUGHPUT COMPARISON BETWEEN RED, NRED AND PRED proposed PRED algorithm regulates the queue size in the
(UNIT OF THROUGHPUT: KBPS)
queue buffer of the gateway progressively and smoothly.

In the first experiment, this paper performs the average
throughput comparison between RED, MRED, and PRED
algorithms in each network topology. This paper compares
the average throughput between RED, MRED, and PRED
algorithms in the network topology of TCP connections Figure.4 Normalized throughput comparison between RED, MRED
varying from 10-to-10 (10x10) to 100-to-100 (100x100). The and PRED for various network topologies
simulation result is shown in Table I. The total network
bandwidth is constant, the more the amount of TCP
connections is, the less the average throughput of each TCP
connection gets. From Table I, it is obviously verified that
proposed PRED algorithm can achieve higher average
throughput than conventional RED and MRED algorithms
for almost all network topologies.
In the second experiment, this paper performs the
normalized throughput comparison between RED, MRED, and
PRED algorithms in each network topology. The normalized
throughput is defined as the ratio of the number of
successfully received packets to the amount of total
transmitted packets. Note that the successfully received
packets account for both the successfully received non-real
time packets and the delay-sensitive packets that satisfy the Figure. 5 End-to-end average delay comparisons between RED,
MRED and PRED for various network topologies
delay constraint. Fig. 4 shows the normalized throughput
comparison between RED, MRED, and PRED algorithms for
various network topologies.
From Fig. 4, it is clearly shown that the normalized
throughput of conventional RED algorithm is the worst, and
that of proposed PRED algorithm is the best. According to
Table I and Fig. 4, we can see that the proposed PRED
algorithm can realize better network bandwidth utilization and
queue management efficiency under various network
conditions.
In the third experiment, this paper performs the end-to-
end average delay comparison between the transmitter and
receiver. Fig. 5 shows the simulation result about the end-to-
end average delay comparison between RED, MRED, and
PRED algorithms for various network topologies. From Fig.5,
we can see that the proposed PRED algorithm also can Figure 6 Instantaneous queue size situations of RED, MRED and
decrease the end-to-end average delay against conventional PRED gateways
RED and MRED algorithms.
In the last experiment, Fig. 6 illustrates the instantaneous V. CONCLUSION
queue size in the queue buffer versus the operating time for This study explains maintaining or varying the router
RED, MRED, and PRED gateways. buffer queues depending on number of active connections
The maximum queue size in the queue buffer in the and dropping policy at router depending on the bandwidth
experiment is set to 50 packets. From Fig. 6, we can see the utilization by each active connection. The current practice
© 2011 ACEEE 5
DOI: 01.IJNS.02.04. 523


limits the buffer space to not more than what is required for 3. H. T. Kung, Trevor Blackwell, and Alan Chapman. Credit based
good utilization. So this study should result some algorithm flow controlfor an atm network: Credit update protocol, adaptive
which helps in varying the buffer size and dropping policy credit allocation, and statistical multiplexing. In Proceedings of ACM
depending on the bandwidth utilization by each active SIGCOMM, 1994.
4. Curtis Villamizar and Cheng Song. High performance tcp in ansnet.
connections.
Computer Communication Reviews, 24(5), October 1994.
From the viewpoint of the instantaneous queue size, the 5. Dimitri Bertsekas and Robert Gallager. Data Networks. Prentice
PRED algorithm is proposed to adjust the maximum threshold Hall, Englewood Cloffs, New Jersey, 1987.
dynamically to adapt to various network conditions, and 6.Charles Eldrige. Rate controls in standard transport layer
regulates the packet dropping probability progressively by protocols. Computer Communication Reviews, 22(3), July 1992.
comparing the instantaneous queue size with the progressive 7. H. T. Kung and Koling Chang. Receiver-oriented adaptive buffer
maximum queue threshold parameters. allocation in credit based flow control for an atm networks. In
According to all aspects of experimental results, the Proceedings of IEEE Infocom, 1995.
proposed PRED algorithm is shown to realize better network 8. Sally Floyd and Van Jacobson. Random early detection gateways
for congestion avoidance. IEEE/ACM Transactions on Networking,
bandwidth utilization and queue management efficiency
August 1993.
under various network conditions. Also, the end-to-end 9. Gang Feng and A. K. Agarwal and A. Jayaraman and Chee Kheong
average delay can further be reduced by the proposed PRED Siew, “Modified RED gateways under bursty traffic,” IEEE
algorithm. More importantly, the proposed progressive Communications Letters, vol. 8, pp. 323-325, May 2004.
adjustment method can also be applied to other RED-based 10. Steve McCanne and Sally Floyd. Ns (Network Simulator).
algorithms. http://www.nrg.ee.lbl.gov/ns/, June 1998.
11. Trevor Blackwell. Applications of Randomness in System
REFERENCES Performance Measurement. PhD thesis, Harward University, 1998.
12. W. Richard Stevens. Rfc2001: Tcp slow start, congestion
1. B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, avoidance, fast retransmit, and fast recovery algorithms. Technical
C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenkar, J. Wroc Report, Internet Assigned Numbers Authority, John Postel, USC/
lawski, L. Zhang, “ Recommendations On Queue Management and ISI, 4676 Admiralty Way, Marina del Rey, DA 90292, 1997. http:/
Congestion Avoidance in the Internet”, RFC 2309, April.1998. /info.internet.isiedu/in-notes/rfc/files/rfc2001.txt.
2. H. T. Kung and Alan Chapman. The fcvc (flow controlled virtual 13. W. Richard Stevens. TCP/IP Illustrated Volume 1: The
channels) proposal for an atm networks. In Proceedings of the Protocols. Addison-Wesley, 1994.
International Conference on Network Peotocols, 1993.

© 2011 ACEEE 6
DOI: 01.IJNS.02.04. 523

Predictable Packet Lossand Proportional Buffer Scaling Mechanism

More Related Content

What's hot (19)

Viewers also liked (8)

Similar to Predictable Packet Lossand Proportional Buffer Scaling Mechanism (20)

More from IDES Editor (20)

Recently uploaded (20)

Predictable Packet Lossand Proportional Buffer Scaling Mechanism