On-Line Traffic Contract Renegotiation for Aggregated Traffic

Post on 01-Dec-2023

0 views 0 download

transcript

On-line Tra�c Contract Renegotiation for Aggregated Tra�c

R. Andreassen and M. Stoera�

aTelenor AS, P.O.Box 83, 2007 Kjeller, Norway.Email: fragnar.andreassen, mechthild.stoerg@fou.telenor.no

Consider an ATM service, which is charged by the contracted peak rate, but where itis possible to renegotiate the peak rate against paying a small renegotation charge. Sucha service represents a more exible economic resource sharing than the current practiceof �xed capacities. We present an on-line algorithm for renegotiating the peak rate thattrades o� peak rate charges, renegotiation charges and long-term delay. We compare theperformance of the algorithm in terms of charge and delay with the optimal strategyemploying full knowledge of the future tra�c, and with the constant bit rate strategy.Experiments in a simulation and in an experimental environment with aggregated TCP/IPtra�c over an ATM link show that the on-line algorithm considerably reduces the gapbetween the optimal and the constant bit rate strategy.

1. Introduction

A renegotiated guaranteed service with the possibility of dynamic peak rate changescould in the future be o�ered in order to e.g., make leased line services more attractiveto customers with long-term tra�c uctuations, such as managers of corporate and uni-versity networks. Compared to �xed capacity leased lines, the service has a potentialfor improved total utility of the link resource, while still giving customers possibilitiesfor cost/quality tradeo�s through choice of service renegotiation strategy. The task ofmaking these cost/quality tradeo�s by dynamically balancing communication charges,renegotiation charges and delay costs is however non-trivial, and would be more or lessimpossible to perform by a human operator. Instead, this functionality may be builtinto an intelligent software agent, acting on behalf of the ATM-link operator or corpo-rate network manager. The aim of this paper is to investigate and evaluate an algorithmfor renegotiated service deployment that may be built into such agents. Andreassen etal. [1] study a related problem, arising when the peak rate is �xed but the customer can(re-)negotiate a tari� depending on the mean rate.Literature on renegotiation has up to now mainly been concerned with video applica-

tions. Zegura et al. [2] survey optimal and approximative algorithms for �nding renego-tiation schedules for video tra�c traces. Almesberger et al. [3] demonstrate that videoconferencing employing renegotiated constant bit rate service (RCBR) over ATM can haveacceptable quality. The peak rates were renegotiated manually as picture content shifted

�This work was supported in part by the European Union under ACTS Project CA$hMAN (AC-039)

between \moving" and \slide show". Grossglauser et al. [4] argue that RCBR leads tobetter shared network resources between connections with variations in slow time-scales.Renegotiation for playback-video and for a link with (aggregated) TCP/IP applications

di�ers in one important aspect: future demand is not known. This necessitates the searchfor and analysis of e�ective on-line algorithms for taking renegotiation decisions. We makethe following assumptions in uencing the design and analysis of the on-line algorithm.

� There is no knowledge about tra�c characteristics and throughput preferences ofthe single connections carried through the link. There is no knowledge of o�eredtra�c, delays and bu�er backlogs, because tra�c is aggregated, and adaptive tra�cbacks o� when encountering a bottleneck. Future capacity requirements are notknown. Past sent tra�c, aggregated over certain intervals, is assumed to be known.

� Short-term delays are unimportant. The customer (leasing a line, e.g.) is mainlyinterested in the reduction of long-term delay, experienced by connections throughthe link, when link capacity is restricted.

� The probability for refusal of a tra�c contract renegotiation is negligible. In practi-cal applications, a request for higher peak rate may be refused, but one may assumethe network to be dimensioned such that refusals happen rarely. We did not inves-tigate the role of refusal probability on the design of renegotiation schedules.

� The charge for renegotiating the capacity is non-negligible, and the charges forcommunication are proportional to the capacity (peak rate).

This paper proceeds by presenting the exact meaning of delay that will be used inthe analysis, and establishing the related optimisation problem. We then propose anon-line algorithm. The results from the on-line algorithm are compared with the resultsfrom the optimal algorithm and with results from the \simple strategy" of keeping thepeak rate �xed. The algorithms are evaluated in two scenarios: �rst, where delay valuesare computed by simulation, and second, where delays are measured from reproducibleexperiment tra�c.

2. Delay and cost

For a given communication over a given type of service one may formulate the economicobjective of obtaining the combined minimum of communication cost and delay cost.Delay is modelled by the uid ow concept: o�ered tra�c is seen as a constant ow insidethe polling intervals (since nothing is known about the individual tra�c sources). Thebacklog bu�er is virtual, but has a piecewise constant service rate, namely the contractedcapacity. An example delay workload diagram may look like in Figure 1. The delayvolume is the area between the service rate (dotted line) and the o�ered tra�c volume(solid line) whenever the service rate is lower than the o�ered tra�c. The service rate inthe �gure is constant inside [t0, t1] and is renegotiated to a lower value at t1.For each interval of constant service rate, there will be associated a charge related

to the capacity, a charge related to the capacity renegotiation, and a cost (or rather apenalty) related to the accumulated delay volume in the period. We chose to penalise the

time

volumeV0

V1

t1t0

Figure 1. Volume/delay diagram for link delay model

delay volume instead of the maximum delay, because this is a better measure for what anumber of adaptive tra�c sources through a congested ATM-link experience over time.For a connection lasting a number of n intervals partitioned at the instants t0, t1, . . . ,tn�1, the complete cost is expressed as

C =n�1X

i=0

hl(tl+1 � tl) + nwr + wd

n�1X

i=0

Vi: (1)

The constant wr denotes the network's charge for renegotiations, and the constant wd

expresses the user's preference for small delays. The degrees of freedom in optimising theabove objective function lie in the choice of renegotiation instants and peak rates.

3. Optimal renegotiation strategy

In order to evaluate how well an on-line algorithm minimises the cost, an algorithmfor computing optimal renegotiation schedules was implemented. The optimal algorithmassumes complete knowledge of future tra�c o�ered to the link. The algorithm is basedon the same idea as a dynamic programming algorithm developed by Grossglauser etal. [4] for renegotiated CBR service. In their setting the cost function

C =n�1X

i=0

hl(tl+1 � tl) + nwr

is to be minimised under the condition that bu�er occupancy never exceeds a givenbound. In our setting, the cost function (1) is to be minimised without conditions onbu�er occupancies. The algorithm of [4] is easily adapted to the above minimisationproblem. It operates with the assumptions that renegotiation decisions can be made onlyat equidistant time slots, that peak rates can only be chosen from the discretised valuesf0; �; 2�; : : : ; K�g for some bitrate �, and that o�ered tra�c rates take the same discretisedvalues f0; �; 2�; : : :g without upper bound.

4. Heuristic algorithm for capacity renegotiations

An on-line algorithm for capacity renegotiations has to deal with two uncertainties,�rst uncertainty about the future tra�c volumes, and second uncertainty about presentlyo�ered tra�c and delays. The only information the algorithm can use are tra�c obser-vations from the past gathered at �xed polling intervals. Note that o�ered tra�c is notequal to observed tra�c, especially when o�ered tra�c exceeds the present link peak rate.In order to deal with the unknown future, the on-line algorithm observes the past. If

the \cost savings" by a would-be renegotiation to some other peak rate than the presentexceeds a certain bound, a renegotiation to this peak rate is proposed. In order to dealwith the unknown delay, the on-line algorithm makes a guess about o�ered tra�c. Morespeci�cally, if the observed tra�c rate in the last interval is \well below" the present peakrate (i.e. � peak-rate � �), then o�ered tra�c is assumed to be equal to observed tra�c.If the observed tra�c is \near" the present peak rate (i.e. > peak rate � �), o�ered tra�cis assumed to be (peak rate + �).The so-called critical region heuristic depends on a parameter cr (renegotiation charge),

a parameter cd (unit delay cost), and a discretisation of peak rates �. At each pollinginterval the platform calls the critical region heuristic and passes it the tra�c rate observedin the last interval. The heuristic will either propose to stay with the present peak rateor propose renegotiation to a peak rate in the set f�; 2�; : : : ; K�g. The parameters cr andcd should not be confused with wr and wd of the objective function. In the performanceanalysis, cr and cd are varied to study the behaviour of the heuristic, whereas wr and wd

stay �xed. We describe one step of the so-called critical region heuristic.The internal data structure consists of an array of critical regions indexed by the possible

peak rates. A critical region for a peak rate consists of a �eld started and a �eld target

time. Starting a critical region means to set started to true and set the target time toa certain time past the present time. Stopping a critical region means setting started tofalse. As soon as the present time exceeds the target time for a started critical region, arenegotiation to the peak rate associated to the critical region is proposed.

One step of the critical region heuristic:� If the observed tra�c rate is > (present peak rate� �), and the critical regionbelonging to (present peak rate+ 2�) is not yet started, start it now and set itstarget time to: present time plus the square root of 2cr=(cd � �). The reason behindthis setting is that we assume o�ered tra�c to be (present peak rate+ �) from thestart of the critical region and for some time in the future. Under this assumptionthe delay cost (cd� assumed delay) incurred between start time and target time willexceed the cost for one renegotiation.

� If the observed tra�c rate is > (present peak rate� �), and the present time exceedsthe target time of the critical region belonging to (present peak rate+ 2�), proposea renegotiation to (present peak rate+ 2�), stop all critical regions, and exit.

� If the observed tra�c rate is � (present peak rate� �), stop the critical regionbelonging to (present peak rate+ 2�).

� For all critical regions belonging to peak rates k� with k� < present peak rate and

k� � (observed tra�c rate+ �) do the following.

{ If the critical region is not started, start it now and set its target time topresent time plus 2cr = (present peak rate� k�). The reason for this setting isthat the schedule renegotiating to k� at start time of the critical region andthen renegotiating back again will become cheaper than the schedule waitinguntil target time, when o�ered tra�c rates stay below k� between start andtarget time.

{ If the present time exceeds the target time of the critical region, propose arenegotiation to k�, stop all critical regions, and exit.

� Stop all critical regions belonging to peak rates k� with k� < (observed tra�crate+ �).

The workings of the algorithm are illustrated in Figures 2 and 3. The \waiting time"until a renegotiation decision is made, depends on the size of cr and cd. For small cr orlarge cd values, the algorithm will wait a shorter time. The in uence of smaller or largercr and cd values on charges and delay is investigated in the next section.

time

rate

δ

Renegotiate?Contracted rate

Observed rate

Figure 2. Increasing load

time

rate

δ

Renegotiate?

Contracted rate

Observed rate

Figure 3. Decreasing load

5. Environments for renegotiation strategy evaluation

The approach taken for evaluation of the algorithms is to let them work on reproducibletra�c trace samples. The samples were obtained by making measurements with theCA$hMAN charging management platform on the tra�c on the ATM link connectingTelenor R&D to its internet service provider. The link speed during measurements was setto an ATM payload rate of 10 Mbit/s. The tra�c was well below this limit. It is assumedthat tra�c is adaptive, translating communication restraints into communication delays.The algorithms were analysed in two environments, by simulation and by experiments.

5.1. Simulation environmentIn the simulation environment, the backlog delay bu�er can be modelled by a leaky

bucket, and o�ered tra�c can be read directly from original statistics. The simulation

environment thus provides for speedy evaluations compared to experiments performedin real time. The optimal renegotiation strategy can only be worked out in a simulationenvironment, and most comparative investigations are therefore performed by simulations.

5.2. Experimental environmentAs a validation of operational properties, the on-line algorithm is in addition run in real

time in an ATM network fed by computers recreating the original tra�c trace by TCP/IPtra�c over ATM. The use of given tra�c samples allows the computation of backlog delayvolumes aggregated during experiments with the algorithm. The two environments serveto investigate how theoretical results relate to an environment where rate adaptations arenot perfect, and where other random e�ects, such as scheduling delays, can be observed.The experiment system consists of a non-adaptive source generating tra�c as observed

from the original unconstrained data transfer, a backlog bu�er storing information thatcannot be immediately sent, and an adaptive source that uses a TCP connection in orderto get realistic rate adaptation. Generated tra�c goes through an ATM network consistingof one link, where actual transmitted data at the ATM level is measured in a chargingplatform. This platform also controls link rates of the connection to be charged, wherelevel and duration of link rates are governed by the renegotiation agent.Time granularity of the agent is approximately �ve seconds, i.e., decisions on renego-

tiations are made with this period. The data source is piecewise constant with the sameperiod as the agent.One important di�erence between the experimental environment and the simulations

is the nature of rate adaptations. In TCP this adaptation is normally made by probinglyincreasing the send rate until packet losses occur, whereafter the send rate is reducedbefore a new increase. By testing the link utilisation using a greedy TCP source, it wasexperienced that in the range of bitrates used in the experiments, 20% of the capacityconsistently remained unavailable for transmission of user data, presumably due to theabove rate adaptation mechanism. To obtain correct algorithm performance in the ex-periments, the observed rates passed to the on-line algorithm were thus increased by afactor 1.25 from the measured value.In the simulation and experiment platforms delays were computed di�erently. The

simulation computes delay volumes from the statistical trace directly, whereas the experi-ment platform sums up (delay � volume) for each packet received. Delay is here the timespent in the software backlog bu�er. Transfer time over the link was virtually zero. Asmall test with constant link rates was performed to compare delay values from the twoenvironments. The test showed that experimentally measured delays vary little (whenusing the same link rate) and that experimental and simulated delay values conform inthe range of non-negligible delay values.

6. Observations/results

Experiments were conducted on several di�erent tra�c trace samples, with di�erent cr,cd parameters (controlling step sizes in the critical region heuristic). The largest observedrate in any of the used samples was 5 Mbit/s. The length t of the polling interval was 5.2seconds with little variation. It was experimented with a peak rate discretisation of � =0.5 Mbit/s. The tra�c trace samples had been collected during busy hours and morning

hours with less tra�c. Table 1 describes the traces used in the analysis.

Table 1Traces used in the analysis

Trace Length (hours) Remark1 24 working day2 24 working day3 1:35 busy hours4 1 morning hours, little activity

We compared the performance of the critical region heuristic with the optimal algorithmand with the strategy of not renegotiating at all.The outputs of the di�erent algorithms can be evaluated by two numbers, the charge,

which is de�ned as the communication charge of the schedule plus wr times the numberof renegotiations, and the delay, which is de�ned as the sum of the Vi in Figure 1. Thetime units are seconds, and the volume units are cells. Throughout the analysis, wr has avalue of 80963.4 (cells), corresponding to the communication charge of a 1Mbit/s link forthe length of about 6 polling intervals. With this charge it does not pay o� to renegotiateafter each polling interval.Figures 4 and 5 show the simulation results for Trace 1 and Trace 2. Shown are charge

and delay (as de�ned above) for di�erent parametrisations of the on-line heuristic. Theline \cr 6746.95" connects the (charge/delay) points produced by the critical region heuris-tic with cr = 6746:95 and cd varying inside [0.0003, 0.3861]. The line \cr 80963.4" connectsthe (charge/delay) points produced by the critical region heuristic with cr = 80963:4 andcd varying inside [0.004, 4.63]. The line \no reneg" connects the (charge/delay) pointsproduced by the constant bit rate schedule for bit rates in f1, 1.5, 2, 2.5g Mbit/s. Alsoshown are the results from optimisation, when wr was set to 80963.4 and wd varies inside[0.013, 4.63]. The reason that the optimal algorithm is not able to achieve zero delay, isthat its input was not the original input trace, but the trace whose values were discretisedto multiplies of �. The delay of the output schedule was computed using the originalundiscretised trace.For small cd values, delay produced by the on-line heuristic can vary unpredictably

depending on the location of the peaks in o�ered tra�c But charge in general decreases fordecreasing cd. This behaviour is seen in the fussy line in Figure 5, The simulation resultsfor the heuristics lie approximately half-way in between the constant bit rate schedule andthe optimal schedules, no matter how one weights charges against delay. For instance,with appropriate parameterisation the on-line heuristic is able to produce much lowercharges than the constant bit rate schedule of 2 Mbit/s, but with approximately the samedelay.For Traces 3 and 4 we compared results from tra�c experiments and simulation. The

values of cr and cd used in this analysis are listed in Table 2. Note that cr and cdcontrol the times that the critical region heuristic waits before negotiating upwards ordownwards. More speci�cally, cr, cd, � and the mean length of the polling interval t

1e+08

2e+08

3e+08

4e+08

5e+08

0 4e+07 8e+07 1.2e+08

char

ge

delay

cr 6746.95cr 80963.40

no renegop 80963.40

Figure 4. Simulations with Trace 1

1e+08

2e+08

3e+08

4e+08

5e+08

0 4e+07 8e+07 1.2e+08

char

ge

delay

cr 6746.95cr 80963.40

no renegop 80963.40

Figure 5. Simulations with Trace 2

determine the number j of polling intervals that the heuristic waits before proposing adownward renegotiation by � = 0:5 Mbit/s. They also determine the number k of pollingintervals that the heuristic waits before proposing an upward renegotiation. The valuesof cr, cd and the corresponding numbers j and k used in the experimental platform arelisted in Table 2.

Table 2Parameters used for tra�c experiments

cr cd j k6746.95 0.01207 2 66746.95 0.19305 2 280963.4 0.1488 24 680963.4 2.3166 24 2

Figure 6 shows the results of the tra�c experiment for Trace 3. Each parameter settingin Table 2 was tested four times. The points denoted by \cr 6746.95 exp" belong to theexperiments with cr = 6746:95 and the two di�erent cd-values. It is easy to distinguishthe set of four experiments belonging to cd = 0:01207 from the set of four experiments forcd = 0:19305. In general, the larger cd, the smaller the delay and the larger the charge.Moreover, Figure 6 shows the experimental results for the constant bit rate scheduleswith bit rates in f2; 2:5; 3; 3:5gMbit/s. As one sees, the critical region heuristic with cr =80963:4 and cd = 2:3166 was able to improve both the charge and the delay as comparedto the constant bit rate schedule of 3 Mbit/s. Figure 7 shows the simulated results forthe same parameter setting as used for the tra�c experiments. Comparing Figure 6 andFigure 7, one sees that the points have approximately the same relative position withrespect to each other, and that charge and delay values for the same parameter settinghave about the same order of magnitude.

The same experiments and simulations were done also for Trace 4, a trace with relativelylittle activity. The results for the tra�c experiments are shown in Figure 8 and for thesimulation in Figure 9. Here, the constant bit rates were chosen as f1:5; 2; 2:5g Mbit/s.The on-line heuristic performs comparable to the constant bit rate strategy, especially forcr = wr. In simulation, a renegotiation action is immediate while in the experiments theactual mechanism to perform the renegotiation is to tear down the connection and builda new one. This action will interrupt packet transmission for approximately 0.5 seconds,giving rise to the di�erences observed in delay between experiments and simulations. Thise�ect is most pronounced in Figure 8, where total delay is low.Further experiments (simulations and tra�c experiments) made with other trace sam-

ples con�rm the following.

� For bursty tra�c, the critical region heuristic with cr = wr is able to close part ofthe gap between the constant bit rate schedule and the optimal schedule.

� The heuristic with a peak rate discretisation of 0.5 Mbit/s performs considerablybetter than with a discretisation of 1 Mbit/s.

� For small cd values, delay can vary unpredictably in dependence of cd, but in generalthe sum of communication and renegotiation charges decreases when cd is decreased.

2e+07

3e+07

4e+07

5e+07

0 2e+07 4e+07 6e+07

char

ge

delay

cr 6746.95 expcr 80963.40 exp

no reneg exp

Figure 6. Experiments with Trace 3

2e+07

3e+07

4e+07

5e+07

0 2e+07 4e+07 6e+07

char

ge

delay

cr 6746.95 simcr 80963.40 sim

no reneg sim

Figure 7. Simulations with Trace 3

7. Conclusion

Our goal was to design an algorithm that is able to assist the user in renegotiating thecapacity of an ATM link with exible tra�c (e.g., TCP/IP) by making a tradeo� betweencommunication charges, renegotiation costs and the user's sensitivity to long-term delays.The algorithm operates solely on observed send rates and does not need any informationabout bu�er backlogs. The algorithm was tested by simulation and in an experimental

1.2e+07

1.6e+07

2e+07

2.4e+07

0 2e+06 4e+06 6e+06 8e+06

char

ge

delay

cr 6746.95 expcr 80963.40 exp

no reneg exp

Figure 8. Experiments with Trace 4

1.2e+07

1.6e+07

2e+07

2.4e+07

0 2e+06 4e+06 6e+06 8e+06

char

ge

delay

cr 6746.95 simcr 80963.40 sim

no reneg sim

Figure 9. Simulations with Trace 4

environment. The algorithm's performance in terms of charge and delay was comparedto the performance of an optimal o�-line renegotiator (with knowledge of the completetrace) and of a simple constant bit rate strategy. The heuristic described in this paper isapparently able to make a controlled dynamic trade-o� between communication costs anddelay costs. The considered algorithm retains its properties also when used with realistictra�c. As the algorithm can work with charging management systems, it is of practicalrelevance. The testbed may as well serve to evaluate and compare other on-line heuristics.It may also serve as a model for more complete tests with several TCP/IP sources andmore involved network scenarios.We assume that the on-line algorithm can also be applied to the renegotiation of tra�c

contracts for end-to-end guaranteed services for users that are more delay-sensitive thanthe operator of an ATM link. In this case the agent implementing the algorithm mightadditionally have access to user's preferences for throughput or it can even measure delayon-line. The performance of the on-line algorithm described in this section will have tobe assessed anew in this situation.

REFERENCES

1. R. Andreassen, M. Stoer, and O. �sterb�, Charging ATM Internet Access, an Exper-iment of Usage Based ATM Charging. In Colloquium on Charging for ATM | theReality Arrives. IEE, London (1997).

2. E. W. Zegura and S. McFarland and O. Parekh, A Survey and New Results in Rene-gotiated Service, Journal of High Speed Networks 6 (1997) 197{206.

3. W. Almesberger, L. Chandran-Wadia, S. Giordani, J.-Y. Le Boudec, and R. Schmid,Using Quality of Service Can Be Simple: Arequipa with Renegotiable ATM Connec-tions. Computer Networks and ISDN Systems 30 (1998) 2327{2336.

4. M. Grossglauser, S. Keshav, and D. Tse, RCBR: A Simple and E�cient Service forMultiple Time-Scale Tra�c. IEEE/ACM Transactions on Networking 5 (1997) 741{755.