Probe Based Dynamic Server Selection for

Probe Based Dynamic Server Selection for Multimedia QoS Michael Searles, Philip Perry, Liam Murphy Department of Computer Science, University College Dublin, Belfield, Dublin 4, Ireland [email protected], [email protected], [email protected]

Abstract This paper proposes a probe-based scheme to select which one of a number of replica servers to use to satisfy client requests for multimedia content. Our scheme attempts to select the candidate server that can provide the best connection in terms of loss, delay and jitter (delay variation). A grading system applies meaningful values to periodic active probe measurements, and a selection algorithm chooses a server so as to avoid congested paths and bursty network traffic in order to improve end-user video presentation quality. Our proposed dynamic server selection system has been designed to work as a complementary technology with any existing multimedia congestion control system. Some experiments to evaluate the performance of the proposed scheme are described. Key Words – Mobile Multimedia, Multimedia QoS support, Dynamic server selection, Multimedia traffic management, Video streaming.

I.

Introduction

As Metropolitan Area Network (MAN) infrastructure scales, service providers replicate data and resources to serve more clients concurrently. While content/media replication is an effective technique for improving the scalability and performance of a media delivery system, it needs to be coupled with an effective selection technique in order to make efficient use of this increased capacity. This paper proposes a probe-based scheme to select which one of a number of replica servers to use to satisfy client requests for multimedia content. We are particularly interested in the use of wireless and mobile devices to access these services through the MAN, so that the probing function is devolved to a multicasting proxy in the access network. The evolution of mobile cellular systems has seen the deployment of data services based on General Packet Radio Service (GPRS) and other systems. These systems have yet to find a method of enabling secure multicast over the air interface. Such a multicast system would use a single radio channel to send a stream of multicast IP packets to a number of mobile nodes within a particular cell. One of the major applications of this type of system would be the multicasting of streamed video content: news programmes, sports highlights, music videos, and so on. It seems likely that future cellular multicasting systems based on GPRS, Enhanced GPRS (EGPRS) and Universal Mobile Telecommunications System (UMTS) will use a multicasting proxy within their own networks. The multicasting could be coordinated from the Serving GPRS Support Node (SGSN) or its equivalent, since this is the network-side end point of the Logical Link Layer, or perhaps from the Gateway GPRS Support Node (GGSN) as this is where the IP packets are put into a GPRS tunnel. Although many difficult challenges are involved in implementing such a system, the work presented in this paper focuses on the issue of how this multicasting proxy decides which video streaming server to connect to for a particular content. The multicasting proxy needs to select the server that can provide the best connection in terms of loss, delay and jitter (delay variation). This will not necessarily be the closest server; rather, the decision will depend on the load on each server, the load on the server's access link, and the possibility of a fault or localised hotspot of activity in the MAN. Our approach is based on

20/1

probing techniques which have been used in the broader Internet, which are here applied to the specific case of video streaming in the network scenarios described above. The rest of this paper is organised as follows. In section 2, we outline the basis for service replication and selection. In section 3, we describe techniques that are used to support QoS for multimedia services. In Section 4, we introduce related server selection techniques. In Section 5 we explain the proposed server selection system architecture. In Section 6, we discuss the key components of the server selection system. In Section 7, we outline the tests that have been performed to date and describe planned future test, to evaluate the performance of our proposed system. In section 8 we present and analyse the characteristics of packet delay and jitter. Section 9, concludes the paper.

II.

Service Replication

Service replication is a process where identical copies of data are stored on a number of machines, known as replicas, which are geographically distributed around the Internet. Content/media replication is an important technique for improving the scalability and performance of a media delivery system [1,2], albeit at the additional cost of providing more servers. Service replication seeks to place replicas close to the client communities from where many requests are received and can provide the following advantages: • • • • •

Reduces unnecessary network traffic. Improves service load distribution on network links. Reduces load on streaming servers. Increases service availability. Reduces latency for clients.

When replication is used, an important concern is how to direct clients to the server that offers the best performance. The client should be able to use the most appropriate server without prior knowledge of the server location or network topology. This can be achieved with a Dynamic Server Selection System, where an appropriate server is dynamically selected for the user [3]. A DSSS requires a list of servers, which can provide the required service and a method for quickly and effectively estimating the QoS available from each host.

III.

QoS Support for multimedia

Voice and Video services have more restrictive Quality of Service (QoS) requirements on delay and delay jitter than data transfer applications [3]. The QoS for such video or voice services can be significantly affected by delay, delay jitter, and unreliable packet deliveries (which are typical characteristics of the basic IP Network service), because packets in an IP-Network are transported using a best effort mechanism [3]. Bursty packet loss and excessive delay have a negative effect on video presentation quality, and are usually caused by network congestion [1]. Application layer Congestion Control and Continuous Media Distribution Services are well-established complementary QoS technologies. The approach proposed here is to deploy congestion control mechanisms at end systems (i.e. an application layer congestion control scheme at each multimedia server) and continuous media distribution services within the network (i.e. server replication and distribution) in an effort to extract the benefits of both technologies, thereby minimising packet loss and delay as far as possible and improving the end-user perceived QoS. Once a server decision has been taken and a session is established with the server, the Rate Control scheme of an adaptive server attempts to minimize the possibility of network congestion by matching the rate of the video stream to the current network conditions [1]. Generally speaking, this type of system begins to degrade the bit-rate of the data stream, in a controlled

20/2

manner, once the transmission quality of the video stream falls below a series of pre-defined QoS target values. These QoS parameters are normally defined in terms of network characteristics such as delay, one-way delay variation, and percentage packet loss. Because of the dynamic nature of background traffic flows within a Metro network, the transmission quality of the path between the server and proxy can change over time. Furthermore, popular video content, such as breaking news headlines from the major news networks, can create periods of flash demand which can result in substantial loading of the server access link to the MAN. Without the intervention of the congestion control features of the adaptive server, these problems could result in very poor video presentation quality and in extreme cases could cause loss of service altogether.

IV.

Related Work

There have been many techniques used to guide clients to the use of a particular server among a set of replica servers. The simplest server selection approach is to assign servers using a static policy: a client is assigned to a server based on a static metric such as geographical location or number of hops. However, the closest server geographically may not necessarily be the best choice because it may not be the least loaded server or the closest server in terms of round trip delay [4]. [5] Indicates that a dynamic server selection policy is more flexible and responsive for locating servers, and is likely to be more effective than a static selection policy. The simplest dynamic selection method is to map requests randomly or in a simple round robin fashion to each of the candidate servers. This approach is simple and is primarily aimed at server load balancing, but it maintains no information about the transmission performance of the path to the server. This technique is best suited when the replicated servers are co-located on the same sub-net and have the same request processing capacity. More sophisticated dynamic server selection techniques have been proposed [5, 6, 7, 8, 9]. Such techniques typically select servers based on server performance and/or path characteristics that are dynamically measured. The majority of previous server selection studies have been conducted for data transfer applications, such as WWW information pages, where the focus is on selecting one of a relatively small number of mirrors hosting Web pages and images. In these cases, the primary metric of interest is the transaction/retrieval time for data objects. Due to the real-time requirements of video and audio data, dynamic server selection for the delivery of multimedia poses a significantly different set of QoS requirements. To date server selection for rich media has largely been ignored [10]. Our proposed server selection system has been designed to cooperate with an existing rateadaptive multimedia streaming application. It differs from earlier server selection work mainly because the server selection process is driven by metrics which are closely related to the video presentation quality perceived by the end user, and whose target values (on which the grading scheme is based) have been specifically chosen to correspond with those of the adaptive streaming application.

V.

Proposed Server Selection System Architecture

We present a probe based Dynamic Server Selection System (DSSS) that has been specifically designed to work as a complementary technology with any existing Rate-adaptive Multimedia Streaming Application (RMSA), both of which are deployed to provide Quality of Service (QoS) support for multimedia streaming to wireless clients. The server selection process is driven by the QoS requirements of the streaming application, which are defined in terms of target values for Round-trip-time delay, one-way delay variation, and percentage packet loss. Periodic active probing measurements estimate the transmission performance of the paths between a multicast proxy and various replica multimedia server candidates. A grading system applies meaningful

20/3

values to the probe measurements, and a selection algorithm arbitrates between grading scores. The goals of our proposed DSSS are to: 1. Direct clients to those servers whose paths are best equipped to fulfil the real-time requirements of the streaming media application; 2. Optimise where possible the performance of the server’s rate-adaptive scheme; 3. Efficiently utilize Metro network resources by avoiding congested paths and bursty network traffic; 4. Minimise the probing overhead in the network. The proposed server selection system architecture consists of three main elements as shown in Fig. 1: Multicast mobile Clients (2.5G), replica Rate-Adaptive Multimedia Servers, and proxy agents, known as Server Resolvers, which are embedded within the GPRS network and probe on behalf of the mobile clients. It is assumed that the GPRS Support Nodes (GSN's) where these proxies reside have Ethernet connections to a Metropolitan Area Network (MAN) which provides very substantial bandwidth to a number of video servers. These servers may be located in dedicated server farms or ISP's, so that their output to the MAN is considered to be the major bottleneck on the path to the multicasting proxy. Even if the physical connection from the farm to the MAN is quite broadband, is it expected that, somewhere within the farm's intranet, the output from a given server instance to a particular multicast group will need to contend for access to an Ethernet Hub. It is assumed that the Multimedia replicas are located in dedicated server farms or ISP’s, so the access link to the MAN is considered to be the primary bottleneck on the path between the proxy and the server replica. It is further assumed that the connectivity of the path between the server and proxy can be adversely affected by a network fault or a transient hotspot of activity in the MAN. Multicast Group Server Replica Server Replica

ISP-1 Mobile Hosts

Network Probing

ISP-3

Metro Media Request

ISP-2 Recommended server Server Resolver

Server Replica

GPRS Network.

Fig.1. Proposed Server Selection System Using active probing, the path characteristics are measured periodically between the server and proxy. The server resolver then determines the QoS available to its multicast client domain from each candidate server. These measurements are assessed by a grading scheme and allocated a QoS score. A server scheduler arbitrates between these server QoS scores. The server with the highest score becomes the recommended server. When a multicast service request is issued, this is directed to the server resolver device within the GPRS network. The resolver replies to this request with the address of the currently recommended server. To reduce the overhead due to probing, we use a cache to store the probing result in a server table at the proxy. The table is indexed by the order of preference and contains information regarding the server address, QoS score and certain flags relating to specific pathological network conditions

20/4

and server load. The server resolver periodically updates the table to reflect dynamic changes in network traffic and server conditions.

VI.

Server Selection System Overview

We assume that all replica servers maintain the same set of media content and employ the same batch scheduling and channel allocation policies. When a request is issued for video content, the selection system is concerned with the question of how to direct the request to the most appropriate server. This system is composed of three components (Fig. 2): • • •

A Measurement Component, using a number of small network probes, estimates the transmission quality of paths to each replicated server. A Grading Component that applies meaningful values to the probe measurements. A Selection Component that arbitrates between grading scores.

Network Probing Utility Periodically, the selection system performs active probe measurements. During probing, the probe utility issues a series of UDP echo request/response messages to each of the candidate servers. By bouncing a short stream of time stamped echo packets (equivalent to the average bit-rate of the streaming media) between media servers and the proxy, the probe utility can estimate the mean RTT, one-way inter-packet delay variation, and percentage packet loss between the candidate servers and GPRS proxy. Inter packet spacing and Packet Size.

(n) Server Replicas UDP Probe Utility

QoS Target Values

UDP echo packet Train Transmission Quality parameter Values

Grading System

QoS scores

Server Recommendation Server Scheduler Multicast Media Requests

Server Resolver

Fig.2. Server Selection System Components. Previous server selection work [5] demonstrates how the reliability and predictive power of active probing can in certain circumstances be dependent on the accuracy of the network probes in reflecting the properties of the media being transmitted. Therefore, for each probing measurement, the echo request packet size and inter-packet spacing have been set to reflect the packet size and mean bit-rate of the streaming video data. The UDP echo utility allows the inter-packet spacing and the packet size of the probe traffic to be changed – this allows the server selection system to facilitate video streams of different bit rates and packet sizes. QoS Grading Scheme The QoS grading system has predefined QoS target values for each of the three transmission parameters. Measurements for each parameter, which fall within the target values, are assigned a partial score. The system assigns a partial score to each transmission parameter by computing the relative difference between the measured and target parameter value. The overall score is a weighted aggregate of the partial scores. The weightings are determined by the relative importance

20/5

of the parameters. For instance, one of the objectives of the system is to optimise, whenever possible, the performance of the adaptive server. Because the adaptive scheme operates using a feedback system between the server and its clients, the metric that primarily determines the speed at which the system can react to pathological network conditions is round trip time. Currently, the system bases its server selection decision on the path estimates from the last set of probe measurements. A future improvement to the system will be to incorporate QoS grades from previous probe measurements into the current QoS score. Statistical estimates could be computed from past performance data which reflect typical levels of contention for a server and network connection. In this way, the grading system will reflect both shorter-term and longer-term network traffic conditions. Server Selection Algorithm. Each probing session can return multiple servers/paths that satisfy the QoS targets. In this case, the selection algorithm ranks the candidate servers according to their grading scores. The server with the highest score becomes the recommended server. In a situation when no candidate servers are returned that can satisfy the minimum QoS requirement of the application, the selection system prioritises the performance of the rate-adaptive scheme. It does this by weighting the selection criteria further in favour of minimum Round trip time delay. A connection to any one of these servers could result in poor transmission performance and may require the congestion control features of the adaptive server to maintain the continuity of the media service.

VII.

Performance Evaluation

In this section we outline the tests that have been performed to date and describe some of the future tests we intend to carry out to evaluate our proposed scheme. The first set of tests studies the influence of Access link utilization on the end-to-end transmission performance between the server and proxy device, and evaluates the performance of the metric collection technique in accurately estimating these changes in transmission quality. Traffic Load (%) 60 80 95

Jitter = 0 ms (%) 46.3 28.7 22.0

Jitter > 5ms (%) 21.2 47 55.6

Jitter > 10ms (%) 8.0 22.6 30.8

Table 1. Delay jitter distribution at different traffic loads. End-to-End Performance. In this set of tests, we were interested in the statistics of network delay, delay jitter and percentage packet loss due to the multiplexing and buffering of video traffic and probe traffic at the IP level with bursty background traffic. We wished to observe the change in the end-to-end connection quality between a server and proxy when various background traffic characteristics such as traffic load were applied to the access link in the path, and to compare these observations with estimates provided by the probe measurements. We created a simple test topology using the network simulator NS-2, which models the connectivity of the server selection system architecture, as shown in Fig. 3. A bottleneck was configured at the access link by restricting the capacity of the link to 30Mbs and a default delay of 20ms was set between the server and proxy device. Using this simulation environment, we could observe and tightly control the network behaviour, enabling different test cases to be created and eliminating unwanted background traffic. For each test case, we simulated a tagged video stream from the server to the proxy device and recorded, over a period of 5 minutes, its transmission quality in terms of packet delay, delay variation (ref. Table 1), and loss. Following this, we

20/6

activated the probe utility and estimated the same transmission parameters from the server to the proxy using the probe measurements. For this series of simulation experiments, we incrementally increased the traffic load on the access link of the path and repeated the test under each new traffic configuration. We assume that each node buffer is realistically finite and implements a first come first serve (FCFS) policy. Tagged Packet Stream UDP Echo Packets.

Sink Access Link (Bottleneck) Probing Utility

Node Server

Metro Links

Source

Cross Traffic. +/- Load, burst rate, and Burst length.

Fig.3. NS-2 Simulation Set-up. Grading System performance These future tests are designed to evaluate the performance of the grading component of the selection scheme and to determine the efficacy of the proposed selection scheme system by demonstrating how the server grading system reacts under different load conditions, both at the access link to the MAN and within the MAN itself. The test topology is similar to the one illustrated in Fig. 3, with the exception that the proxy device now includes the systems grading component and we have introduced cross traffic into those links that represent the MAN part of the path. As before, we create a series of different test network conditions by changing the characteristics of the background network traffic i.e. incrementally increasing traffic load and burstiness. For each test case, we stream a 5-minute test video stream from the server to the proxy and record the transmission quality of the stream. After this transmission we activate a probing session and the grading scheme estimates the QoS score. For each test traffic configuration, we compare the recorded QoS to that calculated by the Grading scheme. Proposed System vs. existing Selection Schemes. As part of the performance evaluation of the proposed server selection system, we plan to compare its performance relative to two other probe-based selection systems. The first is a server selection scheme, which assigns servers to clients based on the minimum round-trip time between client and server. The second selection system bases its selection decisions on the estimated available bandwidth to each candidate server. Using the network simulator, we simulate a number of separate transmission paths, where each path is connected to a candidate server and all paths terminate at a common node. This terminal node is connected to the proxy device that initiates the probing measurements and performs the QoS grading and server selection. The transmissions paths are configured to simulate cross traffic. We have sub-divided cross traffic characteristics into traffic load and traffic burstiness. For traffic load, we defined 4 levels to represent different traffic load conditions: 1. Light, 2. Light-moderate, 3. Moderate and 4. Heavy traffic conditions.

20/7

We defined 3 levels to represent different traffic burstiness: 1. Near constant bit-rate, 2. Moderate variability 3. High variability. Each transmission path is assigned a random value of cross traffic from each category. A number of simulation experiments, each using a different set of cross-traffic configurations, are tested. A series of measurements are taken for each simulation experiment using the three selection schemes.

VIII.

Results.

The following results focus on the changes in delay and delay variation of a tagged video IP stream when it is multiplexed with bursty background traffic under different load conditions (see Fig. 3). The load conditions range from 60% to 95% utilization of the access link capacity. The tagged video stream was simulated using a 50KBS near constant bit rate packet stream, with a fixed packet size of 1000 bytes. The Bursty background traffic was modeled by superimposing a number of independent sources at different bit rates and packet sizes. Fig. 4 Empirically established PDF of delay at different traffic load. 0.500

Sixty % Eighty % Ninty five %

0.450

Distribution

0.400 0.350 0.300 0.250 0.200 0.150 0.100 0.050 0.000 20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

Delay (ms)

Fig. 4 shows the delay distribution of the tagged video stream with sixty, eighty and ninety five percent load conditions on the access link in the server-to-proxy path. It can be seen that the increasing traffic load causes the distribution to have lower peaks indicating that video packets have less probability for zero added queuing delay from server to proxy. We also observe more significant tails across a wide range of delay values which corresponds to larger Delay variation and increasing overall mean delay.

Fig. 5 Empirically established PDF of jitter at different traffic loads 0.500 Sixty % Eighty % Ninty five %

0.450 0.400

Distribution.

0.350 0.300 0.250 0.200 0.150 0.100 0.050 0.000 -16

-14

-12

-10

-8

-6

-4

-2

0

2

Delay Jitter (ms)

20/8

4

6

8

10

12

14

16

These observations are corroborated by Fig. 5 which shows that an increasing traffic load causes the distribution of jitter PDF to have also smaller peak values around zero delay jitter and more pronounced tails across a large range of values corresponding to larger video packet delay jitter. For example, as shown in Table 1, for a traffic load of 60%, the percentage of packets with zero delay jitter is 43.3% and for jitter values greater than 10ms the percentage drops to 8.0%. In contrast, for a traffic load of 80%, 28.7% of packets have zero jitter delay and 22.6% have jitter delays greater than 10ms. This trend continues for higher load values

Fig. 6 Empirical PDF of Probe and Simulation Data for 60% load 0.550

Mean PDF Sim PDF

0.500 0.450

Distribution

0.400 0.350 0.300 0.250 0.200 0.150 0.100 0.050 0.000 0

1

2

3

4

5

6

7

8

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Delay (ms)

Using simulation data we can observe the impact of background traffic load on delay and delay jitter, and therefore quantify the change in end-to-end transmission performance under different traffic load conditions. To determine the validity of our probe utility, we performed a number of probe measurements under the same transmission conditions (using a network emulator) as we did for simulation experiments and compared the results. For these experiments, the packet size and inter-packet spacing of the probes were set to the same values as the tagged video packets. Fig. 6 represents the PDF of delay for probe and simulation data at a traffic load of 60%. From the graph we can see that both sets of data are closely correlated. From this we can conclude that the probe utility can estimate, with reasonable accuracy, the end-to-end transmission performance between the server and proxy device.

IX.

Conclusions and Future Work

Content/media replication is an important technique for improving the scalability and performance of a media delivery system. The efficient utilization of a set of replica servers hinges upon the ability to appropriately allocate servers to clients. The majority of previous server selection studies have been conducted in the context of data transfer applications. Due to the real-time requirements of video and audio data, dynamic server selection for the delivery of multimedia poses a significantly different set of QoS requirements. In this paper, we present a dynamic server selection system that has been designed to work as a complementary technology with any existing multimedia congestion control system. The primary goal of our selection scheme is to direct mobile clients to those servers whose paths are best equipped to fulfil the real-time requirements of the streaming media application. The numerical results that are presented in this paper illustrate the effect of bursty cross traffic on the end-to-end transmission performance of a simulated video steam. They show that delay and delay variation are sensitive to traffic load which causes significant clustering and dispersion of video packets, and which can have a detrimental effect on the video presentation quality. In addition, we have validated our proposed UDP probe utility, showing the probe estimates of endto-end transmission conform, within acceptable limits, to those observed from the simulation experiments.

20/9

Because the current implementation of the system is based on path specific metrics only, certain traffic network conditions could lead to an uneven load distribution across server replicas, and obstruct the scalability and performance of the replicated system. Future development of the system will incorporate server specific metrics into the system that could provide estimates of current contention for server resources. We plan to develop a further set of experimental network topologies using the network simulator NS-2 to assess the performance of the grading and server selection scheme under different cross traffic conditions, and test the performance of the proposed selection scheme against other dynamic selection techniques.

Acknowledgement The support of the Research Innovation Fund of Enterprise Ireland is gratefully acknowledged. References [1] Dapeng Wu, Yiwei Hou, Whenwu Zhu, Ya-Qin Zang, Jon Peha, Streaming Video over the Internet: Approaches and directions. IEEE Transactions On Circuits And Systems For Video Technology, Vol. 11, No. 3, March 2001. [2] Xiaoxiang Lu, Ramon Orlando Morando, Magda El Zarki, Understanding Video Quality and Its Use in Feedback Control, Packet Video 2002, Pittsburgh, PA, USA 2002. [3] L Zhang, Z Li and S N Koh, Effect of Delay and Delay Jitter on Voice/Video over IP, Journal of Computer Communications, Vol. 25, 2002, pp. 863-873. [4] E. Zegura, M. Ammar, Z. Fei, and S. Bhattacharjee, Application-layer anycasting: a server selection architecture and use in a replicated web service, IEEE/ACM Transactions on Networking, August 2000, p. 455-466. [5] R. L. Carter and M. E. Crovella, Server selection using dynamic path characterization in widearea networks, In Proceedings of IEEE INFOCOM 1997. [6] Meng Guo, Mostafa Ammar, Ellen Zegura, Fang Hao, A Probe-Based Server Selection Protocol for Differentiated Service Networks, In Proceedings of ICC 2002. [7] Sandra Dykes, Kay Robbins, Clinton Jeffery, An empirical evaluation of client-side server selection algorithms, In Proceedings of IEEE INFOCOM, March 2000. [8] Z. Fei, S. Bhattacharjee, E. W. Zegura, M. Ammar, A novel server selection technique for improving the response time of a replicated Service, In Proceedings of IEEE INFOCOM 1998. [9] Fang Hao, Ellen W. Zegura, Mostafa H. Ammar, Supporting Server Selection in Differentiated Service Networks, In Proceedings of INFOCOM 2001. [10] Lisa Amini, Henning Schulzrinne, On Probe Strategies for Dynamic Multimedia Server Selection, In Proceedings of IEEE Multimedia conference and Expo, August 2002.

20/10