Revenue-Maximizing Server Selection and Admission ...

Revenue-Maximizing Server Selection and Admission Control for IPTV Content Servers using Available Bandwidth Estimates Brian Meskill, Alan Davy, and Brendan Jennings Telecommunications Software & Systems Group (TSSG), Waterford Institute of Technology, Waterford, Ireland Email: {bmeskill, adavy, bjennings}@tssg.org

Abstract—We present a server selection and admission control algorithm for IPTV networks that uses available bandwidth estimation to assess bandwidth available on the path from an enduser point of attachment to one or more IPTV content servers and that employs a revenue maximising admission decision process that prioritizes requests for high revenue content item types over requests for lower revenue item types. The algorithm operates by estimating expected request arrival rates for different content item types based on past arrival rates and, based on these and available bandwidth estimates decides whether to accept a new request and, when accepting requests, which of the available content servers to use. Results of a simulation study show that the algorithm succeeds in 1) maintaining acceptable packet delays for accepted flows in the presence of fluctuating background traffic on network paths and 2) when available bandwidth is limited prioritizing requests for higher revenue content types. Index Terms—Available Bandwidth, Quality of Service, Admission Control, IPTV.

I. I NTRODUCTION In the case of content distribution networks supporting IPTV, Video on Demand (VoD) or similar applications, there is a necessity to adhere to Quality of Service (QoS) targets. Also, as resources in an IPTV system are a finite commodity, business logic demands that these resources are used in a manner which maximizes the revenue that can be garnered by the service provider. To this end, server selection and admission control are important components to the deployment of a successful IPTV/VoD solutions. This paper addresses the use of end to end Available Bandwidth Estimation Tools (ABETs) in a selection / admission control framework [1] with the concept of revenue optimization [2] to produce a novel approach to admission control and content server selection that operates in an end to end manner without the need to access measurements directly from the network topology connecting end-user points of attachment to those of one or more content servers. It is thus applicable to IPTV service providers deploying services across the public Internet. In the presented framework, revenue is maximized through prioritization of higher revenue requests and Quality of Service is maintained by performing server selection based on the estimated current available bandwidth c 2012 IEEE 978-1-4673-0269-2/12/$31.00

of the network paths. To accept more of these higher value requests when there is limited bandwidth (and still maintain good Quality of Service), there is a deliberate rejection of more of the lower value requests. Thus, in circumstances where a request for a lower revenue content type arrives and there is sufficient bandwidth to service it, the lower revenue content type may be rejected given the expectation that a request for a higher revenue item type will arrive imminently. This supports a business model that is focussed solely on revenue maximization, at the expense of considerations like fairness. The paper is structured as follows. §II outlines some related work in the area. §III presents our approach whilst §IV and §V discuss the simulation model used and an analysis of our results. We then conclude and suggest some future work in §VI. II. R ELATED W ORK Traditionally, admission control approaches fall into two groups: parameter based admission control and measurement based admission control. Parameter based admission control such as [3] is based on the assumption that a priori knowledge exists for the bandwidth requirements of each traffic source. However, often only the peak or mean rate of the traffic is known and sufficient information can not be established. Measurement based admission control such as [4] makes decisions based on measurements taken in real time from the network; it attempts to learn the characteristics and requirements of flows admitted and bases future decisions on this knowledge. Admission Control in a content distribution network context has also been the focus of research recently. In [5], Latr´e et al presented an approach to measurement based Admission Control that utilized PCN[6] to gather measurements. Asghar et al[7] use RSVP[8] as part of an architecture for Admission Control in a CDN network. Both of these approaches require the cooperation of every node along the network path to operate successfully. In recent years, work has been published that has focused on server selection in relation to VoD systems that have examined the costs associated with server selection. Chandra and Sahoo [9] propose an algorithm for selecting the server that would minimize response and completion times based on the current

capabilities of the servers. Carlsson and Eager [10] proposed an approach that looked client start up delay and the total delivery cost. However, their priority was the cost incurred and not the Quality of Service of the content. Available Bandwidth has been defined as “its remaining capacity, that is, the amount of traffic that can be sent along the path without congesting it”[11] and many tools exist for calculating it in an end to end context; that is, without any information from the intermediate topology. Tools such as Pathload[12], Spruce[13],Assolo[14],Yaz[15],Pathrate[16], BART[17] and Forecaster[18] all have varying approachs to estimating Available Bandwidth and as such, they vary in accuracy at this estimation. Research has also been conducted into comparisons and analyses of ABETS[19], [20], [21]. In our experiments we have used the PathChirp [22] ABET which has performed well in such comparisons, has a publicly available implementation and as shown in our previous work [1] is suitable, when appropriately parameterized, for use in IPTV admission control schemes. However, our framework is not limited to using pathChirp and could use any ABET that is capable of operating in an end to end manner. In Davy et al. [2] an empirical estimation of the Effective Bandwidth of a servers egress link is used in conjunction with revenue optimisation to meet QoS targets and maximize revenue. However, this work focused on the egress link from a single server and determined its available bandwidth to be the capacity minus the estimate of Effective Bandwidth. As such, it is limited in its approach as it does not consider either the end to end scenario of IPTV deployment or the potential interference caused by external cross traffic on the network path. By contrast, our approach does not need to know the capacity and does operate in an end to end manner. III. IPTV A DMISSION C ONTROL F RAMEWORK Our IPTV admission control framework is concerned with ensuring the adequate delivery of content from the content servers to the clients over an intermediate topology that is not controlled by the service provider (the Internet being the most likely such topology). Content servers have two purposes: to serve content items and to send ABET packets along the network path of interest. These ABET packets are received by the edge router which uses them to generate an Available Bandwidth estimate. The edge router is also the point of attachment of the clients to the network. One server in the framework, referred to as the selection server, has the sole responsibility for collating the Available Bandwidth estimates for each path and making the decision on whether or not to accept a new request. This server works in conjunction with any number of content servers in the framework. For simplicity we assume that each content server contains a complete library of all the content items, allowing any item to be served from any server. Figure 1 depicts this architecture while Figure 2 shows how the components interact with each other.

Edge Router / ABET Estimator

Unknown Topology

Content Servers / ABET Senders 1..N

Clients

Selection Server

Fig. 1.

AC Framework Framework Components.

In Figure 2, the content server sends an ABET train to the edge router at regularly defined intervals. The edge router uses this packet train to generate an estimate of the available bandwidth, and reports this to the selection server. Independently of this, when a request is generated, it goes from the client to the selection server. The selection server makes a decision to accept or reject the request (based on the algorithms discussed in the following sections). A rejection is reported to the client, whereas an acceptance is delegated to the approriate content server and the content is served. A Video on Demand content library can be expected to contain in the order of hundreds or thousands of different content items. The algorithm presented here places each item into categories and operates by dealing with these categories. This allows the algorithm to remain efficient whilst still dealing with a large scale content library as the amount of categories would be expected to be in the order of tens for even a very large content library. Items can be categorized into groups with similar durations, bandwidth requirements, and revenue potential or a subset of these characteristics. Two content items that have a similar duration and peak throughput might be placed into different categories due to one being a newer release and therefore having a higher earning potential. Similarly, two items might be categorized differently despite have the same revenue potential if the durations are different enough to vary the cost involved in serving each content item. We examine the performance of this framework when the selection server uses each of two decision making algorithms. These algorithms are presented in detail in the following sections. We assume each content server has the resources required to serve any content assigned to it and that all flows assigned to a server run to completion. This allows us to focus on the performance of the admission control framework and not the processing capabilities of the content servers. A. Simple Selection / Admission Control Algorithm The simple selection / admission control algorithm bases its decision to accept or reject a new request for a content item type on whether any of the content servers have the available bandwidth required on their path to the client. Assume there are I individual types of content made available by the service provider. Let i = 1, . . . , I denote an arbitrary type of content item. Let p(i) denote the peak bandwidth per second required

msc Admission Control Message Sequence Client

Content Server Edge RouterSelection Server ABET train repeat

Collect Estimate Report Estimate

Request deny admit Start Flow Video Stream

Fig. 2.

Architecture Component Interaction.

by item type i. Assume that the service provider maintains J content servers, each with a single dedicated egress link to the core network. Let j = 1, . . . , J denote an arbitrary content ˆjd (t) denote the estimate of available bandwidth server. Let B between content server j and edge router d as calculated at time t. As mentioned previously, the selection server maintains an ˆjd (t) for the current estimate of the Available Bandwidth B time t of each path between content server j and edge router d. This estimate is calculated as a moving average of recent reported estimates. If only one server is listed as possessing enough bandwidth to support a request for a particular item type, then the request is accepted and allocated to that content server j ∗ . If there are multiple servers capable of supporting the request, j ∗ is assigned to be the content server with the highest available bandwidth. The final case occurs when none of the network paths have sufficient bandwidth and in this case the request is rejected. This is specified formally in Alg. 1. B. Revenue Maximizing Selection / Admission Control Algorithm This version of the algorithm also uses Available Bandwidth estimates but the decision making is more complex as it takes into consideration the revenue that would be generated and the costs that would be incurred if the flow were to be accepted, as well as the probability of future requests for flows of all priorities. This algorithm is now explained in more detail. The same notation and assumptions that are used in Section III-A are used here and are extended as follows. Let r(i) denote the revenue generated by an accepted request for item type i. Let Ti denote the duration in seconds of flows

associated with the streaming of item type i. Every time a request for item type i∗ arrives, the admission control algorithm estimates, given its knowledge of the duration and time of acceptance of currently accepted flows for the J content servers, the time interval for which the current level of bandwidth will be used by accepted flows, across all content servers (and not including that of the new request) will be maintained; this time interval is denoted (t, t + t0 ). Note that the algorithm assumes that no flows are prematurely terminated for any reason. Every time a request for an item type arrives the algorithm iteratively computes a provisional allocation of the currently unallocated bandwidth to item types for interval (t, t + t0 ) in a manner that seeks to maximize the revenue generated for the service provider. Provisional allocations are based on the revenue values for each item type, the probability of the arrival of requests for those item types in the interval (t, t + t0 ), the peak bandwidth required for each item type, and the most recent estimates of available bandwidth from content servers to the destination. The use of the peak bandwidth is feasible as statistical multiplexing of existing flows is catered for by using current Available Bandwidth estimations. We assume a Poisson process for the arrival of requests for item types, hence the number of arrivals for item type i in the interval (t − t0 , t), denoted qi (t−t0 , t), can be taken as an estimate of the number of arrivals for the interval (t, t+t0 ). This assumption is feasible as for a large population of independent sources (end users), regardless of the individual arrival processes, the composite will tend towards Poission arrivals. As the iterations progress the number of requests for item type i for which bandwidth has been provisionally allocated, denoted ni (t, t+t0 ), is stored. At each iteration the provisional allocation of bandwidth to an item type i is the one that maximizes the marginal utility to marginal cost in comparison to the other possible allocations. The marginal utility, denoted ui (t, t + t0 ), is defined as the revenue associated with accepting a request for that item type, times the probability of an arrival of an additional request for the item type during the interval. If the admission control request is for item type i∗ then the probability of the arrival of at least one request for item type i∗ in the interval is set to 1 (since this request has just arrived). The marginal utility

Algorithm 1: Available bandwidth admission control algorithm ˆjd (t)} Input: i∗ , {B forall the content servers j = 1 . . . J do List all content servers {j 0 } for which ˆjd (t) > p(i∗ ); B if {j 0 } = 6 N U LL then ˆj ∗ d = max{B ˆj 0 d (t)}; Select j ∗ ∈ {j 0 } : B return ACCEPT, j ∗ ; else return REJECT;

TABLE I N OTATION FOR A DMISSION C ONTROL A LGORITHMS Notation I i p(i) r(i) Ti J j (t, t + t0 ) qi (t − t0 , t) ni (t, t + t0 ) ui (t, t + t0 ) i∗ d ˆjd (t) B v(i) δi (t, t + t0 ) πi (t, t + t0 ) Πi (t, t0t )

Description The number of individual types of content item offered by the service provider. A particular content item type. The peak bandwidth per second required by item type i. The amount of revenue generated by accepting item type i. The duration in seconds of flows associated with the streaming of item type i. The number of content servers, each of which hosts all content items. One of the J content servers. The time interval for which all currently accepted flows are expected to remain active The number of requests for item type i during the time period (t − t0 , t). The number of requests for item type i that have been provisionally allocated by the algorithm. The marginal utility of accepting a request for item type i during interval (t, t + t0 ). The item type to which the flow admission request relates. The destination node that is the source of the request for item type i The available bandwidth estimate between content server j and destination d as computed at time t The marginal cost associated with provisional allocation of an item type i. The marginal utility per marginal cost of item type i. Variable used to calculate probability of arrivals of an item type assuming a poisson arrival process, within each iteration of the algorithm. Variable used to calculate probability of arrivals of an item type assuming a poisson arrival process, within each iteration of the algorithm.

Content Server A

70Mb Background Load

Content Server B

65Mb / 80Mb Background Load

Content Server C

Selection Server 60Mb / 90Mb Background Load

Clients

Fig. 3.

Topology Used In Simulation Environment.

At each iteration the algorithm selects a provisional allocation to an item type i0 , decreasing the currently available bandwidth for the interval, denoted B(t, t + t0 ), by p(i0 ). The algorithm terminates when the provisional allocation is for item type i0 = i∗ , in which case the request for item type i∗ is accepted, or when the value of B(t, t+t0 ) is too small to make a given provisional allocation, in which case the request for item type i∗ is rejected. The algorithm is formally specified in Alg. 2. IV. S IMULATION M ODEL

can therefore be expressed as: ui (t, t + t0 )|i6=i∗ = r(i)

∞ X

qi (t − t0 , t)w −qi (t−t0 ,t) e w!

w=ni (t,t+t0 )+1

ui∗ (t, t + t0 )|ni∗ (t,t+t0 )=0 = r(i∗ )

ui∗ (t, t + t0 )|ni∗ (t,t+t0 )6=0 = ∞ X qi∗ (t − t0 , t)w −qi∗ (t−t0 ,t) r(i∗ ) e w! 0 w=ni∗ (t,t+t )+1

We approximate the marginal cost associated with provisional allocation of an item type i, denoted v(i), as maximum bandwidth consumption of item type i over its specified duration: v(i) = p(i)Ti The marginal utility per marginal cost of provisionally allocating bandwidth for a request for item type i during (t, t + t0 ), denoted δi (t, t + t0 ), is then: δi (t, t + t) = ui (t, t + t0 )/v(i)

The simulations were performed using the OPNET ModelerTM [23] simulation environment. The framework is deployed in a scenario where there is three different content servers (A,B,C). We use traffic traces taken from actual videos using various CODECs by [24] and use [25] to inform the distribution of mean durations, enabling us to create realistic traffic flows. For the purposes of control and analysis, we concentrate on requests arriving into the network from a single access point and we specify the intermediate topology between the content servers and the access point to contain Fast Ethernet (100Mb) links. We categorize the content items into three groups and assign them different priorities and characteristics as shown in Table II. Each category of content generates an average of 60 requests per hour as the inter repetition time for requests is exponentially distributed with an average of 60 seconds. The number of links between the content servers and the clients access point was kept equal at 2 hops and background loads were added to the paths by using OPNETs traffic generators. These traffic generators provided a base background traffic of 70Mb, 65Mb, and 60Mb on the paths of the three content servers mentioned, as shown in Figure 3. The packet sizes for the background loads were uniformly distributed with an average of 576 bytes (IPv4 MTU). Three algorithms were examined using the simulated environment of the selection / admission control framework. Two

Algorithm 2: Revenue maximizing selection / admission control algorithm ˆjd (t)} Input: i∗ , {B Step 1: Initialization Calculate t + t0 as the time at which the first termination of the currently accepted flows is expected to occur; forall the item types i = 1 . . . I do Set qi (t − t0 , t) to the number of requests for item type i in the interval (t − t0 , t); Set provisional allocation ni (t, t + t0 ) = 0 ; 0 Set πi (t, t + t0 ) = e−qi (t−t ,t) ; Set Πi (t, t + t0 ) = 1 − πi (t, t + t0 ) ; if i = i∗ then Set marginal utility ui (t, t + t0 ) = r(i); else Set marginal utility ui (t, t + t0 ) = r(i)Πi (t, t + t0 ); Set marginal cost v(i) = p(i)Ti ; Step 2: Identify Optimal Provisional Allocation forall the item types i = 1 . . . I do List all candidates that maximize δi (t, t + t0 ); if list contains item type i0 = i∗ then forall the content servers j = 1 . . . J do List all content servers {j 0 } for which ˆjd (t) > p(i∗ ); B if {j 0 } = 6 N U LL then ˆj ∗ d = max{B ˆj 0 d (t)}; Select j ∗ ∈ {j 0 } : B return ACCEPT, j ∗ ; else return REJECT; else Randomly select item type i00 from list of candidates that maximize δi (t, t + t0 ); forall the content servers j = 1 . . . J do List all content servers {j 0 } for which ˆjd (t) > p(i00 ); B if {j 0 } = 6 N U LL then ˆj ∗ d = max{B ˆj 0 d (t)}; Select j 00 ∈ {j 0 } : B else return REJECT; Step 3: Perform Provisional Allocation Set ni00 (t, t + t0 ) = ni00 (t, t + t0 ) + 1; ˆj 00 d = B ˆj 00 d − p(i00 ); Set B Step 4: Update Internal Variables qi00 (t − t0 , t) Set πi00 (t, t + t0 ) = πi00 (t, t + t0 ) ; ni00 (t, t + t0 ) 0 0 Set Πi00 (t, t + t ) = Πi00 (t, t + t ) − πi00 (t, t + t0 ); Set ui00 (t, t + t0 ) = r(i00 )Πi00 (t, t + t0 ); Step 5: Loop Statement GOTO Step 2;

TABLE II C ONTENT P RIORITIES AND C HARACTERISTICS . Priority High Middle Low

Average Length 20mins 20mins 10mins

Cost $9 $3 $1

of these approaches have already been presented in Alg. 1 and 2 and are referred to as ABAC and REVMAX throughout the rest of this paper. The third approach to be included in the comparison is as follows. Each path is seen to have a static amount of available bandwidth, and this is reduced by the peak rate of each accepted flow that is currently active on that path (referred to as STATIC). V. R ESULTS AND A NALYSIS We compare the algorithms discussed when operating in both a steady state network environment with the background traffic as specified previously and also in the situation where there is a degradation in the condition of the network, such as could be caused by an increase in background traffic for example. To create the increase in background traffic we introduce a step change to two of the traffic generators. The 65Mb background load is increased to 80Mb and the 60Mb background load is increased to 90Mb. This is also shown in Figure 3. Overall, this reduces the available bandwidth from 105Mb down to 60Mb with a significant change in where the majority of that bandwidth is available. Firstly, we examine the end to end delays experienced in the network. It can be seen from Figure 4(a) that the algorithms are all performing to a satisfactory level when the network is in a steady state. STATIC even shows lower delay but this is due to its under utilisation of the available resources, as a result of statistical multiplexing. The benefit of the two algorithms presented in this paper can be seen in Figure 4(b). All 3 of the algorithms experience end to end delays that are less than the 200ms specified as the acceptable limit by [26, p.53-55]. However, both the ABAC and REVMAX are able to adapt to the change in network and the delay is lessened whereas the STATIC approach suffers a higher delay until the increased background traffic is no longer present, as it is obviously unaware of the deteriorated network conditions. An extension of this shortcoming is that if more bandwidth were to become available (due to a decrease in background traffic) the STATIC approach would further under utilise the resources that were present. Another disadvantage to the STATIC approach is that assigning adequately accurate available bandwidth estimates for each of the network paths is quite a difficult task, given our scenario of an unknown and uncontrolled intermediate topology. For these reasons, we discard the STATIC approach and compare only the ABAC and REVMAX algorithms for the rest of this paper. The ABAC and REVMAX algorithms can both be seen to adapt to the worsening network conditions in the increased background traffic scenario. This is due to the fact that the admission control component of the framework rejects more flows when

0.2

0.2

ABAC REVMAX Static

ABAC RevMax Static

0.18 0.16

0.15 0.14

Delay (s)

Delay (s)

0.12 0.1

0.1 0.08 0.06

0.05 0.04 0.02 0

0 0

500

1000

1500

2000 Time (s)

2500

3000

3500

0

500

(a) Steady State Network.

2000 Time (s)

2500

3000

3500

3000

3500

End to End Delays.

180

Steady State Increased Background

160

160

140

140

120

120 Accepted Requests

Accepted Requests

1500

(b) Increased Background Network. Fig. 4.

180

1000

100

80

100

80

60

60

40

40

20

20

0

Steady State Increased Background

0 0

500

1000

1500

2000 Time (s)

2500

3000

3500

0

500

1000

(a) ABAC.

1500

2000 Time (s)

2500

(b) REVMAX. Fig. 5.

Requests Admitted.

there is increased background traffic. Figures 5(a) and 5(b) compares the requests admitted during the steady state and increased background scenarios for each of the algorithms. It can be seen that for the same scenario, both the ABAC and REVMAX algorithms admit a similar number of flows overall, thus explaining the resultant similar delays experienced in the network. Their ability to adapt to the increase in background traffic is demonstrated by the decrease in overall requests accepted by each algorithm. ABAC and REVMAX accept 5.5% and 6.5% less requests, respectively. The advantage of REVMAX over ABAC is readily apparent when the admitted flows are examined in terms of the revenue they provide to the IPTV operator. This information is summarized in Table III. Comparing the revenue generated by both algorithms in the steady state network, a relatively modest improvement can be seen when using REVMAX (3%). This is due to the fact that in steady state REVMAX can

TABLE III S UMMARY OF R EVENUE G ENERATED .

ABAC REVMAX

Steady State $712 $734

Increased Background $633 $709

accomodate the majority of requests from all priorities, and therefore operates in a similar fashion to ABAC. As has been mentioned, fewer requests are accepted overall in the Increased Background traffic scenarios. The ability of the REVMAX approach to prioritize requests of a higher revenue means that it returns a noticeably greater revenue than ABAC in these poorer network conditions (12% greater). This is the strength of the REVMAX algorithm and is further apparent when one looks at how each of the algorithms adapts to the change in network conditions. ABAC shows a significant loss of revenue (-11%) due to requests

60

ABAC REVMAX

50

Accepted Requests

40

30

20

10

0 0

Fig. 8.

500

1000

1500

2000 Time (s)

2500

3000

3500

Cumulative Total of Top Priority Requests Admitted.

being rejected based solely on the current available bandwidth estimates. By being aware of the probability that a higher value request will arrive, REVMAX is capable of preserving and continuing to accept higher value requests and thus limit the loss in revenue (-3%) despite degraded network conditions. Figures 6(a) and 6(b) are stacked graphs of the two algorithms exhibiting this behaviour. In Figure 6(a) all the content priorities see a reduction in the throughput they are generating. This can be compared to Figure 6(b) where the higher the priority, the lower the reduction in throughput for that particular priority. Figures 7(a) and 7(b) serve to highlight this adaption to the new available bandwidth. In Figure 7(a), from 1200 seconds onwards, it can be seen that the ABAC throughput of the top priority content starts to fade away as much less new requests are admitted by the framework. However, REVMAX continues to use the few requests it can admit to prioritize the most beneficial requests from a revenue perspective. Figure 7(b) shows that whilst both algorithms show a lowered throughput for low priority traffic when the background is increased, REVMAX shows a greater decrease as it is rejecting a higher percentage of low priority traffic. To demonstrate the prioritisation of REVMAX of the top priority requests, Figure 8 is presented. This is the cumulative total of top priority flows. In this figure a split is apparent at 1200 seconds with REVMAX continuing to accept the requests for top priority item types. This is in contrast to ABAC which levels out for the duration of the increased background and then begin to increase again as more requests are accepted when the bandwidth becomes available again. VI. S UMMARY AND F UTURE W ORK This paper has presented an approach to server selection and admission control for IPTV networks that can predict the likelihood of requests being received for the various content priorities and can allocate the available resources (bandwidth) in a manner that maximizes the revenue generated. We have shown that this approach does not need access to the intermediate topology and the delay experienced by

IPTV traffic is robust to external changes in the available bandwidth as it adapts the number of requests admitted. As well as maximizing revenue when resources are scarce, we have also demonstrated that this approach can preserve the revenue levels of an IPTV system when there is a sudden change in the available bandwidth. In the future, we plan to extend the algorithm presented to control requests arising from multiple network points of attachment, as well as extending the algorithm to cater for content items of varying length such as requests not running to completion, or having no pre-determined completion time. We will also explore its use in scenarios where content is distributed unequally amongst the servers with the intention of exploring algorithms to control the migration and/or replication of content items between content servers. We intend to examine this while focusing on maximising revenue and minimising costs in, for example, cases where content server space or bandwidth (or both) is being rented by the service provider. ACKNOWLEDGEMENT This work was funded by Science Foundation Ireland via grant 08/SRC/I1403 and by the Irish Research Council for Science, Engineering and Technology, co-funded by Marie Curie Actions under FP7. R EFERENCES [1] B. Meskill, A. Davy, and B. Jennings, “Server selection and admission control for IP-based video on demand using available bandwidth estimation,” IEEE Conference on Local Computer Networks, 2011. [2] A. Davy, D. Botvich, and B. Jennings, “Revenue optimized IPTV admission control using empirical effective bandwidth estimation,” IEEE Transactions on Broadcasting, vol. 54, pp. 599 –611, 2008. [3] M. Fidler and V. Sander, “A Parameter Based Admission Control Algorithm for Differentiated Services Networks,” Computer Networks, vol. 44, no. 4, pp. 463–479, 2004. [4] Y. Jiang, P. Emstad, V. Nicola, and A. Nevin, “Measurement-based admission control: A revisit,” in 17th Nordic Teletraffic Seminar, 2004. [5] S. Latre, B. De Vleeschauwer, W. Van de Meerssche, S. Perrault, F. De Turck, P. Demeester, K. De Schepper, C. Hublet, W. Rogiest, S. Custers, and W. Van Leekwijck, “An autonomic pcn based admission control mechanism for video services in access networks,” IFIP/IEEE International Symposium on Integrated Network Management-Workshops, pp. 161 –168, 2009. [6] “Pre-Congestion Notification (PCN) architecture ietf rfc 5559,” [Online]. http://www.ietf.org/rfc/rfc5559.txt. [7] J. Asghar, F. Le Faucheur, and I. Hood, “Preserving video quality in iptv networks,” IEEE Transactions on Broadcasting, vol. 55, no. 2, pp. 386 –395, 2009. [8] “Resource ReSerVation Protocol (RSVP) version 1 functional specification, ietf rfc 2205,” [Online]. http://www.ietf.org/rfc/rfc2205.txt. [9] P. Chandra and B. Sahoo, “Performance analysis of load balancing algorithms for cluster of video on demand servers,” IEEE International Advance Computing Conference, pp. 408 –412, 2009. [10] N. Carlsson and D. L. Eager, “Server selection in large-scale videoon-demand systems,” ACM Transactions on Multimedia Computing Communications and Applications, vol. 6, no. 1, pp. 1–26, 2010. [11] A. Cabellos-Aparicio, F. Garcia, and J. Domingo-Pascual, “A novel available bandwidth estimation and tracking algorithm,” Proceedings of IEEE Network Operations and Management Symposium, pp. 87–94, 2008. [12] M. Jain and C. Dovrolis, “Pathload: A measurement tool for end-toend available bandwidth,” Passive and Active Measurements Workshop, 2002.

120

120 High Priority Middle Priority Low Priority Available

100

100

80

80 Bandwidth (Mb)

Bandwidth (Mb)

High Priority Middle Priority Low Priority Available

60

60

40

40

20

20

0

0 0

500

1000

1500

2000 Time (s)

2500

3000

3500

0

500

1000

(a) ABAC.

2000 Time (s)

2500

3000

3500

2500

3000

3500

(b) REVMAX. Fig. 6.

40

1500

Utilization By Both Algorithms.

25

ABAC REVMAX

ABAC REVMAX

35 20

25

Bandwidth (Mb)

Bandwidth (Mb)

30

20

15

15

10

10 5 5

0

0 0

500

1000

1500

2000 Time (s)

2500

3000

3500

0

500

(a) Top Priority.

1000

1500

2000 Time (s)

(b) Low Priority. Fig. 7.

Utilization Comparisons.

[13] J. Strauss, D. Katabi, and F. Kaashoek, “A measurement study of available bandwidth estimation tools,” ACM SIGCOMM conference on Internet measurement, pp. 39–44, 2003. [14] E. Goldoni, G. Rossi, and A. Torelli, “Assolo, a new method for available bandwidth estimation,” International Conference on Internet Monitoring and Protection, pp. 130–136, 2009. [15] J. Sommers, P. Barford, and W. Willinger, “A proposed framework for calibration of available bandwidth estimation tools,” IEEE Symposium on Computers and Communications, pp. 709 – 718, 2006. [16] C. Dovrolis, P. Ramanathan, and D. Moore, “Packet-dispersion techniques and a capacity-estimation methodology,” IEEE/ACM Transactions on Networking, vol. 12, no. 6, pp. 963–977, 2004. [17] S. Ekelin, M. Nilsson, E. Hartikainen, A. Johnsson, J.-E. Mangs, B. Melander, and M. Bjorkman, “Real-time measurement of end-to-end available bandwidth using kalman filtering,” Proceedings of IEEE/IFIP Network Operations and Management Symposium, pp. 73 –84, 2006. [18] M. Neginhal, K. Harfoush, and H. Perros, “Measuring bandwidth signatures of network paths,” IFIP Networking, pp. 1072–1083, 2007. [19] C. D. Guerrero and M. A. Labrador, “On the applicability of available bandwidth estimation techniques and tools,” Computer Communications, vol. 33, no. 1, pp. 11 – 22, 2010. [20] E. Goldoni and M. Schivi, “End-to-end available bandwidth estimation tools, an experimental comparison,” in Traffic Monitoring and Analysis,

[21] [22] [23] [24]

[25] [26]

ser. Lecture Notes in Computer Science, F. Ricciato, M. Mellia, and E. Biersack, Eds. Springer Berlin / Heidelberg, 2010, vol. 6003, pp. 171–182. A. Shriram and J. Kaur, “Empirical evaluation of techniques for measuring available bandwidth,” 26th IEEE International Conference on Computer Communications, pp. 2162–2170, 2007. V. J. Ribeiro, R. H. Riedi, R. G. Baraniuk, J. Navratil, and L. Cottrell, “pathchirp: Efficient available bandwidth estimation for network paths,” in Passive and Active Measurement Workshop, 2003. “Opnet modeler, discrete event simulation model library,” [online] http://www.opnet.com/solutions/network rd/modeler.html. P. Seeling, M. Reisslein, and B. Kulapala, “Network performance evaluation using frame size and quality traces of single-layer and twolayer video: A tutorial,” IEEE Communications Surveys Tutorials, vol. 6, no. 3, pp. 58 –78, 2004. X. Cheng, C. Dale, and J. Liu, “Understanding the characteristics of internet short video sharing: Youtube as a case study,” ACM SIGCOMM Conference on Internet Measurement, p. 28, 2007. T. Rahrer, R. Faindra, and S. Wright, “Triple-play services quality of experience (QoE) requirements,” Technical Report TR-126, DSL-Forum, Architecture & Transport Working Group, 2006.