Revolving Indexed Edge Buffering Architecture in ...

Revolving Indexed Edge Buffering Architecture in Staged On-Demand Streaming over the Internet: Design and Analysis 1 SHIVA SHANKAR RAMANNA, RAJ SHARMAN, RAM RAMESH, State University at New York at Buffalo, Buffalo, NY RAM GOPAL, University at Connecticut, Storrs, CT ________________________________________________________________________ On-demand streaming from a remote server through best-effort Internet poses several challenges because of network losses and variable delays. We provide a comprehensive review and develop taxonomy of current methods to enhance the delivery quality of multimedia streaming. We then develop new delivery models for a distributed architecture in which video is streamed from a remote server to an edge server where the video is buffered and then streamed to the client through a last mile connection. The model uses a novel revolving indexed buffering mechanism at the edge server and employs selective retransmissions of lost packets between the remote and edge servers for a best-effort recovery of the losses. The performance of buffer management and retransmission policies at the edge server is modeled and assessed using a probabilistic analysis of the streaming process and system simulations. The influence of different endogenous control parameters on the quality of stream received by the client is studied. Calibration curves on the QoS metrics for different network conditions have been obtained using simulations. These could be used to set the values of the different endogenous control parameters for specific QoS in real-time streaming operations. A methodology to benchmark transmission characteristics using real-time traffic data is developed to enable effective decision making on edge server buffer allocation and management strategies. Categories and Subject Descriptors: Multimedia Streaming, On-Demand Streaming, Remote Streaming General Terms: Edge Server Buffering, Selective Retransmissions Additional Key Words and Phrases: Quality of Service

_______________________________________________________________________ 1. INTRODUCTION As broadband connections become commonplace, the demands on high quality multimedia streaming applications over the Internet have increased enormously. Such applications include on-demand movies, live programs and video-conferencing, to name 1 Authors' addresses: Shiva Shankar Ramanna, Department of Computer Science and Engineering, State University of New York, Buffalo, NY, 14260; email: [email protected], Raj Sharman, Department of Management Science and Systems, School of Management, State University of New York, Buffalo, NY 14260; email: [email protected], Ram Ramesh, Department of Management Science and Systems, School of Management, State University of New York, Buffalo, NY 14260; email: [email protected]; Ram Gopal, Department of Operations and Information Management, School of Business, University at Connecticut, Storrs, CT 06269; email: [email protected].

Permission to make digital/hard copy of part of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date of appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee.

a few. Streaming such content online with low latency levels and jitter-free presentations is a major challenge for any service provider, as it requires enormous server, bandwidth and storage capacities. High variability in customer demand and the returns on investments render these massive investments risky for any service provider. Therefore topographical leveraging through cooperative multimedia caching is a viable option for many service providers. The focus of this paper is to develop and analyze a cooperative streaming strategy involving two servers to ensure the required quality of service levels at the customer end. Denoting the two servers as the Remote Host and the Edge servers, we develop a cooperative streaming model using a selective retransmission strategy from the host server and a revolving cache buffer architecture at the edge server. The proposed architecture and strategy can be extended to other network configurations of cooperative streaming as well. On-demand streaming applications can be broadly classified into two types: near and pure on-demand streaming. Near on-demand applications use techniques such as batching where the user has limited choices in making a request and controlling the stream. Pure on-demand streaming applications although have higher bandwidth requirements, allow clients not only to request the video to be streamed but also to have complete control over the stream. In this research we develop a distributed architecture for on-demand pure streaming for the following scenario. We consider a content provider hosting a set of videos at its host server. The clients are distributed geographically and each client is served by a local/regional ISP. Besides providing last mile access to the clients, each ISP hosts a set of servers on the edge. When a client requests a video from the content provider, the video is streamed from its host server to an edge server of the connecting ISP through best-effort Internet. The edge server provides the last mile delivery to the client, besides buffering the incoming stream. Two popular techniques used to achieve such on-demand streaming are: (a) Replicate all videos on edge servers and stream directly to the clients via last mile connections, thereby avoiding internet traffic (b) Peer streaming servers on the edge with assured bandwidth among them so that videos not available on a given streaming server can be obtained from another server in real time. Since the clients could be geographically distributed and the typical sizes of videos are huge, a full replication of all videos in each edge server may not be cost-effective or even feasible for many service providers. Furthermore, an ISP may not have adequate peering bandwidth resources to cover the

2

needs of the entire distribution of its clients. Hence, both solutions (a) and (b) may not be feasible in many cases. Consequently, the challenge lies in delivering pure on-demand streaming through best-effort internet without having these assumptions. We provide a comprehensive review of literature on current approaches to enhance delivery quality on the best-effort Internet. The extant body of work is organized through a taxonomy of multimedia QoS approaches. The schemes addressed include: compression, continuous media distribution, and application layer QoS. We propose a distributed streaming model to address significant lacunae in the current state-of-the-art methods. The central ideas of the proposed model are twofold: Edge buffering and Selective Retransmissions. While selective retransmissions in UDP based streaming has been extensively considered in the literature, the central contributions of this research are on managing an edge cache using a revolving buffering architecture. The buffering architecture is used to estimate the value of a retransmission in terms of its ability to deliver lost or delayed packets at the client station on time. Consequently, the buffering architecture is used to trigger and manage such potential retransmissions for maximal QoS at the client. Using the edge server as an intermediate buffer that also determines the flow of retransmitted packets from the host would yield better control over the streaming process. Assuming that packet loss is minimal over the last mile connection between the edge server and the client, this approach would lead to enhanced levels of best-effort packet delivery at the client. The proposed architecture consists of two broad components: A remote server application and an edge server application to handle pure on-demand unicast streaming of pre-encoded video through best-effort Internet. Videos that are not locally available are streamed from a remote server to the edge server, which eventually serves the client over the last mile. In this context, retransmission based schemes are generally considered inappropriate for multimedia applications because of the latency involved. However if timely retransmissions can be performed with a significant probability of success, such an approach to error control is attractive. This is because of the little overhead involved on network resources and the enhanced QoS that may result from using it in conjunction with preventive error control schemes (see Dempsey et al. [1996], Zimmermann et al. [2003], Zink et al. [2000]). Consequently, our proposed strategy is to employ an edge buffering mechanism to overcome the variability in packet transmission delays over the Internet, and at the same time, use the buffering mechanism to trigger potential retransmissions that could be selectively used to enhance the final QoS. Issues of

3

incoming stream management, edge buffer management, coordination between the original and retransmission streams and the output streaming strategy all together define the edge server application architecture. Similarly, the issues of outgoing streams (original and retransmitted) management, remote buffer management, and retransmission request handling together define the remote server application architecture. We have modeled and assessed the performance of the proposed architecture using a probabilistic analysis and system simulations. These analyses have yielded a set of calibration curves on the client-level QoS metrics in terms of the endogenous control parameters of the architecture and the exogenous network parameters. Using network sniffers to estimate existing network conditions in terms of the exogenous parameters, these curves could be used in real-time streaming operations by setting the control parameters at appropriate levels for desired QoS levels. The methodology to benchmark transmission characteristics using real-time traffic data to enable effective decision making on edge server buffer allocation and management strategies significantly enhances the practical appeal of the proposed model. The remainder of this paper is structured as follows. Section 2 presents a fairly comprehensive review of the related work with a taxonomy of QoS approaches to multimedia streaming and positions our work in this body of literature. Section 3 develops the proposed remote streaming architecture.

The central ideas behind the

proposed architecture along with the remote server and edge server application design are discussed in this section. Section 4 develops the various system parameters and performance metrics that are used in the proposed model. Section 5 presents an implementation to the streaming model using a high level pseudocode. A probabilistic performance model and a simulation model of the proposed architecture are developed in Section 6. The computational results with both these models are discussed along with their implications on application design and real-time streaming control in section 7. Section 8 concludes the paper and provides future research directions.

2. RELATED WORK Ensuring appropriate levels of QoS in multimedia streaming is a central theme of a vast body of literature in this area. Past efforts in this direction can be classified along several dimensions. In the following discussion, we present a taxonomy of approaches used in streaming and position our work appropriately in this body of literature.

4

Extensive research exists on coping with the timing and bandwidth constraints posed on multimedia streaming so that best possible QoS could be achieved in a best-effort internet scenario. These works can be divided into three broad categories as presented in Wu et. al. [2001]: Video compression techniques, Continuous media distribution services and Application layer QOS techniques. Using these categories as the base dimensions, a taxonomy of approaches used in the literature is presented in Table I. We briefly synthesize these developments in streaming architectures and strategies as follows. While the research on each of these categories is vast, we address some of the recent works in the following discussion. However, we address the retransmission schemes in some detail as they are closely related to our current research.

Table I. A Taxonomy of Multimedia QoS Approaches 1.

Video Compression Schemes a.

Non-Scalable Encoding Schemes

b. Scalable Encoding Schemes 2.

Continuous Media Distribution Schemes a.

Network Filtering Methods

b. Application level Multicast Methods c.

Content Replication Methods i. Mirroring Strategies ii. Caching Strategies

3.

Application Layer QoS Schemes a.

Congestion Control Methods

b. Error Control Methods i. Error Resilient Encoding Schemes ii. Error Concealment Schemes iii. Forward Error Correction Schemes (FEC) iv. Retransmission Schemes

2.1. Video Compression Schemes

5

Video compression schemes can be further categorized into non-scalable encoding and scalable encoding techniques. Non-Scalable techniques (also known as “base only”) encode videos into a single compressed bitstream, whereas a scalable video encoder compresses a video stream into multiple substreams. One of the compressed substreams is the base sub stream, which can be independently decoded. Other compressed sub streams are enhancements, which can only be decoded together with the base sub stream and can provide better quality. The complete bit-stream (i.e., combination of all the sub streams) provides the highest quality. The scalabilities of quality, image sizes, or frame rates, are called SNR, spatial, or temporal scalability, respectively. These three scalabilities are basic scalable mechanisms. There can be combinations of these basic mechanisms. Compression schemes have been discussed in Girod et. al. [1995] and Li et. al[1999]. Rejaie et al. [1999] present a compression mechanism for layering video in the context of congestion control. Conklin et al. [2001] address various problems associated with video compression techniques in streaming over the Internet. Hsiao et al. [2001] show how TCP can be modified to accommodate hierarchically layered video streams, while Kangasharju et al. [2002] develop mechanisms for layered encoding using caches.

2.2. Continuous Media Distribution Schemes Continuous media distribution schemes can be further classified into network filtering, application level multicast and content replication methods. These schemes have been developed to achieve significant QoS as well as improved streaming efficiency over besteffort internet. Network filtering aims to maximize video quality during network congestion. Such filters can adapt the rate of video streams according to the network congestion status. Network filters are placed suitably by service providers to achieve best results. Network filtering has been discussed in Hemy et. al. [1999] and Karrer and Gross [2001] address several factors that affect the quality of multimedia streams during handoffs among the various nodes in a transmission path. Application-level multicast is aimed at building a multicast service on top of the Internet and to support large scale content delivery. Application level multicast addresses the issues of scalability, network management, deployment, and support for higher layer functionality (e.g. error, flow, and congestion control) which cannot be achieved by IP level multicast. (Fast Forward Networks [2000]). In this context, Mccanne et al. [1996] present layered multicast protocols and Rizzo [2000] develops a scalable and stable TCP-based multicast congestion control mechanisms. Content replication is used to improve scalability of the

6

media delivery system. Content replication primarily reduces the load on the streaming server, besides also decreasing the latency for clients by increasing the availability of media content. Content replication techniques include two broad categories: mirroring and caching. Mirroring is used to place copies of the original multimedia files on other machines scattered around the Internet. Cache sharing and Cache hierarchies allow each cache to access files stored at other caches so that the load on the origin server can be reduced and network bottlenecks can be alleviated. Major works in this field include Bouazizi et. al. [2003], Fu et. al.[2002], Miao et. al[1999], Mourad et. al. [1996], Sen et. al. [1999] and Rejaie et. al. [2000].

2.3. Application Layer QoS Control Schemes Application layer QoS control schemes have been proposed to cope with varying network conditions and different presentation qualities requested by the users. Buffer management and admission control at application layer level are also important considerations in multimedia streaming presentations and several approaches have been proposed in this regard (see Little [1993], Balkir and Ozsoyoglu [1998]). The application-layer techniques can be further categorized into Congestion control schemes and Error control schemes. Congestion control schemes are employed to prevent packet loss and reduce delay. For streaming video, congestion control usually takes the form of rate control. Rate control minimizes the possibility of network congestion by matching the rate of the video stream to the available network bandwidth. Congestion control schemes have been discussed in Eleftheriadis et. al. [2001] . Error control schemes on the other hand are used to improve video presentation quality in the presence of packet loss. Error control mechanisms can be further categorized into error-resilient encoding, error concealment, forward error correction (FEC) and retransmission schemes.

2.3.1. Encoding, Concealment and Correction Schemes The objective of Error-resilient encoding is to enhance the robustness of compressed video to packet loss. However, most of these schemes such as re-synchronization marking, data partitioning, and data recovery are targeted at error-prone environments like wireless channels and may not be applicable to the Internet environment. (Wang et. al. [1997]). However, some research exists in the area of network aware Internet video encoding (Briceno et al. [1999]) and research in this area is ongoing. On a comparative note, research on Error concealment strategies is more extensive. Wada [1989] discusses

7

a few error concealment schemes. However, these schemes are not strictly error control strategies because they do not actually recover lost data, but rather create an approximation based on information before and/or after the loss. High-quality concealment algorithms might be expensive for high bandwidth applications and may necessitate the use of specialized hardware as suggested in Papdopoulos et al. [1996]. Lu and Christensen [1999] propose a selective buffering strategy using error concealment to improve the quality of MPEG videos. Varadarajan et al. [2002] introduce the notion of error spreading in continuous media streaming and develop a packet permuting algorithm to effectively conceal errors. Cuetos and Ross [2003] present a framework for scheduling decisions at the sending server that specifically accounts for error concealment in video reproduction at a client in lossy networks. The Forward Error Correction (FEC) approach is closely related to error concealment; in FEC, redundant information is added to a packet so that the original packet could be recovered in the presence of packet loss. FEC techniques have been discussed in Wu et. al. [2000], Bolot et. al.[1996], Albanese et. al [1996], Nonnenmacher et al. [1998], Puri et. al. [2000] and Tan and Zakhor [2001].

2.3.2. Retransmission Schemes Retransmission is usually not considered a viable option for multimedia streaming to recover lost packets since a retransmitted packet may not reach the client within its playout time. However selective retransmission, also known as delay-constrained retransmission which suppresses requests that will not arrive in time is considered a very good approach. Selective retransmission is often compared to FEC as an alternate mechanism for enhancing QoS. In this context, although FEC reduces transmission latency, its disadvantages include a significant increase in transmission rate and hence, greater bandwidth requirements. Also unlike FEC, which adds redundancy regardless of correct receipt or loss, a retransmission-based scheme only resends the packets that are lost. Thus, a retransmission-based scheme is adaptive to varying loss characteristics, resulting in efficient use of network resources. In this research, we develop a novel scheme for streaming control that employs selective retransmissions. Before we discuss other related work on retransmissions, we should mention that some of the techniques mentioned above such as FEC, scalable encoding or various application layer techniques such as multicasting can be used in conjunction with the proposed revolving indexed buffer architecture. These are important and effective extensions to the work presented in this paper.

8

Piecuch et al. [2000] propose a selective retransmission protocol (SRP) to balance the loss found in UDP and latency in TCP. SRP uses an application specific decision algorithm to determine whether a retransmission request is to be sent or not by adjusting the loss and latency to the optimum levels for the application. Emir et. al. [2003] propose a new streaming protocol called Lightweight Streaming Protocol (LSP). LSP uses an estimated round trip time (ERTT) to selectively request for retransmissions. It also addresses network congestion by selectively dropping frames thereby reducing the transmission rate. However both these protocols use a client-server model and do not provide services such as synchronization and multiplexing as in RTP/RTCP. Papdopoulos et al. [1996] present an error control scheme for continuous media applications based on retransmissions. The client side buffer is a simple FIFO queue and the determination of which packets to be requested for retransmission is made by maintaining a smoothed RTD (round trip delay) parameter. Hasegawa et al. [1996] develop a video retrieval protocol that incorporates both pre-fetch and selective retransmissions such that the lost or delayed packets are obtained before the play-out time. Wang and Bhargava [1997] employ selective retransmissions in a method for transmitting large multimedia objects over the Internet. Their approach combines retransmissions with packet size reduction and multi-pass transmission. Li et. al. [1998] propose the LVMD (Layered Video Multicast with Retransmissions) algorithm. This algorithm addresses the network congestion problem using layered video coding techniques by allowing each receiver to subscribe to a subset of the video layers according to its processing power and network bandwidth availability. The model uses retransmissions in such a layered environment. Lee and Lee [1998] develop a retransmission scheme for mission-critical MPEG streams by employing virtual buffers that keep track of error propagation ranges and packet characteristics such as size, type, etc. Yamaguchi et. al. [2000] propose a transport layer protocol termed R3TP. This protocol provides high quality real time data transfer by adopting ATM Block Transfer (ABT) and retransmission-based error control. The model however is realized only on IP over ATM networks. Anjum and Jain [2000] study the option of using link layer retransmissions to improve TCP performance over lossy networks. Feamster et. al. [2002] propose an interesting scheme specifically for MPEG 4 streams. Their model leverages the characteristics of MPEG-4 to selectively retransmit only the most important data in the bitstream. When latency constraints do not permit

9

retransmission, they propose a mechanism for recovering this data using post processing techniques at the receiver. Zink et. al[2002] uses the combination of caching and layered video streaming in developing a promising Internet VoD system. They study the issue of dealing with retransmissions of missing segments for a cached layered video in order to meet users’ demands to watch high quality video with relatively little quality variations. Zimmermann et. al. [2003] propose a retransmission based error control (RBEC) scheme in an environment where the data is randomly distributed across multiple server nodes. Large-scale continuous media (CM) system implementations require scalable servers most likely built from clusters of storage nodes. The RBEC technique utilizes the benefits of random data placement in a cluster server environment while allowing a client to efficiently identify the correct server node for lost packet requests. Sinha et. al. [2004] propose two new retransmission-based error recovery protocols, one for unicast and another for multicast, which do not rely on timers to perform multiple retransmissions. The motivation of their designs is the problems with timer-based protocols, which includes the difficulties in maintaining accurate RTT estimates and timeouts in the face of jitter. Nithish et. al. [2004] propose a RTP based retransmission scheme using network processor based routers (NPRs). Such intermediate routers have the capability of buffering and retransmitting packets upon request. This work addresses the important issue of latency involved with an end to end method for determining the necessity for retransmission. However, having such routers will require a significant change in the existing network infrastructure. The edge server model that we have proposed here is a better option without any such changes required. Since intermediate buffering is not considered in most of these approaches, the efficacy of retransmissions is questionable. This is because the client playing stations have to cope with the stringent time constraints in continuous media traffic and usually have very little time to recover lost packets while maintaining continuous play or will have to compensate with a large client side buffer which would mean a substantial increase in start up latency. Hence using an efficient intermediate buffering technique is crucial to taking advantage of the retransmission strategy. Furthermore, instead of proposing a new streaming protocol to address these problems, we develop a streaming model which uses widely used streaming standards RTP, RTCP and RTSP as suggested by a few recent Internet drafts on using RTCP based feedback for retransmissions. This compliance with well-known standards renders the proposed application layer methodology easily implementable, transportable and scalable. We have used RTCP

10

based feedback for the determination of potentially useful retransmission requests and the management and control of the retransmission process in our model. However, we do not specify the details of the packet formats to accommodate retransmissions, as this is beyond the scope of this work. Interested readers could refer the latest internet drafts on RTP/RTCP for the proposed packet formats.

3. REMOTE STREAMING ARCHITECTURE In order to simplify the presentation, we consider the following streaming scenario. The streaming process entails a remote server, a local edge server and a client. The remote server streams to the edge server over the Internet; the edge server buffers the stream and then transmits it out to the client over a last mile connection. Videos are assumed to be pre-encoded at different encoding rates and maintained at the remote server. Encoding rate is a measure of video quality; higher rates imply greater video quality. Accordingly, an appropriate encoded rate for a video would be chosen based on the available last mile bandwidth and the client requirements. In a given session, let ER (packets/sec) denote the encoding rate chosen. Let SR denote the rate at which the remote server streams the data to the edge server. Due to network effects (congestion and packet losses), the edge server would receive the incoming stream at a rate less than or equal to SR. Assuming that the edge server streams out at the same rate at which it receives, the client also would receive the data at a rate less than or equal to SR. We denote this rate as the client realized rate CR. The client would then play back at rate ER using a local buffer to compensate for the mismatch between CR and ER. We assume that the packet losses in the last mile are minimal and that streaming connections cannot be pre-empted by other connections once they are established. 3.1 Streaming Architecture: An Integrated View An integrated view of the proposed streaming architecture is presented in Figure 1. The streaming architecture consists of two central application components, one at the remote server and the other at the edge server. The user interacts with the edge server application from the client player through an RTSP channel. RTSP is over TCP (which is not a persistent connection) whose default port number on the server side is 554. The actual transmission of video data is over UDP channels using RTP/RTCP protocols that come in pairs. First, a separate UDP channel pair supporting RTP/RTCP is established for the transmission from the edge server to the client. This is denoted as Channel 1. Next, two UDP channel pairs of communication are established between the remote and edge

11

servers. We call them Channels 2 and 3. Channel 2 is used for the original stream and Channel 3 for the retransmission stream. Each of these channels are established through an initial RTSP handshake and terminated by the same RTSP route. Note that unlike RTSP channels, these are persistent connections and will remain throughout the entire streaming session. In each channel, RTP uses an even numbered UDP port (2n) and the corresponding RTCP uses the immediate odd numbered UDP port (2n+1). Furthermore, RTCP2 and RTCP3 are not used for any specific purpose in the proposed architecture; therefore they can be set to UDP port number 0. Figure 2 shows the proposed RTSP streaming control mechanism. Note that for every RTSP message sent to the edge server from the client, the edge server acts as an application proxy and sends it to the remote server. Further, the RTSP session between the remote and edge servers embed the two streams– original and retransmission, between its setup and teardown. A high level algorithmic architecture1 of the integrated set of components is described in Section 5. In the following discussion, we develop three further specific views of the architecture: a remote server view, an edge server view and edge server buffer design and management view.

RemoteServ er

RTSP2

Edge Serv er

RTSP1

Client Play er

RTP2 Channel 2 RTP1

RTCP2 RemoteServ er

Edge Serv er RTP3 Channel 3

Channel 1

Client Play er

RTCP1

RTCP3

Fig. 1. Communication channels for the proposed Streaming Architecture

1

A detailed C-style pseudocode of the entire application can be obtained by requesting the lead author.

12

HTTP GET

Web Server

Presentation Description f ile

SETUP

SETUP

PLAY

Remote Server

Web Brow ser

PLAY

Original Stream

Edge Server

Retransmitted Stream

Combined Stream

Client Player

PAUSE

PAUSE

TEARDOWN

TEARDOWN

Fig. 2. Proposed RTSP Streaming Control

3.2 Streaming Architecture: Remote Server View The streaming component architecture at the remote server is shown in Figure 3. This architecture consists of four separate threads that are bound to different transport layer sockets.

These

threads

are

denoted

as:

Stream

control

remote

interface

(rs_control_interface), Transmitter (rs_app_out), Request receptor (rs_retran_in), and Retransmitter (rs_retran_out). The names in the parenthesis refer to the corresponding modules in the pseudocode presented in the appendix. We describe the internals and functionalities of these threads below. Stream control remote interface: The Stream control remote interface receives and interprets RTSP requests from the edge server. Upon receiving a setup request, it performs a check whether the client can be streamed using a client admission control algorithm. If the client can be streamed, then it allocates the necessary resources for the session. It also maintains the state of the stream session at the remote server. Transmitter: The Transmitter reads the pre-encoded video file. Chunks of video data retrieved from the pre-encoded file are encapsulated in RTP packets. Each RTP packet in turn is encapsulated in a UDP segment. The Transmitter sends the RTP packets as a series of datagrams at a constant rate. As the packets are sent out on RTP channel2, a copy of the packets is stored in a FIFO (First In First Out) Buffer. The packets are stored in the buffer until they are streamed from the edge server so that if there is a retransmission request, they can be streamed again from the buffer without having to read from the disk.

13

Request receptor: The Request receptor waits for any retransmission requests from the edge server and passes the requests to Retransmitter. Retransmitter: The Retransmitter receives requests from Request receptor and retransmits the packets requested by retrieving them from the FIFO buffer. FIFOBuf f er

PreEncoded Mov ie

Transmitter

RTP2

Request Receptor

Retransmitter

RTCP2

Stream Control RemoteInterf ace

RTSP2

RTP3

UDPChannels

TCP

Fig. 3. Remote Server View of the Architecture.

3.3 Streaming Architecture: Edge Server View The streaming component architecture at the edge server is shown in Figure 4. The architecture consists of six separate threads, besides a revolving indexed buffer, a pooled buffer and an index table. The threads are denoted as: Stream control edge interface (es_control_interface),

Receiver(es_app_in),

Transmitter

(es_app_out),

Receptor

(es_retran_in), Requester (es_retran_out) and Policy Manager. The first five are independent threads bound to different transport layer sockets. Their internals and functionalities are briefly discussed below. The policy manager is discussed in the next section after describing the buffer design. The index table is maintained to reflect the current set of packet sequence numbers in the indexed buffer and the packets that have been already requested for retransmission. Stream control edge interface: The stream control edge interface is used to interpret RTSP messages. When a setup request is received, it checks to see if the client can be admitted using a client admission control algorithm. If the video is locally available, it sends a reply back to the client and upon a play request; it would start streaming by starting the Transmitter thread. In case of a request for a video from a remote server, a setup request is sent to the remote server; upon positive response from the remote server,

14

the interface starts all the remaining four threads. It allocates resources (bandwidth, port numbers, buffer space etc) before streaming begins. It interprets all RTSP requests and passes on the requests to the remote server. Receiver: The Receiver receives the packets from the remote server on RTP channel2. When a packet is received, it checks the sequence number and inserts the packet into an appropriate bucket in the indexed buffer (the buffer design is described in the next section). If the sequence number of an arriving packet is outside the range maintained by the current set of indexed buckets, then the packet is inserted into the pooled buffer area. Transmitter: The Transmitter is responsible for streaming the RTP packets from the indexed buffer at a constant rate from the edge server to the client player. The packets are streamed bucket by bucket, in sequence. Requester: The Requester makes requests for retransmissions of missing packets in the indexed buffer as determined by the policy manager. RTCP requests for these packets are constructed and sent out to the remote server through RTCP channel 3. Receptor: The Receptor listens on its UDP socket for any retransmitted packets. When it receives a packet, it inserts in the appropriate bucket of the indexed buffer. If it cannot find the bucket outside the active zone of the indexed buffer it drops the packet. Rev olv ing Indexed Buf f er

Stream Control EdgeInterf ace

RTSP1

TCP

RTSP2

Transmitter

RTP1

Receptor

Index Table

Pooled Buf f er

Reciev er

RTP3

RTP2

Requester

Policy Manager

RTCP2

UDPChannels

Fig. 4. Edge Server View of the Architecture.

3.4 Edge Server Buffer Design and Management The objectives in designing a buffer system at the edge server are: (a) the available buffer space should be utilized effectively, (b) the buffer space should be organized into buckets

15

such that arriving packets can be inserted into their appropriate buckets efficiently, (c) when packets arrive out of the range of the buckets, they should be inserted into some auxiliary buffers without dropping them, (d) the buffer architecture should yield an efficient determination of what packets should be requested for retransmission and when to request them, and finally, (e) minimize the need for sequencing on the client player side when packets are sent from the edge server. The proposed organization of the buffer space into buckets yields a partial ordering of the packets in the memory. This ordering scheme enables efficient insertion of packets into buckets without sorting or searching. Furthermore, this scheme also enables efficient buffer management, control of the request-response process for retransmissions and leads to buffer configurations that could maximize the effectiveness of using retransmissions in enhancing the QoS at the client. The proposed buffering and streaming strategy is as follows. The buffering system consists of two components: a revolving indexed buffer and a pooled buffer. The indexed buffer has a fixed number of buckets. Each bucket is of fixed size and is assigned a range of sequence numbers of packets that it could hold at any point of time. Let N denote the number of buckets. The buckets are indexed sequentially as i = 1,…,N. Let [( Li (t ), U i (t )] denote the range of packet sequence numbers assigned to bucket i at any

given

time

t.

Since

packets

are

numbered

sequentially,

we

have

Li +1 (t ) = U i (t ) + 1, i = 1,..., N − 1 and U i (t ) − Li (t ) = S ∀i , where S is the constant bucket

size in terms of number packets. When a packet arrives at the edge server, its sequence number is tested with the bucket ranges to determine the bucket to which it belongs. If a bucket is thus determined, then the packet is inserted into it. If the sequence number of the arriving packet is less than L1 (t ) , then the packet has arrived too late; hence it is discarded. If the sequence number is greater than U N (t ) , then it has arrived too soon; in this case, the packet is saved in the pooled buffer that is not indexed. The buckets are streamed out of the edge server to the client in sequence. Accordingly, bucket 1 is streamed first. After its completion, the buckets are re-indexed as follows: current buckets 2,…, N are indexed as 1,…, N-1, and current bucket 1 is indexed as bucket N. As a result, its packet sequence number range is changed as follows: LN (t ) = U N −1 (t ) + 1 and U N (t ) = LN (t ) + S . When a bucket is streamed out, all packets currently available in the pooled buffer that belong to the newly designated bucket N are moved into the bucket. In this strategy, streaming is always carried out from

16

the bucket designated as 1 in each streaming step at constant intervals of time. This whole process follows a revolving scheme with a bucket streamed out from one end and a new bucket added at the other end within the same buffer space. The revolving indexed buffer can be implemented as a circular array of dynamically created linked lists, where each bucket is a linked list. An Index table is used to access and manage the linked lists. This is illustrated in Figure 5. The Pooled Buffer can be implemented as an ordered linked list. Note that the actual number of packets in a bucket at any given time is a random variable. Let bi (t ) ≤ S denote the actual number of packets stored in bucket i at time t. If the total buffer capacity at the edge server is M packets, then the number of packets stored in N

the indexed buffer at any point of time t is I (t) = ∑ b i (t ) and consequently, the i =1

maximum capacity available in the pooled buffer at time t is P (t) = M – I (t). The implementation of the indexed buffer and the pooled buffer as linked lists thus enables the maximum utilization of the available total buffer space. We develop the final thread in the edge server architecture, the Policy Manager, in the following discussion. N-1 N-2

N 1

2

1

2

N-1

N

Fig. 5. Implementation of the Revolving Indexed Buffer

Policy manager: The Policy Manager implements a retransmission-request policy and coordinates with other threads in securing missing packets in time from the remote server. The retransmission-request policy entails two decisions: what missing packets are

17

to be requested and when. The policy manager looks up the index table at regular intervals of time, makes these policy decisions and communicates them to the Requester thread that carries out the request. Each request may comprise of packets missing in several buckets. The strategy of this policy is to make requests that will be useful in securing truly missing packets. The objectives of a policy are threefold: (a) the policy should not create false alarms by requesting packets that may be still on their way, (b) the policy should not miss retransmission opportunities that can be truly useful and (c) the policy should avoid requests that may involve genuinely missing packets but could not be obtained in time for the next stage transmission to the client. In order to implement these criteria in a policy, the indexed buffer is classified into five zones as shown in Figure 6. First, the set of N buckets is classified into three basic zones: Active, Retransmission and Passive. Choosing a parameter A, let the sequence of buckets {1, ..., A} denote the active zone. Similarly, choosing a parameter P, let the sequence of buckets {P ,..., N } denote the passive zone. The sequence { A + 1, ..., P − 1} represents the retransmission zone. Whenever a retransmission request is made, only the missing packets in the NoInsertion Zone

1

Insertion Zone

A

Activ e Zone

P-1

RetransmissionZone

P

N

Passiv eZone

Fig. 6. Zone structure of the Indexed Buffer

retransmission zone will be requested. This is because, requesting for packets in the passive zone could create false alarms and requesting from the active zone may result in retransmitted packets arriving too late. When packets arrive, we employ an orthogonal identification of the same buffer space: the No-Insertion and Insertion zones as shown in Figure 6. If a packet belonging to a bucket in the No-Insertion zone, then it is discarded; otherwise it is inserted into the appropriate bucket. The reason for this is that the packet insertion thread should not be in contention for the buffer resources with the Transmitter. Otherwise, the expected steady throughput from the edge server to the client may be affected. Typically, the No-insertion zone is small, and would entail one or two buckets

18

at the head of the indexed buffer. Using these parametric settings, the policy manager initiates retransmission requests at constant interval of time, denoted as T. A detailed performance analysis of these parametric settings is reported in the next sections.

4. SYSTEM PARAMETERS AND PERFORMANCE METRICS We have carried out detailed analytical investigations and simulation studies on the proposed architecture. In this section, we summarize the system parameters and performance metrics employed in these studies. The different system parameters that influence the QoS performance could be broadly classified into two categories: exogenous and endogenous. Exogenous Parameters: These parameters are not under the control of either the application designer or run-time administrator. They pertain to the Internet environment in which remote streaming is carried out. In our models, we denote these parameters as follows: (a) Average network packet loss L, expressed as a percentage of the total number of packets transmitted from the remote server (b) End-to-end delay for any packet between the remote and edge servers expressed using a delay distribution D(µ, σ2). Endogenous Parameters: These are control variables that can be varied by the application designer within the constraints of the system resources to optimize streaming performance. Furthermore, a flexible implementation of the architecture would enable a run-time administrator to set the values of these parameters after assessing the exogenous parameters in any given streaming session. The endogenous variables are: Remote Server Streaming Rate (SRRS), Edge Server Memory Size (M), Bucket Size (S), Edge Server Streaming Rate (SRES), Time interval between retransmission requests (T), and Retransmission Range (RR). The parameter RR is number of buckets in the retransmission zone for which retransmission requests are actually sent for missing packets. Clearly, RR = P − A . Performance Metrics: The system performance is measured at two levels: client and edge server levels. The client level performance is indicative of the QoS received by the client. At the edge server level, we measure performance in terms of the usefulness of the retransmissions in improving the client-level QoS. Two metrics are used to assess clientlevel performance as follows: (a) QoS1 – the percentage of packets transmitted in time from edge server to client, and (b) QoS2 – the percentage of the Encoding Rate accomplished in the packet arrival rate realized at the client. Best quality in transmission is achieved when both QoS1 and QoS2 are close to 100%. At the edge server level, the

19

percentage of packets that were genuinely lost during the original transmission but were recovered in time through the retransmission scheme so that they can be delivered to the client before playout is a measure of the usefulness of retransmissions. This metric is indicated as γ. Best transmission efficiency is achieved when γ is close to 100 %.

5. IMPLEMENTATION A high-level integrated architecture of the proposed streaming mechanism is presented in pseudocode form below. This integrated view represents the coordination mechanisms between the remote and the edge servers that control the RTSP state and invoke other threads in the overall system architecture. The main control thread at the remote server is indicated as rs_control_interface() (refer to section 3.2 on remote server view of the architecture) and corresponding thread at the edge server as es_control_interface() (refer to section 3.3 on edge server view of the architecture)

rs_control_interface () /* rs_control_interface receives rtsp requests from the edge sever and maintains the rtsp state in the remote server accordingly */ BEGIN WHILE (status ≠ STOP) SWITCH(rtsp request) CASE setup: status = SETUP /* do a check if the request can be accepted*/ reply = check_client_admission_permit() IF (reply =1) /*assign port nos, allocate bandwidth*/ allocate_resources() ENDIF CASE play: status = PLAY /* start all the three threads binding them to their respective sockets*/ rs_app_out(startframe) rs_retran_in() rs_retran_out() CASE pause: status = PAUSE CASE teardown: status = STOP free_resources() ENDCASE ENDWHILE END

20

es_control_interface() /*es_control_interface receives rtsp requests from the client player and also acts as a proxy to remote requests, i.e. it passes requests from the client to the remote server, it maintains the rtsp state in the edge server */ BEGIN WHILE (status ≠ STOP) SWITCH(rtsp request) CASE setup: reply = check_client_admission_permit( ) remote_response=request_remote_server(status) IF (reply = ‘true’ AND remote_response = ‘true’) status = SETUP /* port numbers, bandwidth assigned */ allocate_resources() send_presentation_description() ELSE status = STOP send_response_to_client (“Unable to stream the requested movie”); ENDIF CASE play: status = PLAY /*send a rtsp play request to remote server */ request_remote_server(status) /*start all the four threads by binding them to their respective sockets */ es_app_out() es_app_in() es_retran_in() es_retran_out() CASE pause: status = PAUSE /* send a rtsp pause request to remote server*/ request_remote_server(status) CASE teardown: status = STOP /*send a rtsp teardown request to remote server*/ request_remote_server(status) free_resources() ENDCASE ENDWHILE END

6. PERFORMANCE MODELING In this section, we first develop a probabilistic analysis of the performance of the proposed streaming architecture. Next, we outline the simulation model developed to

21

evaluate performance empirically. The computational results from both the models are mutually consistent and are discussed in Section 7.

6.1 Probabilistic Performance Model The probabilistic performance model provides an analytical basis to evaluate the performance impacts of retransmissions on the overall quality of service. We begin the discussion by first considering the case without retransmissions. 6.1.1 Without Retransmissions. Without loss of generality consider a bucket with S data packets numbered packet 1, packet 2… packet S. At time t=0, the remote server begins the process of transmitting the packets in the bucket to the edge server. The streaming rate SRRS determines the elapsed time between the transmissions of consecutive packets. Let tRS (where tRS = 1/SRRS) denote the time between successive transmissions. Therefore, packet 1 is sent at time 0, packet 2 at time tRS, packet 3 at time 2tRS, and packet S at time (S-1)tRS. Let T denote the time at which packets in the bucket are assembled by the edge server and sent to the client. Some of the packets transmitted by the remote server may not be delivered to the client because of either packet losses or time delays in the transmission. Let p denote the probability that the packet is not lost in transmission. It follows that p = 1 − L

100

. The

packet delays are characterized by the delay distribution D with mean µ and variance σ2. Let F(t) denote the cumulative density function i.e. the probability that a packet will arrive by time t. The probability that ith packet will arrive by time T is given by F(T-(i1)tRS). Therefore, the probability that packet i will arrive by time T and is not lost is given by pF(T-(i-1)tRS). Thus, the number of packets from the bucket that are delivered to the S

p ∑ F ( T − (i − 1)t RS )

client is:

(1)

i =1

The quality of service metric QoS1 that denotes % of packets transmitted in time from edge server to client: S

p

QoS1 =

∑ F (T − (i − 1)t ) RS

i =1

× 100

(2)

S

6.1.2. With Retransmissions. We now consider the impact of requesting retransmissions. Let the retransmission time be R where R ≤ T. At time t=R, all packets from the bucket that have not yet arrived at the edge server will be requested for

22

retransmission. The request is sent back to the remote server, which will respond by resending the packets. For analytical convenience we will assume that the remote server will retransmit all the requested packets at the same time. Since the packets have already been compiled and assembled the first time there were sent, the remote server can seamlessly respond to retransmission requests. For expository purposes, we present three cases for the retransmission analysis. Case1: No packet delays, but there are packet losses.

Consider any packet i.

Probability that the packet does not arrive in the first transmission is (1-p). Similarly, the probability that the packet does not arrive in the retransmission is (1-p). Therefore the probability that the packet i will not be delivered to the client is (1-p) 2. It follows that QoS1 = (1 - (1-p) 2 )*100

(3)

The number of packets retransmitted will depend on R. When R ≥ (µ + (S–1)tRS), the expected number of packets retransmitted is (1-p)S. When R < µ the entire bucket S needs to retransmitted as no packet would have arrived at the retransmission time. Assuming R ≥ (µ + (S–1)tRS), the number of wasted packets i.e. the number of packets sent but not utilized is given by (S + Number of retransmission requests Number of packets delivered to client). This simplifies to Sp(1-p). Note that this is inversely related to the performance metric γ, which represents the percentage of retransmitted packets that are useful. Case2: Packet delays, but there are no packet losses. Consider packet 1. At the retransmission time R, the probability that the packet will not have arrived is 1 – F(R). This represents the probability that the packet will be requested for retransmission. If the packet is requested for retransmission then the probability that the re-transmitted packet will not arrive by time T is given by 1-F(T-R-µ). Similarly, the probability that the original packet will not arrive by time T is given by 1-F(T). Thus the probability that the packet 1 will not be delivered to the client is (1-F(T))(1-F(T-R-µ)). Generalizing, we obtain the probability that the packet i will be in the bucket sent to client as 1 - (1-F(T-(i1)tRS))( 1-F(T-R-µ)). Therefore, the number of packets delivered to the client is given by

∑ (1 − (1 − F (T − (i − 1)t S

i =1

RS

(

) ) (1 − F (T − R − µ )

) ) . This simplifies to S

SF (T − R − µ ) + (1 − F (T − R − µ ) ) ∑ F ( T − (i − 1)t RS ) i =1

23

(4)

S

Therefore, QoS1= (( SF (T − R − µ ) + (1 − F (T − R − µ ) ) ∑ F ( T − (i − 1)t RS )) *100) / S

(5)

i =1

Number of retransmission requests is

S

∑ (1 − F ( R − (i − 1)t ) ) RS

(6)

i =1

Number of packets that were streamed but not utilized is given by (S + Number of retransmission requests - Number of packets delivered to client) and can computed from the above expressions. Case3: Packet delays and losses. This represents the general case and can be compiled from the previous analysis. The number of packets delivered to the client can be computed as S

SpF (T − R − µ ) + (1 − pF (T − R − µ ) ) ∑ pF (T − (i − 1)t RS )

(7)

i =1

From the above we obtain, S

QoS1 = (( SpF (T − R − µ ) + (1 − pF (T − R − µ ) ) ∑ pF (T − (i − 1)t RS )) *100) / S

(8)

i =1

Number of retransmission requests is

S

∑ (1 − pF ( R − (i − 1)t ) ) RS

(9)

i =1

The above probabilistic model provides an analysis of retransmissions, and its impact on quality of service, number of retransmissions requested, and number of wasted packets.

6.2 System Simulation Model A simulation model of the streaming scenario with the proposed architecture has been developed using the popular discrete event simulation tool ARENA. Using extensive simulations of the scenario, the performance metrics of the proposed architecture have been assessed under various parametric settings. Simulation runs were conducted for twelve different combinations of network losses and delay distributions, varying the endogenous parameters among various levels in each combination. The endogenous parameters have been varied as follows: three levels of edge server memory size, three levels of number of buckets, three levels of retransmission intervals, two levels of interbucket delay and two levels of retransmission ranges. A completely randomized block design yielded 1296 independent simulations in total. The performance metrics are assessed in each simulation run. The simulation study has been conducted for the following purposes: (a) Comparison of QoS with/without retransmissions (b) Study the effects of endogenous control parameters on QoS with/without retransmissions under

24

various exogenous conditions (c) Study the effects of control parameters on the percentage of useful retransmissions realized at the edge server and (d) Obtain Calibration Curves (QoS1 Vs QoS2) for different exogenous network conditions that can be used by a run-time administrator to set appropriate values for the control parameters in a given streaming session.

7. PERFORMANCE RESULTS We discuss the results of the probabilistic performance model in Section 6.1 and the results of the system simulation model in Section 6.2 below. 7.1 Probabilistic Performance Model Results A detailed analysis of the probabilistic performance model has been conducted to provide analytical insights on the impact of retransmission choices on the quality of service and the overall usage of the network resources. Figure 7(a) depicts the impact of retransmission time on the performance metric QoS1. As expected, early and frequent retransmission requests result in substantial improvements in quality of service. An increase in the retransmission request time lowers the quality of service as increasing number of retransmitted packets arrive too late to be deliverable to the client. The ability of the retransmitted packets to enhance QoS is further elaborated in Figure 7(b). Initially, as the retransmission request time increases the percentage of useful packets also increase. This follows from the fact that too early a request can raise false alarms, and that packets that would arrive shortly are unnecessarily requested. Such false alarms can be avoided by increasing the retransmission request time. On the other hand, retransmission requests that are too delayed can result in a sharp drop in the percentage of useful packets delivered as they may arrive too late to be of use and waste critical bandwidth resources. These results clearly point to the importance of a careful management of retransmission policies to enhance the overall utilization of the resources. In the following discussion we present results from a detailed simulation study that would enable an administrator to fine-tune critical control parameters to achieve optimal overall performance, and to systematically leverage the resources to enhance the client’s QoS.

25

7.2 System Simulation Results The system simulations results are organized into three categories. The first one compares QoS with/without retransmissions and also the effects of varying different control parameters on QoS. The second category presents the effects of varying different parameters on the usefulness on retransmissions at the edge server and the third category a. Eff ect of Retransmissions on QoS1 Expo(15) Distribution, 20% Losses

b. Useful Retransmissions Expo(15) Distribution, 20% Losses 50 Percentage of Useful Retransmissions

100

Qos1

90

80

70

60

45 40 35 30 25 20 15 10 5 0

0

20 40 60 Retransmission Time

80

0

20 40 60 Retransmission Time

80

Fig. 7 a, b. Probabilistic Performance Model Curves.

synthesizes the results into a set of section is the calibration curves that have been obtained for different network conditions. Typical representative sets of results in each category are presented with a discussion and analysis on their behaviors below. Similar behaviors have been observed in all the simulation experiments. 7.2.1 Effects of control parameters on QoS. The effects of varying edge server memory on QoS are shown in Figure 8. As expected, both QoS1 and QoS2 increase as the edge server memory is increased. Furthermore, using retransmissions improves both QoS1 and QoS2 by nearly 10 %. The effects of varying number of buckets on QoS are shown in Figure 9. Both QoS1 and QoS2 decrease with increase in number of buckets. This is because, lesser the number of buckets, more time is allowed for a retransmitted packet to reach back to the edge server before the bucket is streamed out. Consequently, the utility of retransmissions improves, which impacts the QoS metrics at the client. The effects of the inter-bucket delay parameter on QoS are summarized in Table II. Increasing the inter-bucket delay decreases the streaming rate at the edge server. This is because, reducing the streaming rate implies allowing more time for a retransmitted packet to reach the edge server. Hence the percentage of packets that eventually reach the client in time (i.e. QoS1) also increases. Although QoS2 may be expected to decrease when the inter-bucket delay is increased, it shows a rise because of the increase in the

26

number of packets being streamed. As a result, the effective streaming rate at the edge server increases. This argument would also be strengthened by a consideration of the QoS metrics without retransmission. Though QoS1 increases with an increase in inter-bucket delay, in this case QoS2 decreases as the increase in QoS1 cannot compensate the a. Effect of Edge Server Memory Size on QoS1 Exp(1.5) Distribution, 20 % Losses

b. Effect of Edge Server Memory Size on QoS2 Exp(1.5) Distribution, 20 % Losses

100

94

95

92

600 400

90 200

88 600

400

200

QoS2

QoS1

85 80

600

400

90

75

200

86 84 82

70

80

65

78

60

76 0

200 400 600 Edge Server Memory

800

200 0

600

400

200 400 600 Edge Server Memory

800

With Retransmissions Without Retransmissions

With Retransmissions Without Retransmissions

Fig. 8a, b. Graph showing effect of varying edge server memory on QoS . b. Effect of varying No of Buckets on QoS2 Exp(1.5) Distribution, 20 % Losses 88

a. Effect of varying No of Buckets on QoS1 Exp(1.5) Distribution, 20 % Losses 87 5 85

5

84

83

8

81

QOS2

QoS1

86

10

79

5

77

10

10

10

5 8

76

75 5

8

80 78

8 0

82

15

No of Buckets

10

74 0

5 10 No of Buckets

With Retransmissions

With Retransmissions

Without Retransmissions

Without Retransmissions

15

Fig. 9 a, b. Graphs showing effect of varying number of buckets on QoS.

effects of reduced streaming rate. Finally, the effects of the retransmission request interval on QoS are summarized in Table III. As can be intuitively observed, the higher the frequency of retransmissions better is the QoS as more number of packets get requested and consequently, more packets can be delivered to the client in time.

27

7.2.2 Effects of control parameters on the usefulness of retransmissions. The usefulness of retransmissions is measured by the percentage of retransmitted packets that were not late and hence, were delivered to the client in time. These results are shown in Figure 10. Increasing the edge server memory increases the percentage of useful retransmissions, which is an intuitive result. Increasing the number of buckets decreases the effectiveness of retransmissions, as the buckets would be streamed out at a faster rate and there would be less time for a retransmitted packet to reach before it’s stream-out time. Similarly increasing the inter-bucket delay allows more time for retransmitted packets to reach the edge server, and hence, the effectiveness of retransmissions increases Table II. Effect of varying inter-bucket delay on QoS (Expo (1.5) Distribution, 20 % Loss, 8 Buckets, Bucket Size=50, 3 secs Retran Interval) Inter-Bucket

QoS1

QoS1

QoS2

QoS2

Delay (seconds)

(Without

(With

(Without

(With

Retransmissions)

Retransmissions)

Retransmissions)

Retransmissions)

50

79.23

88.60

77.00

88.35

55

79.57

95.30

75.63

93.20

Table III. Effect of varying retransmission interval on QOS (Expo (1.5) Distribution, 20 % Losses, Bucket Size=40, 5 Buckets) Retransmission Interval (seconds)

QoS1 (%)

QoS2 (%)

3 5 8

87.91 85.94 83.84

85.57 83.60 81.51

28

b. Effect of varying No of Buckets Expo(1.5) Distribution, 20 % Losses, Mem=200 Pkts,Retran Interval=5 sec 99 5 94 8

Percent of Useful Retransmissions

Percent of Useful Retransmissions

a. Effect of Edge Server Memory Size Expo(1.5) Distribution, 20 % Losses, 5 Buckets, Retran Interval=3 sec 96 600 400 95 94 93 92 91

200

90 0

200

400

600

10

89 84 79 74

800

0

5

c. Effect of varying Inter-bucket Delay Expo(1.5) Distribution, 20 % Losses, 8 Buckets, Mem=400 Pkts , Retran Interval=3 sec 100 55 98 96 94 92 90 88

50

86 48

50

54

15

d. Effect of varying Retrans Interval Exp(1.5) Distribution, 20 % Losses, Bucket Size =40 98 8 97 5 96 95 94 93 92 91

52

10

No of Buckets

Percent of Useful Retransmissions

Percent of Useful Retransmissions

Edge Server Memory

3

90

56

0

Inter-Bucket Delay

5 Retransmission Interval

10

Fig. 10 a-d. Graphs showing effect of varying different parameters on usefulness of retransmissions.

However, increasing the frequency of retransmissions although increases the number of packets that are requested for retransmission, it also reduces the percentage of useful retransmissions. 6.2.3 Calibration Curves:

The QoS calibration curves for the twelve sets of

exogenous parametric combinations (network losses and delay distributions) are presented in Figure 11. The calibration curves are obtained as follows. Note that QoS1 and QoS2 are two objectives that have to be simultaneously optimized. Further, for each combination of the exogenous parameters, a set of simulations where each simulation pertains to a set of endogenous variable settings has been carried out. By plotting the values of QoS1 and QoS2 from these simulations, the set of dominated endogenous control configurations are eliminated. To illustrate, a configuration ∆ is said to dominate another configuration Ω if both the following conditions hold: QoS1( ∆ ) ≥ QoS1(Ω ) and QoS 2( ∆ ) ≥ QoS 2(Ω ) . Figure 11 presents the nondominated frontier of endogenous control configurations in the bicriteria QoS1-QoS2 space obtained from this study. For

29

the sake of brevity, the exact details of the control parameter configurations for the points on the nondominated frontiers are not provided in this figure. The nondominated frontier presents the tradeoffs between the two objectives for a run-time administrator. An administrator could use the calibration curves in a given streaming situation as follows. First, the existing network traffic conditions in terms of expected losses and delay distribution can be assessed using network sniffers. Second, an appropriate calibration curve that best describes the network conditions is chosen. The curve thus chosen would provide a set of nondominated control parameter configurations for the prevalent network conditions. Next, based on the tradeoffs among these options, the administrator could choose an appropriate configuration for streaming. Modeling and analysis of such decision problems is considered in the multicriteria optimization literature and their application to the streaming parameter selection problem is suggested for future research. The major results of the system simulation studies can be summarized as follows: (a) using selective retransmissions choosing various endogenous parameters appropriately would yield definite improvements in the Quality of Service of the stream received at the client for general network conditions, (b) higher memory at the edge server yields better results, (c) less number of buckets yields higher QoS at the client, although the packets sent from the edge server are less sorted, (d) lower edge server streaming rates imply higher QoS albeit there is a threshold limit for this after which the quality starts dropping,(e) higher frequency of retransmission requests implies higher quality but there would be lot more wasted retransmissions, due to false alarms and potential late arrivals at the edge server, and finally, (f) the calibration curves can be effectively used by a streaming administrator to set appropriate values for the control parameters in a streaming session in order to optimize the QoS criteria subject to the prevalent network conditions. 7. CONCLUSION On-demand streaming from a remote location through an edge server in best-effort Internet continues to be challenging problem. We provide a comprehensive review and develop taxonomy of current methods to enhance the delivery quality of multimedia streaming. We extend the current state-of-the-art by developing a streaming architecture for pure on-demand unicast streaming of pre-encoded video from a remote location. We have designed component architectures of the remote streaming process. The architecture is presented using three views: an integrated view, a remote server view and an edge

30

server view. The architecture employs the existing standard streaming protocols: RTP/RTCP and RTSP. The proposed architecture employs a novel buffering mechanism at the edge server termed revolving indexed buffering and uses selective retransmissions of lost packets to optimize the eventual quality of service at the client. The revolving buffering architecture and selective retransmission strategies are the central concepts of this work. Extensive simulations to evaluate the proposed streaming, retransmission and buffer management policies have been carried out. We also provide a probabilistic model of the proposed streaming process that supports the simulation results. The results show that significant improvements in QoS can be achieved using the proposed buffering and retransmission concepts and they lead to viable and robust mechanisms for run-time optimization of system resources to maximize QoS in any remote streaming context. These mechanisms are presented in terms of a set of calibration curves on the QoS measures for a run-time administrator. They serve as valuable decision aids for edge server buffer allocation and management and thus have significant practical appeal. Several avenues of future research arise from this work. We have considered unicast streaming in this research. However, this poses a considerable load on available bandwidth, especially when it is limited. Therefore, employing application level multicasting could be a viable and efficient solution that could be used under bandwidthrestricted streaming scenarios. This area needs to be studied. Extensions to the proposed architecture under bandwidth constraints themselves are major avenues for future research. Furthermore, an interesting extension to this work would be QoS based SLA (Service Level Agreement) between a Content Provider (CP) and a Service Provider (SP) and also between Service Providers. The SLA would specify: (a) Resource allocation to a customer and (b) expected QoS. In real time, based on demand and network conditions, a SP could follow suitable strategies in accommodating requests, downgrading QoS, paying penalties where required in order to maximize its expected profit. Architectural issues, economics of the SLAs and run-time streaming control optimization under these conditions are important areas for further study. Another interesting extension would be to model and develop architectures for collaborative resource-sharing arrangements among different service providers where an SP could leverage certain resource availabilities and strategic positioning on the Internet to enable cost-effective QoS based streaming delivery. Such applications are quite promising in grid computing environments. We are currently researching some of these problems.

31

Expo(1.5) Distribution, 5% Loss

Expo(1.5) Distribution, 20% Loss 93.6

96.7

93.6

96.6

93.5

96.6

93.5 QoS2

QoS2

96.5 96.5 96.4 96.4

93.3 93.2

96.3

93.2

96.2 98.2

98.4

98.6 98.8 QoS1

99.0

93.1 95.0

99.2

95.5 QoS1

96.0

83.0

Expo(1.5) Distribution, 20% Loss 93.6

82.5

93.6

82.0

93.5

Expo(1.5) Distribution, 40% Loss

93.5 QoS2

81.5 QoS2

93.4 93.3

96.3

81.0 80.5

93.4 93.4 93.3

80.0

93.3

79.5

93.2

79.0 83.4

93.2

83.6

83.8

84.0

93.1 95.0

84.2

QoS1

95.5 QoS1

96.0

Expo(3) Distribution, 40% Loss

Expo(3.0) Distribution, 20% Loss

84.0

93.6 93.4

83.5

93.2

83.0 QoS2

93.0 QoS2

93.4

92.8 92.6

82.5 82.0

92.4 81.5

92.2 92.0 94.8

95.3 QoS1

95.8

32

81.0 83.4

83.6

83.8 QoS1

84.0

Unif(1,3) Distribution, 5% Loss

Unif(1,3) Distribution, 20% Loss 93.4

97.0

93.2 93.0 92.8

96.0

QoS2

QoS2

96.5

95.5

92.6 92.4 92.2

95.0

92.0 94.5 98.0

98.5

99.0

91.8 95.5

99.5

QoS1

Unif(1,3) Distribution, 40% Loss

95.6

QoS1

95.7

95.8

Unif(2,5) Distribution, 5% Loss

83.0

97.0

82.9 82.8

96.5

82.6

QoS2

QoS2

82.7 82.5 82.4

96.0 95.5

82.3 95.0

82.2 82.1 82.0 83.6

94.5 98.0

84.1 QoS1

Unif(2,5) Distribution, 40 % Loss

93.4

83.0

93.2

82.8

93.0

82.6 82.4 QoS2

92.8 QoS2

99.0 QoS1

Unif(2,5) Distribution, 20 % Loss

92.6 92.4 92.2

82.2 82.0 81.8 81.6

92.0

81.4

91.8

81.2

91.6 94.0

98.5

94.5

95.0 QoS1

95.5

81.0 83.6

96.0

84.1 QoS1

Fig. 11. Calibration curves for twelve combinations of network losses and delay.

33

99.5

REFERENCES 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.

Albanese, J. Blömer, J. Edmonds, M. Luby, And M. Sudan, “Priority encoding transmission,” IEEE Trans. Inform. Theory, vol. 42, pp. 1737–1744, Nov. 1996. Anjum, F. and Jain, R., “Performance of TCP over Lossy Upstream and Downstream Links with Link Level Retransmissions,” Proceedings of the IEEE International Conference on Networks (ICON’00) , 2000. Balkir, N. H. and Ozsoyoglu, G., “Delivering Presentations from Multimedia Servers,” Proceedings of the IEEE International Workshop on Multimedia DBMS, 1998. Bolot And T. Turletti, “Adaptive error control for packet video in the Internet,” Proc. IEEE Int. Conf. Image Processing (ICIP’96), pp. 25–28, Sept. 1996 Bouazizi, Imed And Gunes, Mesut, “Selective Proxy Caching for Robust Video Transmission over Lossy Networks.” In Special Session for Robust Video Transmission within the IEEE ITRE 2003, Newark, New Jersey, August 2003. Briceno, H. M., Gortler, S. and McMillan, L., “NAÏVE – Network Aware Internet Video Encoding,”, Proceedings of ACM Multimedia’99, Orlando, FL, pp. 251-260, October 1999. Conklin, G. J., Greenbaum, G. S., Lillevold, K. O., Lippman, A. F. and Reznik, Y. A., “Video Coding for Streaming Media Delivery on the Internet,” IEEE Transactions on Circuits and Systems for Video Technology, Vol. 11, No. 3, pp. 269-281, March 2001. Cuetos, P. D. and Ross, K. W., “Optimal Streaming of Layered Video: Joint Scheduling and Error Concealment,” Proceedings of ACM Multimedia’03, Berkeley, CA, pp. 55-64, November 2-8, 2003. Dempsey, Bert; Liebeherr, Jorg And Weaver, Alfred. “On Retransmission Based Error Control for Continuous Media Traffic in Packet-Switching Networks”, Computer Networks and ISDN Systems, 28(5):719--736, March 1996. Eleftheriadis And D. Anastassiou, “Meeting arbitrary QoS constraints using dynamic rate shaping of coded digital video,” in Proc. 5th Int.Workshop Network and Operating System Support for Digital Audio andVideo (NOSSDAV’95), Apr. 1995, pp. 95–106. Emir Mulabegovic, Dan Schonfeld, Ansari Rashid, “Lightweight Streaming Protocol (LSP)”, Multimedia’02, December 1-6, 2002, Juan-les-Pins, France. Fastforward Networks. (2000) Fast Forward networks’ broadcast overlay architecture. [Online]. Available: http://www.ffnet.com/pdfs/boa-whitepaper.pdf Feamster Nick, Hari Balakrishnan, “Packet loss recovery for streaming video”, Proceedings of 12th International Packet Video Workshop, April 2002 Fu, Yun And Vahdat, Amin, “Service Level Agreement Based Distributed Resource Allocation for Streaming Hosting Systems,” In Proceedings of the Seventh International Workshop on Web Caching and Content Distribution (WCW), August 2002 Girod, Horn, And Belzer, “Scalable video coding with multiscale motion compensation and unequal error protection,” in Proc. Symp. MultimediaCommunications and Video Coding, NY,1995 Hasegawa, T., Hasegawa, T., Kato, T. and Suzuki, K., “A Video Retrieval Protocol with Video Data Prefetch and Packet Retransmission Considering Play-out Dead Line,” Proceedings of the 1996 International Conference on Network Protocols (ICNP’96), 1996. Hemy, Hengartner, Steenkiste, And T. Gross, “MPEG system streams in best-effort networks,” Proc. IEEE Packet Video’99, Apr.1999. Hsiao, P., Kung, H. T., and Tan, K. S., “Video over TCP with Receiver-based Delay Control”, Proceedings of ACM NOSSDAV’01, Port Jefferson, NY, pp. 199-208, June 25-26, 2001. Kangasharju, J., Hartanto, F., Reisslein, M., and Ross, K. W., “Distributed Layered Encoded Video through Caches”, IEEE Transactions on Computers, Vol. 51, No. 6, pp. 622-636, June 2002. Karrer, R. and Gross, T., “Dynamic Handoff of Multimedia Streams,” Proceedings of ACM NOSSDAV’01, Port Jefferson, NY, pp. 125-133, June 25-26, 2001. Lee S. H. and Lee S., “Retransmission Scheme for MPEG Streams in Mission Critical Multimedia Applications,” Proceedings of the 24th EUROMICRO Conference, 1998. Li, Wu, And Zhang, “Study of a New Approach to Improve FGS Video Coding Efficiency,” ISO/IEC JTC1/SC29/WG11, MPEG99/M5583, Dec. 1999. Little, T. D. C., “A Framework for Synchronous Delivery of Time-dependent Multimedia Data,” ACM Multimedia Systems Journal, 1993. Li Xue , Sanjoy Paul, Mostafa Ammar, “Layered Video Multicast with Retransmissions (LVMR): Evaluation of Hierarchical Rate Control”, 1998 Loguinov, Dmitri And Radha, Hayder, “Retransmission Schemes for Streaming Internet Multimedia: Evaluation Model and Performance Analysis,” ACM SIGCOMM Computer Communication Review (CCR), vol. 32, no. 2, April 2002. Lu, Y. and Christensen, K. J., “Using Selective Discard to Improve Real-Time Video Quality on an Ethernet Local Area Network,” International Journal of Network Management, 1999.

34

27. Mccanne, V. Jacobson, And M. Vetterli, “Receiver-driven layered multicast,” in Proc. ACM SIGCOMM’96, Aug. 1996, pp. 117–130. 28. Miao And Ortega, “Proxy caching for efficient video services over the Internet,” in Proc. Packet Video’99, New York, Apr. 1999. 29. Mourad, “Doubly-striped disk mirroring: Reliable storage for video servers,” Multimedia, Tools and Applications., vol. 2, pp. 253–272, May 1996 30. Nitish M, Ramkumar J, Ramakrishna C, Lakshmi Priya Tks, “Design and Evaluation of Intermediate retransmission and Packet loss detection schemes for MPEG4 transmission.”, Proceedings of the International conference on Information technology: Coding and Computing (ITCC 2004) 31. Nonnenmacher, J., Biersack, E. W. and Towsley, D., “Parity-Based Loss recovery for Reliable Multicast transmission”, IEEE/ACM Transactions on Networking, August, 1998. 32. Papadopoulos, Christos And Parulkar, Gurudatta, “Retransmission-based error control for continuous media applications”, Proceedings of the Sixth International Workshop on Network and Operating System Support for Digital Audio and Video, pp. 5--12, 1996 33. Piecuch, Mike; French, Ken; Oprica, George And Claypool, Mark, “A Selective retransmission protocol for multimedia on the internet” In Proceedings of SPIE International Symposium on Multimedia Systems and Applications Boston, MA, USA November 5-8, 2000. 34. Puri, Ramchandran, Lee, And Bharghavan, “Application of FEC based multiple description coding to Internet video streaming and multicast,” in Proc. Packet VideoWorkshop, Cagliari, Sardinia, Italy, May 1–2, 2000. 35. Rejaie, R., Handley, M. and Estrin, D., “Quality Adaptation for Congestion Controlled Video Playback over the Internet,” Proceedings of ACM SIGCOMM’99, Cambridge, MA, 1999. 36. Rejaie Reza, Yu Haobo, Handley Mark, And Estrin Deborah. “Multimedia Proxy Caching for Quality Adaptive Streaming Applications in the Internet.” In Proceedings of the Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies 2000 (INFOCOM'00), TelAviv, Israel, pages 980-989, March 2000. 37. Rizzo, L., “pgmcc: a TCP-friendly single-rate multicast congestion control scheme,” proceedings of ACM SIGCOMM’00, Stockholm, Sweden, pp. 17-28, 2000. 38. Sen, Rexford, And Towsley, “Proxy prefix caching for multimedia streams,” Proc. IEEE INFOCOM’99, Mar. 1999. 39. Sinha Rishi , Christos Papadopoulos, “An adaptive multiple retransmission technique for continuous media streams”, NOSSDAV 04, June 16-18 2004, Cork, Ireland 40. Tan, W. T. and Zakhor, A., “Video Multicast Using Layered FEC and Scalable Compression,” IEEE Transactions on Circuits and Systems for Video Technology, March 2001. 41. Varadarajan, S., Ngo, H. Q. and Srivastava, J., “Error Spreading: A Perception-Driven Approach to Handling Error in Continuous Media Streaming,” IEEE/ACM Transactions on Networking, Vol. 10, No. 1, pp. 139-152, February 2002. 42. Wada Masahiro , “Selective recovery of video packet loss using error concealment,” IEEE Journal on Selected Areas in Communications, vol. 7, pp. 807-814, June 1989. 43. Wang, S.Y. and Bhargava, B., “Multi-pass Transmission Policy: An Effective method of transmitting large multimedia objects in the wide-area network,” Proceedings of the COMPSAC’97 – 21st International Computer Software and Applications Conference, 1997. 44. Wang, Orchard, And Reibman, “Multiple description image coding for noisy channels by pairing transform coefficients,”Proc. IEEE Workshop on Multimedia Signal Processing, June 1997. 45. Wu Dapeng, Hou Yiwei, Zhu Wenwu, Zhang Ya-Qin, Peha Jon, “Streaming Video over the internet: approaches and directions”, IEEE transactions on circuits and systems for video technology , vol 11, no 3 ,March 2001 46. Wu, Hou, Zhu, Lee,Chiang, Zhang, And Chao, “On end-to-end architecture for transporting MPEG4 video over the Internet,” IEEE Trans. Circuits Syst. Video Technol., Sept. 2000 47. Yamaguchi, M., Ito, K. and Takasaki, Y., “Packet loss detection scheme for retransmission-based realtime data transfer,” Proceedings of the IEEE 7th International Conference on Parallel and Distributed Systems: Workshops (ICPADS’00 Workshops), 2000. 48. Zimmermann, R., Fu, K., Nahata, N. and Shahabi, C., “Retransmission-based error control in a many-to-many client-server environment,” Proceedings of the ACM Multimedia Computing Networking Conference, Santa Clara, CA, January 2003. 49. Zink, M., Jonas, A., Griwodz, C. and Steinmetz, R., “LC-RTP(Loss Collection RTP): Reliability for Video Caching in the Internet,” Proceedings of the IEEE 7th International Conference on Parallel and Distributed Systems: Workshops (ICPADS’00 Workshops), 2000. 50. Zink Michael, Schmitt Jens, And Steinmetz Ralf. “Retransmission Scheduling in Layered Video Caches”. In Proceedings of IEEE International Conference on Communications 2002 (ICC 2002), New York, USA, pages 2474-2478. IEEE, April 2002. ISBN 0-7803-7400-2.

35