HAP: A New Model for Packet Arrivals

HAP: A New Model for Packet Arrivals

Ying-Dar Jason Lin, Tzu-Chieh Tsai, San-Chiao Huang and Mario Gerla

Computer Science Department University of California, Los Angeles

Los Angeles, CA 90024

Abstract

Applications to be supported on broadband networks ex- hibit a wide range of trafic statistics and many of them are sensitive to de~ay and loss violations. To accu- rately estimate admissible workload and bandwidth re- quirement, a detailed trafic model, HAP (Hierarchical Arrival Process) is proposed in this paper. Packets gen- erated from HAP are modulated by processes at user, ap- plication, and message levels. This model is a general- ization of on-o~ trafic models and is shown to be equiv- alent to a special class of MMPP (Markov Modulated Poisson Process). Three algorithmic methods along with simulations are applied to evaluate the queueing perfor- mance under HAP trafic. Delay under HAP trafic can be well over tens of times higher than Poisson trafic, depending on parameters and load. Congestion may per- sist for minutes. HAP’s dramatic short-term behavior explains the occasional congestion m the real networks.

Conventional tra&ic models, however, do not exhibit this behavior. With these results, we give implications for broadband network control.

1 Introduction

Ever since the early development of ARPANET [1], much efforts have been devoted into both measurements and modeling of computer network traffic and perfor- mance. In the measurement sector [2], the measurement environments range from wide area networks [1, 3] to lo- cal area networks [4, 5, 6]. In the modeling sector, the analytic traffic models fall mainly in the categories of Poisson and MMPP (Markov Modulated Poisson Pro- cess) [7, 8, 9].

A recent trace-driven simulation study [61 however in- dicates that real computer network traffic has extreme traffic variability on time scales ranging from millisec- onds to months, which is not captured by conventional Poisson or MMPP traffic models. The study shows that, Permission to copy without fee all or part of this material ie granted providad that tha copies are not made or distributed for diract commercial edvantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

SIGCOMM’93 - Ithacar N. Y., USA /9/93

a 1993 ACM 0-89791-61 9-0193/00091021 2...$1.50

when the real traffic is fed into a network simulator, per- formance behavior is much worse than the one predicted using analytic traffic models. During congested periods, congestion persists and losses can be significant. There is, indeed, a gap between the behavior under real traffic and that produced by analytic traffic models.

Traffic results from the interaction of various traffic sources. Thus, network traffic depends on the way traf- fic sources behave locally and pairwisely. We often char- acterize traffic pattern, or traffic behavior, using the following parameters: locality, correlation, and bursti- ness, Locality deals with the geographical distribution of traffic sources. High locality (i.e. most of the traffic is contributed by a small fraction of communicating node pairs) results in performance degradation if resources are allocated uniformly across node pairs. Correlation and burstiness are more directly related to the packet arrival process which is the main focus of our study.

A correlated packet stream means that packet arrival instances are not independent from each other, while a bursty packet stream means that there is a high variabil- ityy in the packet interarrival times. The general observa- tion is that higher correlation leads to higher burstiness and thus longer delay.

As we take a close look at the packet stream corre- lation, we realize that the long – term correlation de- pends on the user and application behavior, while the short — term correlation is regulated by the interac- tion of protocol and communication device parameters.

In fact, there are many processes modulating a single packet arrival stream. Users arrive at and leave from a computer. Users may invoke applications while stay- ing in the system. Applications can generate traffic of various types: interactive, file transfer, virtual memory paging, process swapping, image transfer, and real-time applications like voice, video, and multi-media. Each traffic source type uses a specific protocol suite to trans- mit its packet stream. For example, interactive traffic usually goes through the character stream protocol like TCP, while file transfer traffic uses a block operation on a datagram protocol like RPC-on-UDP. Finally, the capacity of the host machines and the network deter- mine how fast the packet streams can bt? injected into the network.

Motivated by the above observations, a new computer

network packet arrival process, HAP (Hierarchical Ar- rival Process), capturing both long-term and short-term correlations is proposed in this paper. The objective of this HAP model is to replace Poisson and general MMPP models for more accurate performance analysis and resource allocation. A HAP has three levels – user, application, and message. A set of parameters describe the arrival and departure processes at each level. The model captures the fact that a packet arrival process is modulated by its upper-level arrival processes. HAP is a formal generalization of ON-OFF type traffic mod- els [10, 11, 12] where a burst can arrive only when the call it belongs to is active. In fact, the ON-OFF model is a 2-level HAP with only one message type. We can model acomputer packet stream as a 3-level HAP while modeling packet streams from some other different en- vironments as 2-level HAPs.

The paper is organized as follows, Section 2 formally presents the HAP model and its parameters. In sec- tion 3, we first show that HA Ps are multi-dimension, infinite-state MMPPs. Three solutions are used to an- alyze HAP’s queueing performance. Section 4 presents the numerical results regarding the accuracy of the ap- proximate solutions and the queueing performance of HAP/M/l. Both long-term and short-term behaviors are studied. HAP parameters are adjusted in section 5 to study some topics. In section 6, we give implica- tions for broadband network control. In-progress work on HAP is briefed in section 7

still active. This may happen, in a computer, when the user issues an application as a background process and leaves.

To formally model a HAP, we use Figure 1 as a concise representation for the HAP model. The HAP model parameters are defined below: (Suppose that the recip- rocal of each parameter is the mean of its distribution.)

~ : user interarrival time distribution p : user service time distribution

Ai : interarrival time distribution for application type i (In Fig 1, application arrivals are enabled only

during user service time)

Pi : service time distribution for application type i

~ij : mterarrival time distribution for message type j

of application type i

(again, messages are generated during application

life span)

pij : service time distribution for message type j of application type i

where i = 1 . . . 1 andj = 1 . . . mi. That is, a user can simultaneously invoke up to 1 different types of applica- tions. Each application type i can generate mi types of messages.

A

2 The HAP Model

2.1 HAP with user, application, and

message levels

In this section, we present the HAP model. A HAP is a message arrival process at a network node. At a node, users arrive and depart at a specified arrival rate and departure rate. That is, users arrive according to an interarrival time distribution and stay in the sys- tem for a duration that also has a specified distribu- tion. During his/her presence in the system, the user may invoke several types of applications. Each type of application is invoked at a specified rate, and remains active for an interval which has a specified distribution.

Again, during the active interval, the application gen- erates several types of messages, at different rates and with different message size distributions. Messages may be fragmented into packets or cells in the transmission net work. This depends on the transmission protocols.

There may be many users in the system. And each user is invoking several applications which belong to one application type or several application types. Again, each application has generated none or several messages which belong to one message type or several message types. It is also possible, in this model, that a user has departed but the application this user invoked may be

Figure 1: The HAP model

In the terminology of the object-oriented methodol- ogy, Figure 1 is a containment hierarchy of the object class “user”. A user arrival produces an object inst ante of the object class “user”. Several inst antes of “user’(

can coexist at a network node. Each “user” inst ante, in turn, forks its own child instances which belong to the classes “application i, i = 1 . . 1“. Each “application i,i= l.. l“ instance, belonging to a “user” instance, autonomously forks its own child instances which are of the classes “message ij, i = 1 . . 1 and j = 1 . . mi”.

Figure 2 is an example of two instances of the “user”

class where two nodes overlap if they belong to the same class/type.

If a HAP on a network node dumps its messages into the network, this message stream cent ains complex cor- relations between messages. In fact, we can decompose a message stream into a burst hierarchy aa shown in Figure 3 where message instances of the same color are of the same message type.

J21b

Figure 2: Two user instances of HAP class

Time

Figure 3: Decomposing a message stream into a HAP

2.2 HAP with client-server interaction

In a computer network, traffic occurs due to the inter- actions among traffic sources. These interactions can be studied using the client-server interaction model where requests generated by the clients are sent over the net- work to the servers and responses are sent back to the clients. These responses may, in turn, trigger next re- quests from the clients. That is, a sequence of requests and responses between a client and a server may be gen- erated once the original request is issued by the client.

Let us take “rlogin” aa an example. A user running

‘(rlogin” application on a node issues a command, which is considered as a request, to the remote node. The re- sult, which is considered as a response, from the remote node may trigger the user to issue another command in this “rlogin” application.

A message generated from a HAP process is actually a request from a client on a network node to a server on another network node. To incorporate the client- server interactions into HAP, we modify the original HAP model to the HAP-CS (Client-Server) model in Figure 4 with the additions of the parameters,

Ptj : service time distribution for request message type j of application type i

p;j : service time distribution for response message type j of application type i

p$j : probability that request message type j of application type i will trigger a response

Pjj : probability that response message type j of application type i will trigger next request

where i = 1 . . . 1 and j = 1 . . . mi

A

k al

1

#j%& p

All ~bnlhlm

. ^c

I,PII --- m@lml .;1 --- f

.

“I, PII --- mlPlm* “1A --- .

Figure 4: HAP with client-server interaction

2.3 Example HAPs

Figure 5(a) is an example HAP with 4 application types and 5 message types. Message types A, B, C, D, E represent interactive, file transfer, image transfer, voice call, and compressed video, respectively. They may use different protocols for transmission. For example, in- teractive data usually uses TCP on top of 1P, trans- parent file transfer by NFS/RPC/UDP/IP, image by RPC/UDP/IP, voice and video by some new protocols.

Note that a message is usually fragmented into many packets or cells during transmission.

(b)

Figure 5: Example HAPs

Application type 1 is a common programming envi- ronment where users read or edit files, check directories, etc. Type 2 is possibly a database query environment where only short interactive data is transferred. Type 3 is a graphics-intensive application where fixed size im- ages are transferred. Type 4 is a multi-media applica- tion where all message types are possible. The example assumes that all users are homogeneous, while in real- ity we may have several types of users. In Figure 5(b), we divide the original HAP into four HAPs representing four heterogeneous user types.

3 Queueing Performance Analy- sis

After presenting HAP and HAP-CS models, we are

ready to do some analysis. We first map a HAP to a (1 + I)-dimension, infinite-state MMPP. As there is no closed form solution for queueing performance un- der MMPP traffic, we resort to three algorithmic so- lutions. Solution O is a brute-force iterative approach, while Solution 1 and 2 are approximate solutions. These approximations are shown to be good under three con- straints on parameters. In Solution 2, we obtain a closed-form formula for message interarrival time dis- tribution, which speeds up the computation dramati- cally. To keep the analysis tractable, we assume, unless stated, that all the HAP model parameters are expo- nentially distributed for the rest of this paper. In the analysis part of this paper, we analyze the interarrival and queueing performance at the message level, not at the packet level, because the pat tern of packet streams really depends on the adopted transmission protocols.

3.1 Mapping HAP to MMPP

MMPP is a doubly stochastic Poisson process where the arrival rate is modulated by the state of its embedded cent inuous-t i me Markov chain. Early studies on the queueing behavior with this kind of arrival process with algorithmic solutions can be fcmnd in [14, 15]. Recently, 2-state MMPP haa been used extensively to approxi- mate a superposition of various arrival processes like data, voice, and video traffic [7, 8, 9]. A complicated algorithmic solution is applied to a 2-state-MMPP/G/l queue [8]. However, this 2-state MMPP is only an ap- proximate traffic model for the analysis purpose. Be- sides, a general MMPP is not an appropriate model for computer network traffic.

As we can see, HAP is a class of MMPP whose arrival rate is determined by the state of an (/ + 1)-dimension infinite-state Markov chain where transitions only hap- pen between neighboring states. The state variable of this Markov chain is represented as

(~, Yl, !/2,..., ui)

where x is the number of user instances and yi is the number of instances of application type i, i = 1..1.

The arrival process in this state is Poisson with rate 2:=1 y~ % k “ Figure 6 shows the Markov chain for this MMPP. We have an (1+2)-dimension, infinite-state Markov chain including one dimension for .z where z is the number of message instances in the system when we assume pij = p“ and feed this HAP into an expo- nential service queue. If we i~sume & = A’, Aij = A“,

w = p’, and mi = m, this MhlPP is reduced to a

2-dimension one, as illustrated in Figure 7, with state variable (z, y) where y is the total number of instances

of all application types. The arrival rate in this state is yrd”. If we feed this simplified HAP into an exponen- tial service queue, we get a 3-dimension Markov chain with state variable (z, y, z) where z is the number of message inst antes in the system. However, there is no closed-form solution for this Markov chain. Even if we use Z-transform to solve a 2-level HAP, we still only get a partially differential Z-transform equation, due to the fact that z depends on y (and also y depends on z).

x, yl, .... y,-1, ....yl

H

Xh .... ^)li/L

-&&*-j

XP ^{xai ....}

It

Figure 6: Embedded Markov chain for HAP

Figure 7: Simplified embedded Markov chain for HAP

3.2 Solutions to HAP/M/l

3.2.1 Solution O: brute force

We intend to iteratively compute the steady-state prob- abilities of the (1 + 2)-dimension Markov chain and ob- tain Y, mean number of messages in the system, and ~, mean arrival rate. From 77 and ~, we can compute T, mean message delay, using Little’s result.

From the (1 + 2)-dimension Markov chain, we can write down the state transition equation as

P(x, ul, . . ..yl. z)

= AP(Z– l,yl, . . ..yl. z)

+(Z +

l)

I

+~[zw(z,!h..,

+(Yi + l)piqx, Yl,.., Yi + 1>.., vf)z)l

1 ~t

+~Yi~AijP(x, Yl, . . ..}z}z - 1) i=l jzl

+P’’I’(z,ul,...,y l,z+l). (1)

Although this Markov chain has infinite states, we have to limit the number of states to run the iterative algo- rithm. With several trials, we can set reasonable bounds for z, yi, and z so that boundary states have probabili- ties very close to O. As this is a continuous-time Markov chain, there is no loop transition from a state back to it- self. Thus, we can set the probabilities of out-of-bound adjacent states to O to avoid using a large set of bound- ary equations for all special boundary conditions.

Solving HAP/M/l

The algorithm starts from initializing the state prob- abilities and then many iterations to reach the steady- state probabilities. Initially, we set the state probabili- ties as

where Iz I is the number of Z’S possible values, etc. For each iteration, we recompute probabilities for the states with z + yl + . . . + y~ + z = k, starting from k = O to 1, 2, etc. At the end of each iteration, state proba- bilities are normalized to m~kel~u:; they sum up to 1, The algorithm stops when “+P ~ c for all states, where Pn is the probability in t%e nth iteration and c is a small real number, From the steady-state proba- bilities, z and ~ can be computed. By Little’s result, z = IT, message delay, T, can be obtained. The expe- rience with this brute-force approach is that the bound for z is much larger than the ones for z and yi. That is because we have only one server at the message level while there are, logically, infinite servers at the user and application levels. For large x and yi, the states with even larger ,z have taken over most of the probability. A large number of states makes the convergence to steady- state probabilities difficult.

3.2.2 Solution 1: steady state probability

Given the computational difficulty in Solution O, we now drop the .z dimension of the (i + 2)-dimension Markov chain, which results in the Markov chain in Figure 6.

We u~e the same approach to obtain P(z, yl, . . . . yr) and then ,4. Suppose that the state transition rates are small compared to the message arrival rate, ~~=1 w ~~~1 ~ij, when the system stay in state (c, yl, . . . . yl), the message interarrival time distribution can be approximated as

where P(z, yl, . . . . Y[) is the probability that, given a message, it is generated during the system’s stay in state (x, yl, . . . . y~). It is the probability that the system stays in state (z, yl, . . . . yl) weighted by the message arrival rate of that state. Thus, we can write

1 m,

P(X, yl, . . ..Yr) = p(~, yl, ...,Y~)~Y~~A~j

COceco 1 m,

Note that the denominator is actually ~. As we ex- press, in Solution 1 and also Solution 2, the message interarrival time as a distribution and redraw arrivals from this distribution, correlation between subsequent arrivals is lost. Only Solution O preserves this correla- tion.

Solving HAP/M/l

Being able to compute a(t), the problem now is to

compute mean delay of HAP/M/l. We use the ap-

proach for G/M/ 1 [16]; namely if we can obtain cr in the equation A* (p” – p“c) = u where A*(s) is the Laplace transform of message interarrival time, we can plug it into the equation for delay, T = -, and waiting time distribution2W(y) = 1 — ae-~”tl-”)v. Us- ing Little’s result, ~ = A T, we can also solve ~, the mean queue length, including the one in service, if we know ~. Since A* (s) = ~om a(t)e-gtdt, we can compute A* (p” – p“u) by integration. We resort to the following algorithm to solve a.

u-Algorithm:

Step 1 : Pick any value between O and 1 for u, say 0.5.

Step 2 : Calculate A* (p” – p“a) by integrating

~~ a(t)e-(~’’-o)’dt’dt where a(t) is from Equa- tion 2.

Step 3 : If lA*(p” – p“a) – 01 < e, stop. Otherwise, pick a as ‘*( P’’-’P’’’’)+U and go to Step 2.

Note that as u increases, Jo- a(t)e-(~’’-o)tdttdt also increases. Thus, A* (p” – p“u) has a positive correla- tion with u. This means each time we take the average of A* (p” – #’o) and a as the new a value their differ- ence gets smaller. This shows that the algorithm will converge.

The mean message delay, T, for this G/M/l queueing system is then -J w here a“ is the result of a- algorithm. For the mean queue length, we have

where ~ is the denominator of Equation 3, For G/M/l, once we have solved u*, the waiting time distribution is easily expressed as W(y) = 1 – u“e–~’’(l–””)v.

3.2.3 Solution 2: conditional probability

Solution 2 is the same as Solution 1 except that we can now obtain closed-form formulas for a(t) and ~ by conditional probability.

Mean message arrival rate

Suppose there are x user instances and yi instances of application type i, i = 1 . . . 1, the mean message arrival rate, 1, is

m] ^{ml — 1} m.

If we condition on x and, since there is no rest ric- tion on yi, model application arrivals and departures as M/M/co [16], we can obtain ~ as

m (&’)y’ _q

2X .=oy.=oy’=’-e “’‘2

where P= is the probability that there are x user in- stances. Note that conditioning on x and yi and the ap- proximation as M/M/ccI are g,ood only when arrival and departure rates at user level are much smaller than the ones at application level, which again are much smaller than the ones at message level. Again, since there is no restriction on z, we can model user arrivals and de-

(A)= _~

partures as M/M/co. Thus, ,~r is ~e * . Clearly we have

Thus, we have

1.77A.

(4)

If we assume Ai = A’, Pi = p’, and Aij = A“ V i and ~, we have

. . . 1

(5)

From Equation 5, we observe that merging or splitting the branches in this simplified HAP (i.e. & = ~’, Pi = P’, and Aij = A“) will not change its ~ as long as we keep the same number of leaves in its HAP object class.

Figure 8 shows three HAP’s with the same ~, which is 4A ~A” (from Equation 5). However, their degrees of b&!kiness should be different. Intuitively, one would think that the order of burstiness is (c) > (b) > (a) because the arrival rate is 4Af’ when a single application instance is active in (c) while it is 2A” when a single application instance is active in (a).

Mean numbers of usevs and applications

As pointed out, the arrivids and departures of user and application instances can be modeled as M/M/ou.

(a) w ^(c)

Figure 8: Three HAPs with equivalent mean arrival rate

Thus, the mean number of user instances, Z, is ~ and the mean number of application instances, ~, is

If Ai = A’ and Pi = p’, ~ becomes 1~~.

Message interarrival time distribution

To solve the message interarrival time distribution, a(t), we try to solve A(t) first since it is easier. We first condition on x and then condition on yi, i = 1 . . 1.

When HAP is in state (z, yl, ,.,, yr), the message arrival process is Poisson with rate ~~=1 yi ~~~1 Jij. Using the conditional probability, on x and ~, weighted by the message arrival rates just like Equation 2 and 3, we have

The denominator is ~ and its result turns out to be the same as Equation 4. As we carry out all the summations on 1, which is still 1, and the summation over Y1, we have

@A, -E;;,

We can extract e @1 from the above formula,

Carrying out the summations over the other Yi ‘s, we obtain

co l–~ez~~=l~e

-~;;l ~%,,

0=0

Finally, by carrying out the last summation, we reach the result

(8)

Note that L’(t) = –L(t)iVf(t). We can also check this probability function: A(t) + 1 as t -+ coand A@) = O as t = O. For the density function, a(t), we differentiate Equation 7 to get

x [L(t)N(t)+ L(t)M2(t) +

~L2(t)M2(t)],

N(t) = ~

‘A~_

‘~;’ “’t(~&j)2.

i=lP’ ^j=l

Note that a(t) -+ O as t + coand a(0) =

Solving HAP/M/l

TO solve HAP/M/l, we need to assume ~ij, the mes- sage service time distribution, is equal to p“ for all i and j. If we ‘allow non-identical service time distribu- tions at a queue, we have no product form solution [17].

However, as a(t) in Equation 10 is a complex function, obtaining the A* (s) and solving for u will be intractable.

Thus, we still use our u-algorithm to solve a.

4 Numerical Results

We now present some results on HAP. Assuming that

& = A’, Pi = p’, and Aij = ~“ for all i and ~, we study the accuracy of the solutions under different user, appli- cation, and message parameters. We use the following set of parameters to study message interarrival time dis- tribution and the queueing behavior on an exponential server queue: A = 0.0055, p = 0.001, A’ = 0.01, p’ = 0.01, ~“ = 0.1, p“ = 20, 1 = 5, m = 3. According to

Equation 4, ~ = -x~x O.l X5X3=8.25 whichis

the same as the result from Solution O and simulations.

For this set of parameters, we have a = 0.50 by Solu- tion O, 1, and 2, p = 0.42, mean delay for HAP/M/l = 0.55 by Solution O and simulation, and 0.1 by Solution 1 and 2, mean delay for M/M/l = 0.085 (HAP’s delay is 6.47 times higher by Solution O and simulation, and 17.65% higher by Solution 1 and 2). Solution 1 and 2 are within l% difference between each other. As we can see, the approximation error due to the loss in correla- t ion, when we express the message interarrival time as a distribution, is very significant,

4.1 Accuracy of the solutions

Solution O in section 3 takes about 2 weeks, on a SUN- 4/280 minicomputer without other long running pro- cess, to compute the delay for a given set of parameters because of the large bound required in z dimension. So- lution 1 takes around 7 hours, while Solution 2 only takes 5 to 7 minutes.

From the derivation of Solution 1 and 2, we observe that three constraints on the parameters are required to obtain good results by Solution 1 and 2:

la.

lb.

2.

3.

Message-level arrival and departure rates have to be much larger than the upper-level arrival and de- parture rates.

Lower-level arrival and departure rates have to be much larger than the upper-level arrival and depar- ture rates.

Gap between the rates of neighboring states in the underlying Markov chain can not be too large.

Traffic load is light.

Condition la and lb are for Solution 1 and 2, respec- tively. Condition la are due to the derivation of Equa- tion 2 which is valid only when the message arrival rate,

~~=1 Y~ ,&:l ~~~ ! iS large COmPared to the state transi- tion rate of the Markov chain in Figure 6 and the mes- sage arrival rate does not have a sudden big change when the state transition happens. (The message departure rate, of course, should be larger than the message ar- rival rate. ) Condition lb is a tighter condition than la because, in Solution 2, Equation 7 is obtained by first conditioning on x and then on yi. This conditional

probability is valid only when x is seldom changed com- pared to Vi. Even if x or y is changed, we do not want a big jump in the message arrival rate, which results in condition 2. Condition 3 is d ut to the loss in correla- tion. This loss becomes very serious when the system utilization gets higher.

The above three conditions are just guidelines. In our trials, we observe that if (1) lower-level rates are 5 times larger than the upper-level rates, (2) message arrival rate of one state in the underlying Markov chain is not more than double or less than a half of the rate of its neighboring states (which limits the value of m), and (3) the resulting o for HAP/M/1 is less than 30?70, Solution 1 and 2 have approximation errors less than 5%. When utilization is over 30%, the approximations start to drift far away from the exact results by Solution O and simulations. As we can expect, Solution 1 is a better approximation when condition la is satisfied but condition lb is not. Surprisingly, Solution 1 and 2 are almost the same, with less than lyo difference between them, when the tighter condition, lb, is satisfied.

4.2 Message interarrival time

For the same traffic level, HAP exhibits a higher degree of burstiness than Poisson. In Figure 9, both curves of a(t) have the same ~ (7.5). We plot HAP’s a(t) with Equation 10 and compute the HAP’s ~ using Equation 4 to find the equivalent Ioad-le vel Poisson process. Inte- gration of a(t) is 1 for both curves and integration of t *a(t), which is 7 or ~, have the same value (1/7.5).

HAP haa higher a(0), 9.28, than Poisson’s 7.5. But they intersect at two points: i! = C).077 and 0.53. The inter- section at 0.53 is illustrated in Figure 10.

:-d

., . . . . i“,., ..’ri..l ,1..,.-)

Figure 9: Message interarrival time distribution

The interpretation of these two intersections is that HAP tends to have a higher percentage of messages ar- riving with rather short interarrival times while Pois- son has a higher percentage of messages arriving with medium interarrival times. AS HAP’s a(t) has a longer tail, it also has a slightly higher percentage of messages with relatively large interarrival times. It is important

,.25

0.2 El, with l“w.b., - ,.,,, —

WI.,.” “1,, i“bd. -,.,0, —

~ 0.15 .

0.>

,.05

01 I

0.4, 0.5 0.53 0.6 0.63 0.7

* ,.-..*. i .,.,.,,1 ..1 t 1,. , .s0)

Figure 10: Tail of message interarrival time distribution

to note that these two intersections make both curves have the same ~ and hence ~. If they only intersect at t

= 0.077, this HAP will have smaller? and hence larger

~ because integration of t xa(t) for HAP will be smaller than the one for Poisson. Integration oft x a(t) of HAP’s tail after 0.53 compensates the discrepancy of the front part.

Compared to Poisson, HAP’s arrivals tend to spread out from the mean interarrival time (O. 133). If the dif- ference of message arrival rates of neighboring states in the Markov chain is large, arrivals will spread out from the mean interarrival time even more. The short interarrival times represent the time intervals between messages of the same burst, while the longer interar- rival times are the time intervals between bursts at the application and user levels.

4.3 Long-term queueing behavior

As we feed this multi-level highly correlated message stream into an exponential service queue, we can expect a higher queueing delay compared to Poisson. This is obvious because a message is more likely to enter the queue with a group of messages which maybe correlated by the same user instance, application instance, and even message inst ante.

In Figure 11 and 12, we obtain average delay, proba- bility that an arrival finds the server busy (u), and uti- lization (p) by Solution O and simulations (which have less than 5% difference between each other). Note that our starting set of parameters are A = 0.0055, p = 0.001, A’ = 0.01, p’ = 0.01, A“ = 0.1, p“ = 17, 1 = 5, and m

= 3. In Figure 11, when p“, which is equivalent to the server capacity, is 30 messages per second on the aver- age, HAP’s delay is only 15.22?lo higher than Poisson’s.

But HAP’s delay becomes 200 times higher than Pois- son’s when the utilization is 64Yo! In the meantime, the difference between u and p grows aa we increase the uti- lization. In Figure 12, we adjust the load, by changing J, while keeping the server capacity fixed.

13 . . 41 45.X) I 0.221 Delay performance, ~ = 8.25

Figure 11: Average Delay versus Server Capacity

Delay performance, p(message) =17

Figure 12: Average Delay versus Message Arrival Rate

4.4 Short-term queueing behavior

To explain why HAP’s average delay goes up dramat- ically as we increasing the utilization, we now look at HAP’s short-term queueing behavior in the simulation.

Figure 13 shows that HAP simulation is difficult to converge. It is not easy to determine the criteria to stop the simulation due to its fluctuation which is far more serious than Poisson. There are two reasons for this.

The first one is that HAP compounds processes at quite different time scales. User arrival and departure have time scales of tens of minutes, while message arrival and departure have time scales of milliseconds.

1.35

“1,. d.,. &

>.,

1 25

,.2

1.1s

,.,

,., s

,

,.95

...^I I

o ,.+,7 ,.,07 3.+07 ,im”fl:ya” 5.5.0 ;,.=.+,7 7.+07 8.+07 9*O7

Figure 13: Fluctuation of HAP Simulation

The second reason is that, from time to time, serious

congestions happen in the HAP simulation. These con- gestions are due to the long bursts which are illustrated as the big mountains in Figure 14 (in a one-hour period) where the number of messages in the queue is traced.

In the extreme case as shown in Figure 15, we have a mountain which has the peak number of messages over

17,000 and lasts about 80 minutes. (In our simulations, Poisson’s peak number of messages only reaches 29!) These mountains cause the fluctuation in simulations and make the average delay go up significantly. For this extreme mount ain, we trace the numbers of users and applications in Figure 16 and 17, respectively. At the beginning of this long burst, there are 13 users and 49 applications while the averages are 5.5 and 27.5, respec- tively. Under a large number of users or applications, the chance to have an upcoming long burst is high.

so

*, 0.0005 O.*,, 0.001, 0.002 ,.002s 0.003

.i..,.tie. .J.. ,.11,1- . . . . 1E6 ..0)

Figure 14: Arrivals and Departures in a One-hour In- terval

,8090

.h_..’L3 .*. .— ,6,00

14000

12000

,0000

*.*.

6000

‘a,,

2900

0

0 ,00 iow 1500 2000 2500 3,,0 35,0 ,000 4500 5000

.,..,.*,.. cl.. ,.- .,. b.,,”.,.. or . . . . . . (...)

Figure 15: The Peak Busy Period

Figure 18 lists the statistics of busy/idle period and height of the mountains (maximum number of messages in a busy period) for HAP and Poisson. Both HAP and Poisson have mean busy period/(mean busy period + mean idle period) around 55Y0, Mean busy/idle period and height of HAP are only slightly higher than Pois- son’s, while the variances of HAP are much higher (618, 15, and 66 times higher than Poisson’s for busy period,

idle period, and height, respectively). Besides, we ob- serve that, for the same simulation length, the number of mountains of HAP is 19y0 smaller than Poisson’s.

,0

. . . ...3.*.” — 16-

14

,,

10-

a

6

:L-2!IzEJ

.Im. fr- th. ,bwin”i”s d . b.,.. (sod

Figure 16: User Arrivals and Departures in the Peak Busy Period

Figure 17: Application Arrivals and Departures in the Peak Busy Period

Heights of the mountains affect the waiting times of new arrivals, while lengths of busy periods determine the numbers of arrivals that will have waiting times of these orders. A high mountain with a short width means only a small number of arrivals suffer congestion.

Having larger mean busy period and height, and even much higher variances, HAP has a much larger number of arrivals suffering serious congestion. For the studied case, comparing with Poisson’~~, HAP’s variance for busy period is extremely high, while its variance for height is medium high. This implies that this HAP have a very larger number of arrivals suffering medium waiting times (many medium high nmountains with very long widths).

The average delay increases dramatically due to the occasional long bursts. But why does HAP tend to gen- erate mch long bursts? The explanation is that HAP compounds correlated processes into one process to gen- erate arrivals, which increases burst iness. As these pro-

cesses are correlated, to the same parent process for ex- ample, the chance that they are active simultaneously is much higher. This is totally different from multiplexing independent arrival processes, which reduces burst iness.

~= 8.25, K (message)= 15

Figure 18: Busy and Idle Periods: HAP versus Poisson

5 Adjusting HAP Parameters

We now use Solution 2 to adjust HAP parameters to study several topics: levels of modulating processes, ar- rival versus departure processes, and bounding the num- bers of users and applications. Since Solution 1 and 2 are not good approximations when the utilization is over 30%, we are interested in observing the trend of the re- sults by adjusting HAP parameters, not the quantitative differences. We use the set of parameters described at the beginning of Section 4 as a starting point to adjust different parameters.

Levels of modulating processes

Starting from the original set of parameters, we keep increasing and decreasing, one at a time, arrival and de- parture rates, by 5~0, of processes at user, application, and message levels. In Figure 19, we find that adjusting J’ and A“ has larger impact on burstiness than adjust- ing A. Note that the X axis is ~ in order to compare their behaviors under the same ~. It is interesting that A’ and A“ have the same effect on burstiness, On the other hand, adjusting ~ has a larger impact on ~ than adjusting J’ which has also a larger impact than adjust- ing ~“. The results show that upper-level arrival pro- cesses haa more impact on ~ while lower-level arrival processes has more impact on burstiness. The expla- nation is that adjusting A“ directly affects the message arrival process. The same observation also applies to the departure processes.

For arrival and departure processes at the same level, adjusting any one haa the same effect on burstiness.

Two curves for delay versus ~ simply coincide. One interesting quest ion is: what if we adjust arrival and departure processes at the same levq simultaneously by the same factor? From Equation 4, A remains the same.

However, the burstiness differs. The result shows that increasing both by the same factor of 10VO decreases the delay by about 1% and vice versa. The interpretation is simple. The arrivals, users or applications, that come frequently but go quickly generate shorter bursts than the arrivals, with equivalent ~, that come infrequently but stay longer.

Effect of admission control

0.3

0.25

.,.

0.,5

0.1

0.,s I

z * ,

Wa.h: ,.s$,..0, ‘0 “ 1’

Figure 19: Levels of arrival processes

One simple flow control scheme on HAP is to limit the numbers of current users and applications. We know that this scheme for sure will reduce ~. But will it reduce the burstiness? Figure 20 says it will and it reduces more as ~ increases. The bounds we put for the numbers of users and applications are 12 and 60, respectively, while originally they are set to 60 and 300 that are large enough for computing the unbound cases.

This result suggests that a simple admission control is effective in reducing delay and provides a chance to support a higher ~ for a given delay criteria. The in- terpretation of this result is that bounding the numbers of users and applications also bounds the burst length.

However, this simple admission control can not bound the number of messages. That is, we still have no con- trol at the message level.

,.*7

0.,6

0,1s

0.14

,.t>

0.,2

0.11

0.,

0.09

0.0, I I

6 6.5 7 7.5 9 9.5 10 10.5

LWd.:wz (:;5/.-,

Figure 20: Effect of bounding users and applications

6

Implications for Broadband Network Control

We now summarize the results and discuss their impli- cations for broadband network control. HAP traffic is very burst y. Congestion may persist for minutes. It is

the only formal model, so far, that exhibits the same congestion phenomena in the real network. HAP can serve as the computational base to estimate the admis- sible workload for a given bandwidth (admission con- trol), or the required bandwidth for a given workload (bandwidth allocation).

The delay gap between HAP and Poisson increases significant 1y as the server ut ilizat ion increases, which means HAP is very sensitive to the allocated band- width. Misengineering with underestimated bandwidth requirement results in a serious performance degrada- tion which is much worse than what we can predict by the Poisson model. In high-speed networks, allocating appropriate bandwidth is much more effective than al- locating more buffer space to reduce delay and loss [6].

For the studied HAPs, HAP’s average delay is only tens of percentage higher than Poisson’s if the utilization is under 3070. For this level of utilizations, fast computa- tions are feasible by our Solution 2.

Burstiness increases aa the gap between the arrival rates of neighboring states in the underlying Markov chain increases. That is, there is a change in message arrival rate when a state transition happens. Since state transitions in HAP only happen between neighboring states, HAP’s burstiness is limited. However, as the number of states is infinite, the message arrival rate can change significantly as the process navigate this huge Markov chain. Reducing the number of states reduces the burstiness. One simple way is to limit the number of users and applications. To reduce burstiness at the message level, we can design the end-to-end protocol, window flow control for example, to reduce the message arrival rate, which reduces the burst length at message level, and block operations, by fragmenting messages into blocks along with window flow control, to reduce the burst length.

If a HAP contains very heterogeneous applications, which results in big gaps between neighboring states, burstiness is increased. The implication is not to mul- tiplex heterogeneous applications on the same channel.

The less bursty applications will suffer a lot. By the same argument, due to HAP’s extreme burstiness, mul- tiplexing HAP traffic with non-HAP traffic should be avoided, especially when the non-HAP traffic is some real-time application. More numerical results are re- quired to justify this implication.

7 Conclusion and Future Work

In this paper, we introduce and formalize a new class of traffic model – HAP. HAPs have both short-term and long-term burstiness and correlation. We analyze its queueing delay with three solutions and simulations.

Basic numerical results on message interarrival time and queueing behavior are reported. HAP’s behavior matches the real network performance. With th results on delay patterns, we give implications on broadband

network control.

There are several promising directions for future re- search. We are currently studying the effects of ad- justing HAP parameters. This includes the effects by dimensioning HAP (changing its structure) and by mu- ltiplexing HAPs with non-HAP traffic. As the analysis part does not cover the protocol behavior, simulation is the resort to study the the feasibility of the protocols designed for specific applications.

Finally, we discuss HAP’s role in admission control of connection-oriented (CO) services and design prob- lem of connectionless (CL) overlay network in ATM net- works. In a HAP, interactive, file transfer, and image transfer will use CL services for transmission through an ATM network, while real-time applications like voice and video will use CO services. Suppose that we use the HAP model to compute the admissible number of CO connections for each application type from the given HAP parameters and the performance requirement. A linear approximation technique [10] can be used to com- pute the admissible call regicm. If we store this ad- missible call region in an admission decision table of each ATM network interface, the admission decision for an incoming VC (Virtual (hlnection) or Vp (VirtUal Path) request can be made b,y a table lookup. Inter- connection of LANs/MANs to ATM networks is one of the services to be offered in 13-ISDN. CCITT Recom- mendations [18, 19] describe the concept and the di- rect provision of CL capabilities within B-ISDN. Given the physical ATM network and the HAP parameters for both CL and CO applications, we can design the CL overlay network for CL services subject to a perfor- mance requirement. This problem is fairly complicated as it involves the dynamic interaction between CO and CL traffic. HAP can serve as a good model for either CL or CO traffic. Further study is on-going.

References

[1]

[2]

[3]

[4]

[5]

Kleinrock, L., Queueing Systems, Vol. II: Com- puter Applications, pp.320-322, pp.422-484, John Wiley & Sons, New York, 1976.

Pawlita, P. F., Two Decades of Data Traf)ic Measurements: A Survey of Published Results, Experience and Applicability, Proceedings of the 12th International Telecommunication Conference, Torino, June 1988.

Heimlich, S. A., Tra&c Characterization of the NSFNET National Backbone, Proceedings of the 1990 Usenix Conference, January 1990.

Shoch, J. F. and J. F. Hupp, Measured Perfor- mance of an Ethernet Local Network, Communi- cations of the ACM 23, 1.2, pp.71 1-721, December 1980.

Gusella, R., A Measurement Study of Diskless Workstation Tra&c on an Ethernet, IEEE Trans-

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

actions on Communications, VO1. 38, No. 9,

pp.1557-1568, September 1990.

Fowler, H. J. and W. E. Leland, Local Area Network Trafjic Characteristics, with Implications for Broadband Network Congestion Management, IEEE Journal on Selected Areas in Communica- tions, vol. 9, No. 7, 1139-1149, September 1991.

Heffes, H., A Class of Data Trafic Processes - Covariance Function Characterization and Related Queueing Results, vol. 59, No. 6, The Bell System Technical Journal, 1980.

Heffes, H. and D. M. Lucantoni, A Markov Mod- ulated Characterization of Packetized Voice and Data Traflc and Related Statistical Multiplexer Performance, IEEE Journal on Selected Areas in Communications, vol. SAC-4, No. 6, PP.856-868, September 1986.

Sriram, K. and W. Whitt, Characterizing Superpo- sition Arrival Processes in Packet Multiplexer for

Voice and Data, IEEE Journal on Selected Areas in Communications, vol. SAC-4, No. 6, PP.833-846, September 1986.

Hui, J. Y., Resource Allocation for Broadband Net- works, IEEE Journal on Selected Aress in Commu- nications, vol. 6, no. 9, pp. 1598-1608, December 1988.

Schoute, F. C., Simple Decision Rules for Accep- tance of Mixed Trafic Streams, Processdings of the 12th International Teletraffic Congress, Torino, 1988.

Kuehn, P. J., From ISDN to IBCN (Integrated Broadband Communication Network), Proceedings of the World Computer Congress IFIP ’89, pp. 479- 486, San Francisco, 1989.

Jain, R. and S. A. Routhier, Packet Trains - Mea- surements and a New Model for Computer Net- work Traf7ic, IEEE Journal on Selected Areas in Communications, vol. SAC-4, No. 6, pp.986-995 September 1986.

Neuts, M. F., The M/M/l Queue with Randomly Varying Arrival and Service Rates, Opsearch, 15, No. 4, pp.139-157, 1978.

Neuts, M. F., Matrix- Geometric Solutions in Stochastic Models, An Algorithmic Approach, John Hopkins University Press, Baltimore and London, 1981.

Kleinrock, L., Queueing Systems, Vol. I: The- ory, PP.101-102, PP.176, pp.251-252, John Wiley

& Sons, New York, 1975.

Baskett, F., K. M. Chandy, R. R. Muntz, and F.

G. Palacios, Open, Closed, and Mixed Networks of Queues with Di#erent Classes of Customers, Jour- nal of the ACM, 22(2), 248-260, 1975.

CCITT, B-ISDN Service Aspects, Recommenda- tion 1.211, Geneva, 1991.

CCITT, B-LS’DN Functional Architecture, Recom- mendation 1.327, Geneva, 1991.