Active Adaptation by Program Delegation in Video on Demand

Active Adaptation by Program Delegation in Video on Demand Nancy Tran, Klara Nahrstedt Department of Computer Science University of Illinois at Urbana-Champaign, USA Email: n-tran1, [email protected]

Abstract

cessing powers. The only variability allowed is through changes in feedback values; the algorithm remains invariant. In the above passive approach, all programs used to control QoS are static because they can neither be moved dynamically to a remote location nor replaced. They are attached to their hosts (server or client) for the entire duration of the application. This absence of program mobility makes it very dicult for multimedia systems to support dynamic changes in QoS control policies and adaptation algorithms. Such changes are often required due to the time-dependent needs of an application which can best be served by switching to different protocols or dierent resource management policies. Accommodating these changes with a xed set of programs would require a forecast of many possible scenarios, which may not always be attainable. Even if the prediction is realizable, it may demand a huge amount of disk space to store the dierent combinations, while only a few of them are ever deployed for a given application at a given point in time. This may lead to a waste of disk space and complex applications that are likely hard to implement and maintain. In order to facilitate multimedia applications to timely adapt to their continuously changing environment and hence to QoS uctuations, this paper seeks to complement the passive data passing model with the active program passing model: active because programs can be dynamically launched, loaded and executed at a remote destination where computation is needed. Such programs are referred to as mobile programs or mobile agents [1]. Dispatching a program to another computer is known as remote delegation because the computational responsibility of the program is passed to another machine that carries out the actual execution. Exploiting program mobility to actively adapt to applications' QoS variations oers some notable advantages:

In order to realize a more exible structure and achieve a richer set of capabilities in the adaptive control of QoS for distributed multimedia systems, this paper seeks to complement the conventionally used passive data passing paradigm with the newer active program passing approach. By timely delegating and redelegating adaptation programs to encapsulate desired feedback control intelligence and data, a ne-grained, dynamic and customizable adaptation to quality of service variations becomes realizable. We describe an experimental prototype that utilizes the above active adaptation approach to regulate video ow for video on demand. Preliminary results show a viable system which has much greater exibility for adaptation than is traditionally possible, and exhibits a smooth, graceful improvement/degradation in perceptual QoS during speedup or slowdown.

1 INTRODUCTION Presently, many distributed multimedia systems adapt to their changing environments and quality of service (QoS) requirements by exchanging control and feedback data between servers and clients. For the most part, the nature of such data is passive, that is, they contain values representing the states of some pre-de ned variables and control parameters. The recipients of the data respond by executing a xed set of functions, implementing some xed adaptation algorithm. The problem here is that these functions are indiscriminately applied to all participating machines even though the latter may have dierent requirements. For example, upon receiving feedback on frame loss from its clients, a video server reacts by executing the same frame dropping algorithm across all clients, regardless of the dierence in their pro This work was supported by ARPA grant F30602-97-20121

 A ne-grained, dynamic customization of QoS con1

trol can be realized. Through delegation, a client can inject into the server, at any point in time, a mobile program containing speci c adaptation functions and algorithms, tailored to the client's processing capabilities and requirements. The program is then executed at the server, directly aecting the server's behavior towards the given client. This results in a exible structure where dierent clients can impose their preferred QoS control policies carried in dierent mobile programs. For example, in multicast applications using MPEG1 encoding, a group of clients may desire their server to adjust its frame sending rates, while another group of slower clients may prefer the server to send the I frames and discard the rest.

an on-demand feedback scheme, are developed for this purpose. The remainder of this paper is organized as follows. Section two compares with current VoD systems and overviews related researches. Section three describes the architectural components of an implementation of active adaptation in a VoD system. Section four explains our ow control logic. An active adaptation protocol is presented in section ve. Experiments and results follow in section six. Finally, the conclusions section includes a summary of advantages and future research directions.

2 Related Work

2.1 Adaptation

 Furthermore, existing QoS adaptation behavior can

be altered dynamically to respond to QoS variations in a continuously changing environment. Here, redelegation can be used: a new program, which incorporates an application's new control intelligence re ecting new requirements, can be delegated over to a remote site, replacing the current mobile program. This strategy permits a video receiver to

exibly introduce new control schemes to its sender at any time during the application, thereby achieving far greater adaptivity than is traditionally possible. Considering a ow control example, if during a video play, a client's CPU is so busy that the current rate control strategy is deemed to be inappropriate, the client may decide to switch to a frame dropping strategy by simply redelegating another suitable program.

Examples of distributed multimedia systems, which utilized adaptive QoS feedback control based on the passive data passing model, can be found in [2] and [3]. There, all feedback information are passive in the sense that they represent the values or states of some adaptation parameters and variables such as network state, frame loss rate and negative acknowledgment to signal packet loss. Our approach diers from the above in its dynamic deployment of active feedback programs and data to adaptively control QoS. The INRIA Video Conferencing System (IVS) [2] targeted their feedback control design towards multicast distribution of real time streams. At a receiver, the average frame loss experienced during a time period is measured and is used to derive the congestion level of the network for that period. This level represents the state of the network as perceived by a given receiver and is used as feedback data. Based on these individual feedback values, the source adjusts the output rate of its video coder when the number of receivers suering severe frame loss exceeds a percentage threshold. As a result, those destinations that are served by links with ample bandwidths will receive poor quality video just because the majority of the receivers in the multicast tree suer congestion and cannot absorb a high video transmission rate. We believe that the drawback of this scheme lies in the lack of exibility to dynamically accommodate the heterogeneous characteristics of receivers in a multicast group. If we could delegate to the server various active feedback programs which include dierent adaptation policies to control a video coder's eective output rates, then dierent subgroups of receivers in the multicast tree would receive images with dierent qualities, matching the characteristics of dierent subgroups. In Vosaic's adaptation algorithm [3], receivers send

The end result is that programs at the server no longer need to be xed. Instead, a server can utilize dynamically deployed adaptation programs to respond to its clients' diverse hardware/software processing requirements. These programs can be removed and replaced on an 'as needed' basis when they become obsolete. The objective of this paper is to exploit the mobility of programs in order to provide a richer set of adaptive capabilities to accommodate continuous QoS changes in distributed multimedia systems. Here, the concept of active adaptation breaks the mindset of traditional adaptation. Instead of sending feedback values, clients have the latitute of dynamically sending feedback programs, which encapsulate their desired QoS control logic and data. These programs, customized for individual clients' needs, replace the server's rigid set of QoS control functions. We will illustrate with a prototype how active adaptation can be applied to regulate video

ows in a video on demand (VoD) application. A ow control equation, an adaptation protocol, together with 2

passive feedback messages to the server. These messages contain values of adaptation parameters that indicate the frame loss rates: frames that are either lost in the network due to congestion or discarded by the receivers due to insucient local host processing power. The server adjusts its frame transmission rate based on a xed adaptation algorithm. As such, all clients are subject to the same algorithm which remains immutable until the server terminates. This rigidity greatly restricts adaptivity in heterogeneous distributed environments: it is not possible 1) to enact dierent control policies for dierent receivers, or 2) to make control policy changes at the server while it is executing. In contrast, our scheme oers greater exibility for customized adaptation by allowing individual receivers to specify their characteristics to individually in uence the server's behavior dynamically, without interfering upon other receivers' QoS demands. Similar to our objective of applying mobile programs to perform adaptation, the Krakatoa Chronicle [4] provides news-on-demand services on the World Wide Web through launching Java applets from the server to the clients. By executing locally at the receivers on behalf of the server, the applets can timely adapt to their local user preferences in personalizing the formatting and presentation of news articles. The purpose of applets dispatching is to move computations close to the clients in order to avoid trac generated by the exchange of control commands and acknowledgments. This type of server-initiated program dispatching ts well with the nature of the application where no feedback control mechanisms are required. However, its scope for adaptivity is limited to serve local user preferences [5] in the context of newspaper text delivery. No support for multimedia trac is provided. In contrast, this paper proposes a receiver-initiated adaptation scheme to satisfy feedback control requirements for the transport of video data.

The architecture proposed in [6] for packet and cellswitched networks supplies an interface which comprises a pool of pre-de ned network functions stored at intermediary nodes. These functions (e.g. Ethernet function, IP forwarding function) make up the core of available network protocols and services. To control how packets are processed, users can specify the identi ers of one or more functions in the packets together with desired parameter values. As packets traverse through the network, the selected functions are invoked and executed at network nodes. Consequently, dierent packets can induce dierent computations, permitting higher

exibility in user control. One major advantage with this approach lies in enabling incremental extension of network functions, thereby facilitating the deployment of new network services and protocols. However, the scope of exibility is still con ned within the set of available functions. Tennenhouse and Wetherall envisioned another kind of active networks [7], one that can aord greater degrees of exibility for customization in an objectoriented programming environment. Programs (classes and methods) are not restricted to be pre-de ned or preloaded. Rather, they can be timely tailored to speci c demands of applications, dynamically loaded into network nodes, and execute there. The concept of 'capsule' is introduced: a transport mechanism that allows data and programs to be bundled in the same packet and sent together. As capsules navigate through network nodes, the enclosed programs are loaded on the y, performing computations on data carried in the same packet. As a result, capsule programs provide the ability to dynamically modify the behavior and state of a network node. Furthermore, they can be saved in the node's storage for future use, building up a collection of highly customized and extensible services, ready to be invoked. The architecture in [7] also calls for an execution environment at each network node to support safe execution of program instructions.

2.2 Active Networks

2.3 Elastic Server

Today, mobile programs are not only deployed in endsystems as in [4] and our work, but also in intermediary network nodes. This results in recent emergence of novel network designs and architectures, known as 'active networks', a term coined by Tennenhouse and Wetherall in [7]. The traditional view of a router/switch as being a passive 'store and forward' machine is replaced by a highly exible engine, one that can dynamically accept and perform customized computations on various packets/cells according to individual applications' requirements. Examples of active networks can be found in [6] and [7].

Following a similar line of thoughts, but applied to support mobile program computing at end systems, another kind of execution environment can be found in [1]. There, Goldszmidt and Yemini proposed an elastic server, composed of an execution environment, a remote delegation protocol and a runtime environment. Figure 1 shows the layout of these environments in an elastic server. Since our active adaptation system is built on top of this server, in the following paragraphs, we will give a brief overview of its architectural components. Further details can be found in [1]. 3

SERVER

Program Threads

MACHINE

Video Senders

Elastic Server

Adaptation Threads

CLIENT MACHINE Adaptation Program

IPC

IPC

... Execution Environment an Elastic Process

...

Video Server

Runtime Environment

Elastic Server

TCP / UDP IP

Network Subsystem & Operating System

Delegator

Video Receiver TCP / UDP IP

Operating System

Operating System

Program & Control Command Transport

Figure 1: Environment Layout of an Elastic Server

Video Data / Control Data Transport

Figure 2: Architecture of a VoD System with Active Adaptation

 The execution environment is used to support on-

demand loading and execution of all mobile programs. It is an application-layer process, known as 'elastic process'. It is elastic because its contents can expand or shrink depending on the volume of Figure 2 depicts the overall architecture of our design. mobile programs that are delegated by other ex- It follows a client/server structure and is composed of ternal processes. Delegated programs can execute two systems. as threads in the address space of the elastic pro A video on demand system to perform basic core cess. One bene t of using threads is to reduce video functions: video retrieval, transmission, recontext switching overhead, allowing the process ception, storage and playback. For each senderto be more scalable. Con ning programs execution receiver pair, a TCP connection is established to in the environment protects external resources from transfer control information such as 'start' or 'stop' tampering attempts. Authentication of delegators movie, and movie attributes for buer initialization is also possible. and display preparation. A separate UDP channel is engaged to transport video images. For each video client (receiver), the video server  The transport, execution and control of mobile prospawns a separate process, referred to as video grams are achieved through a set of services known sender. Both the sender and the receiver are reas 'remote delegation protocol'. This protocol insponsible for monitoring their own activities becludes: 1) dispatch, load and unload a mobile prosides performing the above mentioned core video gram to/from an elastic process; 2) instantiate a handling functions. program thread and schedule it for execution; 3)  An active adaptation system which comprises 1) remotely control thread execution through coma delegator process at each client machine and 2) mands such as start, suspend, resume and termian elastic server at the server machine. Threads, nate. instantiated from delegated adaptation programs, execute in the elastic server. Interprocess communication (IPC) in the same machine between com The runtime environment contains software strucponents of the VoD system and the adaptation systures to support the above remote delegation protem is achieved through shared memory. tocol. It is built on top of the host operating system. Its main functions are to provide: a network We follow a receiver-initiated adaptation approach. It protocol for communication between remote pro- is drawn from a design principle for the IETF's Resource cesses, a repository for programs storage and re- Reservation Protocol (RSVP) [11] although in this patrieval, a program manager and a thread scheduler per, we do not use reservations. Each receiver is responto control thread execution. sible for specifying its processing and QoS requirements,

3 Architecture

4

based on its hardware/software processing capabilities, constraints and workload. These speci cations can then be placed in an adaptation program, delegated over to the server machine. As such, the server can adapt differently for dierent clients by executing dierent adaptation programs. In the following two sections, we will describe the delegator and the adaptation programs.

DELEGATOR (Client Machine)

ELASTIC SERVER (Server Machine)

1

Open connection

Program 2

3.1 Delegator

3

The delegator is a process forked by the video client upon startup. It is responsible for maintaining communication with the elastic server to handle remote delegation requests. We consider two types of delegation.  Initial delegation of a program X which encapsulates initial adaptation policy, equations and/or data, tailored to a client's needs, resulting in a negrained, customized adaptation.  Redelegation which replaces program X with program Y. The objective is to free a client from being tied down to a xed adaptation policy. Program Y may contain a dierent policy, algorithm and data. For example, suppose a MPEG1 video session starts out with a rate control policy to regulate video ow. However, when it experiences high workload, it might want to switch to the policy of dropping all B frames. Contrasting with the traditional passive data passing model, the latter is not

exible enough to support such dynamic adaptation requirements. To accomplish initial delegation and redelegation, two procedures are devised: the remote delegation procedure and the redelegation procedure.

Dispatch & load

Bypassed -- successful program loading assumed

ÏÏÏ ÏÏÏ ÏÏÏ ÏÏÏ

'Start thread' command 4

create & execute thread thread

Figure 3: Remote Delegation Procedure The procedural steps above are illustrated in gure 3. For simplicity, we assume that old program copies do not exist in the elastic server. Following is a sample C code fragment which shows how to accomplish remote delegation. It invokes remote delegation service routines provided by the SOS1 server, an implementation of an elastic server by Systems Management ARTS Inc. /* Initialize return code & program name */ int rc; char *program_name = ``/library/programX'' /* 1. Open connection */ rd_party_server_open(0, &SOS_handle, SOS_server_address, timeout_value);

3.1.1 Remote Delegation Procedure

/* 2. Dispatch and load program */ rc = rd_server_program_load(SOS_handle, &programX_handle, NULL, program_name);

1. Before the rst delegation begins, the delegator opens a connection with the elastic server. Once the connection is established, all subsequent delegation requests can bypass this step. 2. The delegator issues a request to dispatch and to load a program into the elastic server. 3. If program loading fails because an old program of the same name already exists in the elastic server, there are two options. The video receiver can either use the existing copy, saving delegation overhead, or request to unload the old copy and to reload the program. The latter option ensures possible new modi cations be picked up. 4. The delegator issues a start thread command to instantiate a thread and to start its execution.

/* 3. If old copy exists, unload old copy and reload programX */ if (rc == EXISTS) { rd_program_unload(programX_handle); rc = rd_server_program_load(SOS_handle, &programX_handle,NULL, program_name);} /* 4. Create thread and start its execution; parameters are passed in arg_vector */ if (rc == 0) rd_thread_start(&thread_handle, NULL, programX_handle, arg_vector); 1

5

Systems Management ARTS Operational Server

The code above uses three handles to identify and locate objects: SOS handle, programX handle and thread handle. They are used by all subsequent remote control commands to represent the SOS server, programX and its associated thread respectively.

SERVER MACHINE AdaptationĆ thread X Sender 1

IPC

Delegator 1 Program X implements policy X

CLIENT 1'S MACHINE

3.1.2 Redelegation Procedure To replace the currently delegated program, the delegator requests the elastic server to terminate the execution of the associated thread, and remove the program. It then delegates another program and starts its execution. Following is an implementation of the redelegation procedure, again invoking the SOS library routines.

Adaptation thread Y Sender 2 IPC

VIDEO SERVER

int rc; char *program_name = ``/library/programY''

Delegator 2 Program Y implements policy Y

CLIENT 2'S MACHINE

ELASTIC SERVER

Figure 4: 2 Dierent Clients, 2 Dierent Programs

/* Stop current delegated program */ rd_thread_terminate(thread_handle);

the programs in an interpretive language which do not require compilation but take longer to execute. Consequently, in our prototype, we experiment with precompiled programs only. A sample adaptation program, which includes a ow control equation, will be presented in the next section.

/* Remove old copy */ rd_program_unload(programX_handle); /* Load new program */ rc = rd_server_program_load(SOShandle, &programY_handle, NULL, program_name);

4 Flow Control at End Systems

/* Create & start thread execution */ if (rc == 0) rd_thread_start(&thread_handle, NULL, programY_handle, arg_vector);

To demonstrate how program delegation can be applied to adaptively control QoS in distributed multimedia systems, we build a prototype to address the issue of regulating video ow between end systems of a VoD application. In particular, we focus on the frame loss problem which arises when there is a mismatch in processing capabilities between a video server and its clients. One way to resolve this mismatch would be:

3.2 Adaptation Programs

In contrast to feedback data which carry values used to notify state changes or the occurrence of an event that needs attention, adaptation programs are vehicles through which clients can specify a combination of control policies, algorithms, equations, executed by the server to handle the event. In short, clients can actively participate in the formulation of their server's QoS control logic to timely suit their processing needs and capabilities. Changes in state values can be either embedded in the programs or passed in as program arguments. Figure 4 illustrates the delegation of two dierent programs initiated by two dierent clients, implementing two dierent control policies. The ideal level of exibility would be to have adaptation programs composed and compiled on the y. However, given the current state of technologies, this would signi cantly lengthen the time to perform program delegation, making it unacceptably slow to handle real-time data. Equally problematic is the alternative of writing

1. to assess the processing capabilities of participating machines. This is the subject of an upcoming discussion on processing state metrics; 2. to have a policy that determines how the mismatch can be handled. One such policy is to slow down the frame sending rates based on the processing state metrics. An analysis on the magnitude of slowdown will follow the discussion on processing state metrics. In the process, a slowdown equation is derived. Our strategy for active adaptation is to encapsulate this equation in an adaptation program, which is later delegated to the sender for execution in order to control its frame sending rates. 6

4.1 Scope & Assumptions

clude the possibilities of network congestion or failure, frame loss is very likely caused by the inability of a receiver to keep pace with the source transmission rate. Once the local network subsystem buers are lled up, all subsequent frame arrivals are dropped.  Receiver wait time (RWT) is used to measure frame arrival delay. It represents the time interval during which a receiver idly waits for a frame to arrive. Long delays indicate frame starvation. Within the con nes of our assumptions, such delays must be caused by excessive dampening of video ow at the source. Here, we have a reverse situation where the receiver works faster than the server. This symptom usually appears when local resources are released upon the completion of tasks in the receiver's workload. As for the video sender, the only metric maintained is the sender's frame processing time (SFPT). SFPT, a counterpart of RFPT, includes: 1) frame retrieval time from a storage medium, 2) frame transmission time, 3) frame processing overhead and 4) sender inter-dispatch time during which a sender must wait for other senders before it regains control of the CPU. This time increases with the number of senders.

Because UDP/IP does not engage end-to-end ow control, a mismatch in processing capabilities between a server and its slow (relative to the server) receivers can cause severe frame loss, leading to serious degradation in perceptual quality of service. A machine's processing power, memory size and workload can all contribute to its slowness. To investigate the impact of processing capabilities alone, at end systems, we concentrate on solving the frame loss problem raised by a receiver' local inability to cope with high frame rates. Frame loss caused by congestion at network nodes or other network related problems is not studied. As a result, for a given video session, delays introduced by the underlying network are assumed to be almost unchanged. Also, the server is assumed to have sucient capacity to handle its clients' requests. A server's inability to absorb its clients' demands should be viewed as an admission control problem and not ow control. As for handling dierent types of video encoding, only MPEG1 encoded videos are considered although our architecture and adaptation protocol are general enough to handle other frame-based encoding schemes such as MJPEG and H.263.

4.2 Processing State Metrics

4.3 Analysis of Sender Slowdown

The processing capabilities of a frame-based video sender and receiver can be assessed by their frame processing times because they capture the video application's characteristics, hardware and software requirements. The receiver's frame processing time (RFPT) bundles together: 1) frame reception time during which one compressed frame is retrieved from the network subsystem's buers and stored in the video application's buers. Its duration varies directly with the compressed image size; 2) frame decode and display time; 3) frame processing overhead to account for monitoring and statistics collection activities; 4) receiver interdispatch time during which the receiver has to wait for other tasks to complete before its gets re-dispatched. This waiting time can be large when the workload is heavy (e.g. presence of CPU-intensive jobs). Operating system overhead such as scheduling is included in this component. The processing state of a receiver is monitored through three metrics.  RFPT is intended to estimate local processing capabilities.  Number of lost frames is used to detect losses beyond some threshold. Since our assumptions pre-

By how much should a video sender slow down or speed up in order to synchronize with its receiver's processing pace? Ideally, a frame should not arrive too early nor too late, but close to the moment when the receiver is ready to process a new frame. That is, the time taken by a receiver to wait (RWT) for a frame to arrive should be almost zero. If RWT ' 0, there will not be frame starvation. Let us consider the total cycle time, T, spent in processing one frame at both the sender and the receiver. Part a) of gure 5 shows the components of a normal cycle T. It is composed of SFPT, ND (network delay), RWT (receiver wait time) and RFPT. ND includes propagation, queuing and processing delays at various network nodes on the path from source to destination. Part b) illustrates an ideal cycle T where RWT = 0. On timeline 1, assuming the cycle starts at t0 = 0 and ends at t3 , the total cycle time is: T = t3 = SFPT1 + ND1 + RFPT1

(1)

At t3 , the receiver is re-dispatched and is ready to process another frame. It would be ideal if, at t3 , a new frame has just arrived. This situation is illustrated by the oblique segment joining timelines 1 and 2 at M . On 7

SFPT

ND

RWT

4.4 Window-Based Local Averages

RFPT

Because it is prohibitively expensive to store and transmit the RFPT's of every frame, averages can be used to obtain estimates. However, one must be cautious in RWT + 0 Timeline 1 SFPT ND RFPT choosing the length of the interval over which averages t t t t +0 are computed. In particular, the traditional global averaging method can generate long intervals that could Timeline 2 cancel out temporal uctuations, yielding poor estiSFPT ND RFPT M mates. A brief discussion on global averaging can be t t +t found in [8]. b) Ideal cycle : T = SFPT + ND + RFPT To capture temporal characteristics of time-sensitive data, we propose obtaining local averages through a Figure 5: Computation of Sender Slowdown moving window. This window con nes the averaging interval over which sampled values are accumulated and averaged. It moves forward as time progresses, replacing old samples with new values on a FIFO basis. This window motion reduces cancellation eect. We only use a single window to record all the processing times. Currently, window sizes are chosen. Further intimeline 2, let tx be the time when the source is ready vestigationarbitrary on setting the length of an averaging interval to start a new cycle. By moving backwards (right to is warranted. left) from M, tx can be computed: Due to MPEG1 frame encoding dependencies, the different types of frames (I, P, B) have large dierences in tx = t3 ? SFPT2 ? ND2 their processing requirements. As a result, RFPT are accumulated according to their frame types and averSubstituting t3 with equation 1, ages are computed for each type. tx = (SFPT1 + RFPT1 ? SFPT2 ) + (ND1 ? ND2 ) (2) a) Normal cycle : T = SFPT + ND + RWT + RFPT

1

2

x

1

1

1

0

2

2

3 * SFPT 2 * ND 2

3

2

3

Returning to timeline 1, suppose the sender has just 4.5 Flow Control Adaptation Pro nished processing a frame. In order for this frame to gram arrive at the receiver at t3 , the sender should slow down by: tx ? t0 ? SFPT1 . Substituting tx with equation 2 The slowdown equation (4) is, in essence, our ow conand t0 with 0, trol logic. There are two approaches to transfer the slowdown = (RFPT1 ? SFPT2 ) + (ND1 ? ND2 ) (3) RFPT's used in this equation: either embedded in the program, or separately as program arguments. Because The rst part of equation 3 shows the impact of pro- RFPT's are simple values, we adopt the second apcessing capabilities and the latter part, the impact of the proach for performance reasons. More details on the network. Because of our earlier assumptions of constant rationale are provided shortly in the next section. But network delays, ND1 ? ND2 ' 0. In addition, without rst, a sample C pseudocode for the program: loss of generality, subscripts 1 and 2 in the equation can be renamed as current and future respectively. Init_interprocessComm_with_sender(); slowdown = (RFPTcurrent ? SFPTfuture )

(4)

Do until_end_of_video { RFPT = obtain_RFPT_average(); SFPT = obtain_SFPT(); slowdown = RFPT - SFPT; if (slowdown > 0) sleep(slowdown); signal_sender(); wait_till_sender_signalback();

The values of SFPTfuture can be predicted by utilizing the latest histories of sender processing times. If the result of the slowdown equation is > 0, the source must sleep by this amount. A negative value is a possible indicator that the server is overloaded. This is a necessary but not a sucient condition for detecting server overload.

} 8

⊗

Program Process frame

⊗ UDP

⊗

Wait for frame

⊗

Process frame

Dispatch & Load program

TCP Load program

⊗

ÏÏÏ ÏÏÏ ÏÏÏ

⊗ Send 'start thread'

Command

⊗

Wait for ACK/ ⊗ timeout

Send ACK

Create & execute thread

TCP

⊗

TCP

ELASTIC SERVER

L

L ⊗

Wait

⊗

⊗

Wait

DELEGATOR

Figure 7: Delegation Phase

Signal endof-learning

TCP

SENDER

ure 6 delineates the interactions between a sender and its receiver in their collaboration to learn frame processing times. For every processed frame, SFPT and RFPT are measured and accumulated at the sender and receiver respectively. To ensure that SFPT and RFPT's preliminary values are gathered for all frame types (I, P, B), the learning phase continues until a few complete groups 2 of MPEG1 images are received. At the end of the phase, the receiver computes averages for the values collected. An end-of-learning message is then transmitted to the sender, requesting it to wait for further noti cation from the yet-to-be-created adaptation thread.

RECEIVER

Figure 6: Learning Phase

5 Adaptation Protocol For each video sender-receiver pair, there is a delegatoradaptation program/thread pair (see gure 2). The adaptation protocol orchestrates interactions between these four entities. It has four phases: learning, delegation, adaptation and re-adaptation. Here, the principle of conservation [9] is applied to control video ow. I.e., a new frame is not sent out to the network until an old frame is processed by the receiver. This leads to two requirements: 1) at startup, a receiver must attempt to reach stable state. Attempts to meet this requirement are made at the learning phase; 2) once stability is reached, it must be maintained because of possible changes in the receiver's operating environment (e.g. workload changes). The re-adaptation phase is responsible for satisfying this condition.

5.2 Delegation Phase

Upon completion of the learning phase, the receiver transfers control to the delegator. Figure 7 shows the collaboration between the delegator and the elastic server to deploy mobile programs. Here, the remote delegation procedure outlined in 3.1.1 is applied. The delegator dynamically dispatches and loads a pre-compiled adaptation program. Subsequently, program execution is initiated through the 'start thread' command. The 5.1 Learning Phase RFPT averages, computed at the learning phase, are Conditioning the adaptation program with preliminary piggy-backed in the command. At the end, the delegaassessments of the SFPT and RFPT averages consti- tor waits for further noti cation from the receiver. tutes the learning phase. In an attempt to keep this phase short and yet, be able to acquire reliable statistics to re ect the true states of the participants, UDP 5.3 Adaptation Phase with simple acknowledgment is employed. Unreliable Once active, the adaptation thread (agent) regulates transmission provided by UDP alone is inadequate be- video by looping through a handshaking procedure cause it can lead to frame loss, distorting the very rst ( gure ow 8) for every frame. First, the agent signals the RFPT and SFPT values, thereby making subsequent sender and waits. Then the sender processes one frame, adaptation erroneous and dicult. writes the SFPT value in shared memory, signals back In general, the acknowledgment scheme works as fol- the agent and waits. Finally, the agent resumes, relows. The source sends one frame via UDP. It then waits trieves SFPT and computes slowdown. If the slowdown until an acknowledgment is received or a timeout period 2 A complete group is a sequence of images enclosed within has expired. In the latter case, it will resend the image. The receiver uses TCP to return acknowledgment. Fig- two I frames, excluding the last I (e.g. IBBPBBPBBI). 9

⊗ Signal

Resume Process frame

sender

⊗

⊗ Wait

⊗ ⊗ ⊗

Write data ⊗ Signal

⊗

Wait

⊗

Wait ⊗ RFPTs

SFPT

Resume ⊗ Get data ⊗ Resume

⊗

Detect threshold violation

⊗

Write data

⊗

Signal

⊗

Wait

⊗

Resume

⊗

Transmit data ⊗

⊗ Get data

SHARED MEMORY

SENDER

Signal ⊗

⊗ Continue

execution

Receive data ⊗ Continue execution

ADAPTATION THREAD

Figure 8: Adaptation Phase

TCP Wait ⊗

⊗

ADAPTATION THREAD

SHARED MEMORY DELEGATOR

RECEIVER

Figure 9: Re-adaptation { Feedback on Demand is > 0, it will sleep, thereby forcing the sender to stay idle.

5.4 Re-adaptation Phase

The objective of this phase is to maintain stability. If the SFPTs, RFPTs and the slowdown equation are correct, the resulting ow regulation should create a condition of equilibrium at the receiver. As long as there are no perturbation in the receiver's workload, no dramatic differences in video scenes contents and our assumptions remain valid, this equilibrium will last until the video ends.

5.4.1 Causes for Disequilibrium However, when a receiver is subject to workload variations, its local processing capabilities will change in proportion to the intensity of its workload. Such changes can destroy stability, leading either to possibly severe frame loss or frame starvation. Workload uctuations can assume two directions producing opposite outcomes. 1. An increase in workload intensity reduces the receiver's processing capabilities. The competition for resources among tasks in the workload causes RFPTs to increase, thereby creating an unbalanced condition in which the sender transmits faster than the receiver. As a result, frame loss re-occurs. 2. A decrease in workload intensity increases the receiver's processing capabilities. Typically, such situation arises upon tasks' completion. Resources released by the completed tasks are made available to the receiver, shortening its RFPTs. Meanwhile, at the source, the adaptation agent continues to use old RFPT values. This creates a reversal in

which the receiver works faster than the sender. As a result, frame delay occurs. To restore equilibrium, the adaptation agent must be advised of the RFPT changes and re-adapt to these new changes so that the correct amount of slowdown can be re-instated. To this end, we adopt a feedback on demand approach.

5.4.2 Feedback on Demand We consider two equilibrium indicators: frameloss and frame delay. When either one exceeds its own threshold, feedback statistics are evaluated. These statistics consist of RFPT averages calculated over all values stored in the moving window. Upon writing them to shared memory, the receiver signals the delegator that feedback data are available. The delegator resumes, obtains the data and forwards them to the adaptation thread via TCP. It then signals the receiver and waits for the next feedback event. At the remote end, the adaptation thread gets the data and continues execution. If the new slowdown is smaller, frame transmission is accelerated. If it is larger, video ow is further decelerated. In our current prototype, it turns out that the adaptation program is simple. It merely computes the slowdown/speedup of a sender's frame rates. It is not necessary to modify the program to accommodate changing processing capabilities. As a result, we can just send feedback values which consist of three simple RFPT averages, one for each MPEG1 frame type. However, one prominent feature of our model that distinguishes from traditional adaptation schemes is the provision of an environment that supports sending feedback programs for re-adaptation. In particular, the re-

10

Recording Rate 30 fps Resolution 352 x 288 pixels Length 815 frames Frame Encoding Pattern I B B P B B

1 Client 2 Clients 3 Clients (secs) (secs) (secs) Learning [6.34?7.23] [6.34?7.37] [6.60?7.69] Delegation [1.53?2.72] [1.85?2.71] [2.41?3.46]

Table 1: Video Attributes

Table 3: Initial Costs (Learning & Delegation)

Frame Loss Threshold 10% Frame Delay Threshold 30 msecs RFPT Window size 10 groups RFPT Winsize Rate of Change 10% Threshold Table 2: Thresholds & RFPT Window Size delegation procedure presented in 3.1.2 is designed for this purpose. To respond to new requirements of a changing operating environment at the receiver, new control logic3 and algorithms, together with simple or complex feedback data values, can all be enclosed in a new program. This program, in turn, is redelegated to the server through the redelegation procedure to replace the existing, but obsolete, adaptation program. In effect, a dierent adaptation strategy is established on the

y as needs arise. Experimenting with the redelegation of feedback programs will be our future work.

6 Experiments & Results Experiments are conducted on a cluster of four Sparc IPX workstations running Solaris 5.5.1 and connected to a 10 Mbps Ethernet LAN. The VoD system is built using XIL [10] toolkit. The active adaptation system invokes delegation services provided by the SOS server. One workstation is dedicated to the video server and the SOS server, the rest are for video clients. To test the ability to capture various processing capabilities and adapt to their changes, we vary the workload of a designated client machine { mercury.cs.uiuc.edu by introducing a CPU-intensive job. All measurements reported in this paper are obtained from this machine. When the workload consists of only a video application, the client is said to be unloaded. Adding other tasks to the workload produces a loaded client.

gage a high quality MPEG1 video, recorded at 30 frames per second (fps). Major attributes of interest are listed in table 1. Adaptation thresholds and RFPT window size are given in table 2. Feedback for frame transmission slowdown is triggered when frame loss exceeds 10% of the total number of frames in the RFPT window. As for speedup, we use the frame delay threshold. It is set at 30 msecs instead of the standard end-to-end delay of 100 msecs because our experiments are con ned within a single LAN. However, experiments show that frame delay threshold alone is not sucient to help determine the cause for frame starvation. In fact, delays in frame arrivals can be due to either network delay or excessive ow control as a result of reductions in workload intensity. Hence, we additionally calculate the rate of change in the size of the RFPT window: (new winsize ? old winsize)=old winsize. This computation is performed every 10 complete groups of frames. If the result is negative and exceeds its threshold , then frame delay is most likely due to a decrease in workload intensity and feedback for speedup is requested. This additional threshold is crucial in determining speedup so that the receiver can make use of resources released by recently completed tasks.

6.2 Initial Costs

Overheads incurred in the learning phase and the delegation phase at a client are given in table 3. These numbers are obtained for 10 sample runs. Depending on the number of clients served, the learning phase lasts from about 6.3 to 7.7 seconds and the delegation phase from 1.5 to 3.5 seconds. Although the learning period is seemingly long, users hardly perceive the delay because frames are displayed while their processing times are collected. This is in contrast with protocols that require users to wait for a large buer to ll up before the rst frame is displayed [3]. However, frames arrive 6.1 Performance Metrics slower because, during learning, acknowledgment is enWe measure frame loss and frame processing rates of the gaged. In total, 13 frames are processed. They belong designated client for the entire video. Experiments en- to roughly 2 complete groups plus one I frame. There3 An example would be to change the slowdown computation fore, the average frame processing rate in this phase method. ranges from around 1.6 (13/7.7) to 2 (13/6.3) fps. 11

CLIENT UNLOADED

9 8

2

7 Number of Lost Frames

Number of Lost Frames

1.5

1

6 5 4 3

0.5

2 x : Speedup

1 0