RC 20734 (2/20/97) Computer Science
IBM Research Report Efficient Retrieval of Composite Multimedia Objects in the JINSIL Distributed System Junehwa Song, Asit Dan, Dinkar Sitaram IBM Research Division T.J. Watson Research Center Yorktown Heights, New York
Limited Distribution Notice This report has been submitted for publication outside of IBM and will probably be copyrighted if accepted for publication. It has been issued as a Research Report for early dissemination of its contents. In view of the transfer of copyright to the outside publisher, its distribution outside of IBM prior to publication should be limited to peer communications and specific requests. After outside publication, requests should be filled only by reprints or legally obtained copies of the article (e.g., payment of royalties).
IBM
IBM Research Division Almaden T.J. Watson Tokyo Zurich
Efficient Retrieval of Composite Multimedia Objects in the JINSIL Distributed System Junehwa Song, Asit Dan and Dinkar Sitaram IBM T. J. Watson Research Center Yorktown Heights, NY 10598 fjunesong, asit, sitaram
[email protected] The paper will appear in the Proc. of the ACM SIGMETRICS Conference, June 1997.
Abstract
2 1
Semi−Final Global view
10
60
80
Swimmer Swimmer 2 1
3
Seim−final statistics
4
Maximum BW
Available BW
Final Global View
95
140
Time (sec)
155
The rapid evolution of multimedia technologies has made feasible new ways of creating and presenting complex multimedia documents. Such documents consist of media objects of various types and granularities that are organized into meaningful chunks; e.g., slide presentation or story consisting of multiple (and even simultaneous) images, text data, as well as video and audio clips [10, 20, 15, 22]. Two examples of such composite presentations and resulting variations in the data consumption rates are shown in Figures 1 and 2. The first example is a report of a swimming competition where in addition to the global view, small video windows containing close ups of the leaders are shown towards the end of the report. The second example mingles video, images and narration of the interesting sights around Washington DC (details are provided later).
28.8
20
Simthsonian 2
Introduction
US Capitol
Data Transfer Rate (Kb/s)
Simthsonian 1
Figure 1: Olympic swimming competition
White house
1
5
Final statistics
In a distributed environment, presentation of structured, composite multimedia information poses new challenges in dealing with variable bandwidth (BW) requirement and synchronization of media data objects. The detailed knowledge of BW requirement obtained by analyzing the document structure can be used to create a prefetch schedule that results in efficient utilization of system resources. A distributed environment consists of various system components that are either dedicated to a client or shared across multiple clients. Shared system components could benefit from Fine Granularity Advanced Reservation (FGAR) of resources based on true BW requirement. Prefetching by utilizing advance knowledge of BW requirement can further improve resource utilization. In this paper, we describe the JINSIL retrieval system that takes into account the available bandwidth and buffer resources and the nature of sharing in each componenton the delivery path. It reshapes BW requirement, creates prefetch schedule for efficient resource utilization in each component, and reserves necessary BW and buffer. We also consider good choices for placement of prefetch buffers across various system components.
Swimmer Swimmer 2 1
Data Transfer Rate (Mb/s)
Maximum BW
Narration Narration Narration 2 3 1
Available BW
Pastorale 10
40
70
120
Time (sec)
Figure 2: Tour of Washington D.C.
to be supported will vary over time depending on the structure of the presentation [16, 17]. Tables 1 and 2 show the data consumption rate for the above two presentation examples. The variable data rate makes the task of efficient allocation of resources in shared components more complex.
Efficient presentation of such structured, composite multimedia information (i.e., retrieval and synchronous playback) gives rise to new challenges. In a distributed multimedia environment, all or some pieces of a composite presentation object may reside in one or multiple remote systems away from the client presentation system (See, Figure 3). To avoid jitter in a presentation, appropriate resources need to be reserved on various data paths from the respective sources to the client system [2, 8, 6, 11, 12, 3]. For composite documents, the instantaneous total data consumption rate that needs
One simple resource allocation policy for applications with variable bandwidth requirement is to reserve a constant BW (equals to the maximum instantaneous bandwidth required by the presentation) for the entire presentation duration. However, there are several disadvantages to this simple approach. First, in many commercial environments (e.g., cable or phone connection to home) the bandwidth is limited at the final stage of the network. This is referred to as the “Last Mile Problem”. Hence, it may be impossible or difficult 1
ships to earlier works. Section 2 describes typical workloads, and a brief overview of the JINSIL system. Section 3 introduces the general problem of BW and buffer satisfiability for a given presentation with variable BW requirement and describes the scheduling and retrieval policy used by the JINSIL system. This policy is referred to as the Generalized Bandwidth and Buffer Constrained Scheduling (GBBCS) policy. A performance study of these algorithms using simulation is presented in Section 4. Finally, summary and conclusions of the paper are presented in Section 5.
Multimedia Server
Server Control Interface
Multimedia Server Network
1.1 Contributions and Relationship to Earlier Work
Server Data Interface
The JINSIL retrieval system supports presentations of composite multimedia documents with variable BW requirement in both dedicated and shared environments. In an environment with shared components, the resources of a component (e.g., BW and buffer space) are utilized by all streams delivered through that component. Hence, the resources available to a single stream are not fixed. Additional complexities are introduced in dealing with such environments, especially in taking into account variable requirements of all streams and partitioning the available resources amongst the streams.
Clients
Figure 3: A distributed multimedia environment to support presentations of complex media documents that require multiple streams of video, audio, image or text data (even for a short duration). Higher up on the data delivery paths (e.g., in the server) the bandwidth may be shared across multiple presentations. Allocating the peak bandwidth reduces the number of presentations that can be admitted.
A number of papers have considered prefetching in a dedicated environment where a constant amount of BW and/or buffer is available per stream. Prefetching mechanisms in a dedicated environment to smooth the burstiness introduced by data compression in a single long data stream are studied in [19, 9].1 Both papers address optimal delivery schedules consisting of piecewise constant rate such that neither the prefetching of data overflows the client buffer, nor does the chosen delivery rate cause buffer underflow. The optimality condition is defined either as the minimum number of changes in the delivery rate [9] or as the least variability in delivery rates [19].
In this paper, we describe the scheduling and retrieval policies of the JINSIL retrieval system that allocates appropriate resources in every component on the delivery paths, and creates object delivery schedules for each stage. The resource allocation and creation of a prefetch schedule in JINSIL addresses various issues, including obtaining variable BW requirement of a document by analyzing its structure, determining delivery paths based on location of objects, dedicated vs shared resources on these paths, and available buffer and BW resources in each system component. Note that BW variability in a presentation can come from two sources: variations in compression ratio of a stream [19, 9] and composition of different multimedia objects [16, 17, 18]. The JINSIL system deals with the second case, and can use the solutions proposed in [19, 9] for dealing with changing compression ratios.
Bandwidth and buffer satisfiability issues for a composite multimedia document in a dedicated environment are studied in [16, 17]. We extend this work in several ways. First, we consider end-toend scenarios where some of the system components on the data path may be shared, and hence, efficient utilization of shared resources demands an object delivery schedule with minimum peak bandwidth requirement. We also consider system components that support the FGAR policy for BW and buffer. Structural analysis and time shifting (i.e., prefetching or delaying) have been used in the DEMON project [18] for presentation of composite documents in a networked environment. This has made better use of a fixed BW allocation per request by smoothing the bit rate requirements of a document. However, it has not exploited the FGAR policy for resource reservation.
The main focus of this paper are the scheduling and resource allocation issues addressed by JINSIL in an environment with shared components. First, at each delivery stage, for a given allocation of BW and buffer to a presentation, it creates a prefetch schedule for the atomic objects in the document. Second, if the system component supports the notion of Fine Granularity Advanced Reservation (FGAR), the scheduler matches the resource allocation (e.g., BW and buffer) to the variability in available resources and the exact prefetch schedule, i.e., the traffic is shaped to match the timedependent availability of BW and buffer. The resource allocation policies in JINSIL improve the efficiency of retrieval in a number of ways. The FGAR policy together with the reduction of the peak bandwidth requirement increases the feasibility of presentation, and hence, the number of streams that can be admitted by a system component. Additionally, as shown later, the time-dependent variation in bandwidth requirement may lead to periodic exhaustion of server bandwidth and hence, inefficient server utilization.
There is a lot of prior work on storage retrieval to avoid jitter in data delivery [11, 12, 3]. Continuous retrieval of composite document using flash memory is considered in [20]. In [4], authors study the prefetching and delaying schemes to avoid contention in data retrieval from disk space. A characterization and workload of hypermedia applications is proposed in [13]. The workload is used 1 In [19] performance of the proposed policy is studied in a shared network environment. However, the proposed algorithm did not explicitly take into account the available BW in the shared component (i.e., network) in reshaping the traffic.
The remainder of the paper is organized as follows. Section 1.1 delineates the contributions of this paper and describes it relation2
to study (via simulation) the performance of the Continuous Media File System (CMFS).
2
object id White house US Capitol Smithsonian 1 Smithsonian 2 Narration 1 Narration 2 Narration 3 Pastorale
Distributed Multimedia System Environments
In this section, we first describe the details of two specific workloads referred to in the earlier section. We then provide an outline of the JINSIL retrieval system.
start time 5 40 75 95 10 43 78 0
duration 30 30 20 15 22 20 24 120
data rate 30 Kb 28 Kb 29 Kb 30 Kb 15 Kb/sec 25 Kb/sec 16 Kb/sec 20 Kb/sec
Table 2: Data rates in tour of Washington D.C. presentation
2.1 Composite Multimedia Documents throughout the presentation. The first image shows the White House and also gives a narrative description. After some moments, the second image (of the Capitol building) along with its corresponding narration is provided. Soon after, the third and fourth images (of the Smithsonian Mall) are presented one after another along with a narration for both. Figure 2 shows the variability in data consumption rates during this presentation.
A composite multimedia document consists of a mixture of media types (e.g., text, audio, video, image) which are presented according to some pre-specified temporal relationships. The variable BW requirements of a document can be captured in a bandwidth profile (described in detail later). In the following, we first describe two typical composite multimedia documents, and generate bandwidth profiles (to be used in the paper) by analyzing their structures. object id image 1 narration 1 video 1 video 2 video 3 image 2 narration 2 video 4 video 5 video 6
start time 0 3 10 60 60 85 87 95 140 140
duration 10 6 70 20 20 10 6 60 15 15
Bandwidth profiles We represent the time dependent bandwidth requirement of a composite multimedia document by a bandwidth profile. A bandwidth profile is a list C ,
data rate 30 Kb 20 Kb/sec 1.6 Mb/sec 1.5 Mb/sec 1.6 Mb/sec 28 Kb 24 Kb/sec 1.5 Mb/sec 1.4 Mb/sec 1.4 Mb/sec
C = < (tc1 ; C1 ); :::; (tcL ; CL ); (tcL+1 ; 0) >;
where tcl represents a time at which the consumption rate changes (and is referred to as a breakpoint). The data consumption rate between two time points tcl and tcl+1 is represented by Cl . Each client system generates the initial bandwidth profile for a composite document by considering the start times, play durations, and data rates of all its atomic objects. In the BW profile, the breakpoints are generated by taking the union of the start times and end times of all atomic objects. During each interval (tci ; tci+1 ), the total data consumption rate of the presentation, Ci , is the sum of playback rates of all atomic objects during this interval. Note that for atomic objects of static types (e.g., images or text), all of the data need to be transfered before they can be displayed. For ease of analysis, these are simulated also as continuous type. Let an image Imagei of size L Kb be played at ti for d seconds. We consider it as a continuous data type with start time ti , data rate L=, and duration . Using this notation, the BW profile for the Olympic Swimming Competition example can be written as,2
Table 1: Data rates in presentation of an Olympic competition Olympic Swimming Competition This example shows the highlights of Olympic swimming competition. It is composed of 10 atomic media objects as is shown in the Table 1. Image 1 presents the statistics of the semifinal and the competitors in the game. Along with the Image 1, a narration (Narration 1) describes the statistics. After the image and the narration, Video 1 is played to show the global view of the competition. Near the end of the Video 1, two small screens are opened in the middle of the monitor, to show close up views of the two best competitors ( Video 2 and Video 3). The playback of Video 2 and Video 3 overlap with the playback of Video 1. At the end of the game, the last frame of the Video 2 which shows the winner of the competition fills up the whole monitor and stays till the playback of the final competition. Final competition is similarly presented by Image 2, Narration 2, Video 4, 5 and 6, etc. Figure 1 shows the variability in the data consumption rate for this presentation.
?
< (0; 0:015 Mb=s); (11; 0 Mb=s); (82; 0 Mb=s); (89; 0:024 Mb=s); (142; 4:3 Mb=s);
(2; 0 Mb=s); (12; 1:6 Mb=s); (84; 0:014 Mb=s); (95; 0 Mb=s); (157; 0 Mb=s)
(5; 0:02 Mb=s); (62; 4:7 Mb=s); (87; 0 Mb=s); (97; 1:5 Mb=s);
>
We will use this bandwidth profile as the workload for our performance study in Section 4.
2.2 JINSIL System
D.C. Tour The second example provides a guided tour of Washington D.C. It shows three popular places in D.C. i.e., the White House, U.S. Capitol, and Smithsonian Mall. The playback starts with a background music, Beethoven’s Pastorale, which is played
2 In this profile, are taken as 2 seconds for each static object. Also note that this presentation requires an initial delay of 2 seconds to accommodate initial data fetching before the presentation starts.
3
Data path Data From Server
Communication Manager
Data To Client
Local Buffer Manager Buffer read
uf fe r
Server JINSIL
tb
Remote read
Data Storage
Data Importer
Control To Server
Client JINSIL
Ge
Server Buffer Manager
Prefetcher Object Delivery Schedule
Scheduler
VMFS
File Access
Composite Media Player
Play
User Play Request
te Crea ule d Sche
JINSIL
Figure 4: A server system Metafile
The JINSIL retrieval system is essentially a system for creating an efficient object delivery schedule (ODS) based on the presentation structure and for end-to-end allocation of appropriate resources (e.g., in client and server systems).3 The ODS describes the starting point and delivery rate of each atomic object in a presentation.4 Figures 4 and 5 show the interactions of the JINSIL module (i.e., scheduler and prefetcher) with client and the server systems. The authoring system stores the structure of a presentation in a metafile (details can be found in [15, 22]). Upon receiving an user presentation request, the composite media player invokes JINSIL for generating an ODS, and for retrieving the specified multimedia objects.
Figure 5: A client system
3 Resource Allocation Scheme In this section, we describe the two main features of the resource allocation policy in JINSIL : fine granularity advanced reservation (FGAR) and generalized bandwidth and buffer constrained scheduling (GBBCS).
The JINSIL scheduler first generates a bandwidth profile for the requested presentation based on the document structure, and uses this profile to test for feasibility of presentation with the available client buffer and bandwidth. If feasible, the scheduler reserves the needed resources and constructs an ODS to be used for retrieval. The ODS may include prefetching of objects or delaying of the entire presentation. The presentation delay is the minimum delay required for a jitter free presentation (i.e., for continuous delivery). The atomic objects may reside at remote sites and hence, resources need to be reserved in each component on the data path. The JINSIL layer in each stage (e.g., client and server) will pass an ODS to the next stage as a delivery request. This schedule is used in turn by the scheduler at that stage to generate a new bandwidth profile. (The interactions and the issues in multi-stage delivery are discussed in Section 4.6.) Note that in a shared component (e.g., server), the scheduler will trade-off BW and buffer to maximize the throughput of the component. Details of the algorithms for testing for feasibility and resource allocation will be described shortly.
Fine Granularity Advanced Reservation (FGAR) To maximize resource utilization in a shared component, it is necessary to take into account variability in resource availability and resource requirements. Since this may require reserving additional (or lesser) resources at a future time (instead of reserving the maximum currently), it is referred to as the fine granularity advanced reservation (FGAR) policy. The BW profile defined earlier describes BW requirements of a presentation. The BW and buffer space availability are represented by the lists and B , respectively, where = < (t1 ; 1 ); :::; (tM ; M ); (tM +1 ; 0) >, and B = < (tb1 ; B1 ); :::; (tbN ?1 ; BN ?1 ); (tbN ; 0) >. Generalized Bandwidth and Buffer Constrained Scheduling (GBBCS) In a system component where a fixed amount of bandwidth and buffer space are dedicated to a single client, the scheduler can test the feasibility of a requested presentation by using the algorithm proposed in [17]. However, the availability of resources will be time-dependent in system components shared by multiple clients. In such environments, the scheduling policy needs to reflect the time-dependent availability of the shared resources. The proposed GBBCS policy takes into account both the BW profile and timedependent availability of resources in creating a delivery schedule for the atomic objects in a presentation.
Once JINSIL is successful in resource allocation and creation of an ODS, the composite media player starts playing back the presentation. Note that the presentation may be delayed by JINSIL in constructing a feasible ODS. The composite media player starts accessing the virtual media file system (VMFS). The data is inserted into the filesystem buffer by the local or remote JINSIL prefetcher, depending upon the delivery mode (i.e., push or pull). 3 Currently, network protocols can not use such information without provisions for an FGAR policy. 4 The details of the ODS data can be found in [21]. The JINSIL uses ODS data structures for resource allocation, data retrieval as well as for communication between the system components. However, for simplicity of presentation in this paper, we will use a bandwidth profile to represent an ODS.
Figure 6 shows the broad steps in the GBBCS policy used by by the client and the server systems. Note that once a presentation delay is introduced (say, in client) the subsequent stages (i.e., 4
FeasibilityWithMinimumPrefetching(C 0 , 0 ,B 0 ) BP = 0; For p P ; :::; if Cp0 Bp+1 = tp+1 tp 0p , 0 Bp ; p Cp Bp+1 = tp+1 else p 0p ;
f
f
GBBCS(C , , B ) FeasibilityWithMinimumPrefetching(C , , B ) ; if not schedulable, min delay = ComputeMinDelay (C; B; ) ; Cdelay = DelayReq (C, delay); else Cdelay = C ; Creshape = RsvMinPeakBW (Cdelay ; B; )); return(min delay,Creshape ,, B );
g
g
= ?1 1 ( ? )) f ( + f =0 = + ( ? tp) ;g f = Bp = Bp+1 + (tp+1 ? tp)(Cp0 ? 0p ) ; if Bp > Bp0 , return (p,Bp ) ; g /* overflow at tp */ g return(0,B1 ); /* if B1 == 0, request is feasible, else initial prefetching is required */
Figure 6: Generalized Bandwidth Buffer Constrained Scheduling
Figure 7: Algorithm for Testing Feasibility
server) can not easily introduce further delay in the presentation. (This issue is discussed further in Section 4.6.) The parameters of the GBBCS policy are the BW profile (C ), and the earlier defined availability lists of BW () and buffer (B ) of the invoking system component. The GBBCS policy first tests feasibility of presentation for the given C , and B . If the presentation is not feasible, it then checks for feasibility with a presentation delay. The ComputeMinDelay step is invoked to compute the minimum time by which the request has to be delayed for resource availability. Depending on the buffer availability, the presentation delay is used either to prefetch sufficient amount of data for a jitter free presentation, or to wait until enough BW and buffers are available. The GBBCS policy then modifies the BW profile as Cdelay by shifting the profile C by the required amount of delay. Once the presentation is feasible, the step RsvMinPeakBW is invoked to generate a reshaped BW profile, Creshape , for the current presentation request. The reshaped BW profile, Creshape, uses prefetching whenever possible, to minimize the peak BW required by the request Cdelay . The above procedure RsvMinPeakBW also reserves the required bandwidth and buffer, and updates availability lists and B . The details of these steps are given in the subsections 3.1 to 3.4.
request. This relationship forms the basis for all the steps used in the JINSIL scheduler. We next describe an algorithm for testing the schedulability of a request that is used by the steps for computing minimum delay, and minimum peak bandwidth reservation. Further details of the steps can be found in [21].
3.1 Relationship amongst Consumption Rate, Reserved BW and Buffer Let T C , T and T B be the set of breakpoints in a BW profile, available BW and available buffer, respectively. Also, let T C = tcl ; l = 1::L ; T = tm ; m = 1::M , and T B = tbn ; n = 1::N . To obtain the relationships among C , B , and in a feasible allocation, let us consider the combined set of breakpoints, T , i.e., T = T C T T B . Let P be the cardinality of the set T , i.e., the total number of breakpoints in T . We redefine the data consumption rate, available BW and buffer space with respect to the combined set of breakpoints, T , by C 0 , 0 and B 0 , respectively, where C 0 =< (t1 ; C10 ); :::; (tP ; CP0 ); (tP +1 ; 0) >, 0 =< (t1 ; 01 ); :::; (tP ; 0P ); (tP +1 ; 0) >, B 0 =< (t1 ; B10 ); :::; (tP ?1 ; BP0 ?1 ); (tP ; 0) >.
f
f
g
g
f
[
Note that in a dedicated system component where and B are constant values, the smoothing algorithm proposed in [19] can also be used to create Creshape. The algorithm in [19] has an additional objective of minimizing the variance in the reshaped BW profile.
g
[
For multimedia presentations with continuous data consumption, the data should be delivered without causing any buffer underflow or overflow. Let p be the data delivery rate between the breakpoints tp and tp+1 . Also, let Bp and Bp+1 be the amount of prefetched data at breakpoints tp and tp+1 , respectively. The relationship among Cp0 , p and Bp and Bp+1 can be characterized by Bp+1 = Bp (tp+1 tp ) (Cp0 p ); (1)
The GBBCS policy has two advantages. First, as shown later in Section 4, variable bandwidth requirement may lead to periodic exhaustions in server bandwidth. This also results in wastage of server resources, since a request cannot be scheduled until enough resources are available, and the available resources remain idle. By reducing the variability in BW requirements, the GBBCS policy reduces this wastage in server resources. More importantly, the GBBCS policy is run in all (shared or dedicated) components on the end-to-end path. This may result in successive smoothing of the BW profile. Note that even when enough resources are available in a dedicated system component (say, in the client system), the reshaping of BW profile by JINSIL reduces fluctuations seen by the succeeding stages.
?
?
?
where (0 p 0p ) and (0 Bp Bp0 ). The second term in the
above equation represents the net data reduction (or accumulation) from the buffer during this interval. Any allocation of BW and buffer ( and B ) satisfying the above equation is referred to as a feasible allocation.
3.2 Testing for Schedulability of a Request
In remainder of this section describes in more detail the steps in GBBCS. We first set up a fundamental equation which describes the relationships among the time dependent resource availability and
Given BW and buffer avaialability (0 and B 0 ), the algorithm in Figure 7 tests for feasibility of the retrieval request with BW 5
The required minimum delay is now computed by equating the required prefetch amount to the amount that can be prefetched with available BW, i.e.,
Breakpoints from Resource Availability Breakpoints from Data Request
B1 (t + t) = t 01 :
Union of Breakpoints
(3)
Therefore, from Equations 2 and 3,
min T
(t) : t = 0 B1dB (4) 1 ? dt1 (t) Note that a time shift in C by t may result in a change in the relative
Union of Breakpoints After Shift
Time
orders of breakpoints (illustrated in Figure 8). The stripes in the bars (solid or dotted) represent the breakpoints in resource availability (T B T ), consumption rate (T C ), and union of these breakpoints before and after shifting of C 0 . Let minT be the maximum amount of shift which can keep the current relative order of breakpoints, i.e.,
Figure 8: A time shift of a request and changes in breakpoints
[
profile (C 0 ). If this is feasible, the algorithm also computes the minimum amount of data that needs to be prefetched at each break point. Otherwise, it returns the latest breakpoint at which the feasibility condition (Equation 1) is violated. (This breakpoint (tp ) and the prefetching amount (Bp ) would be used by the minimum delay computation step.) The algorithm steps through all break points starting from the last break point (tP ). In each iteration, it computes the minimum amount of data that needs to be prefetched at (tp ) to satisfy the data consumption rate during the interval < tp ; tp+1 >. If the required prefetching amount is greater than the available buffer size, the presentation is not feasible under the currently available bandwidth and buffer space. The procedure terminates at this point and returns the index of this breakpoint (i.e., at which buffer overflow occurs). The normal termination of the algorithm implies a feasible schedule has been found. If the initial prefetching amount (B1 ) is non-zero, the presentation has to be delayed to prefetch this data.
minT = minfti ? tcj j ti 2 T [ T B ; tcj 2 T C ; ti > tcj g: If t minT (t is obtained from 4), shifting in C by t does not affect the relative orders of breakpoints. Hence, t could be the
required minimum delay. To check the satisfiability of the request C after a time shift of t the algorithm in Figure 7 is reexecuted. If the shifted request is feasible, the step ComputeMinDelay ends with t as the minimum delay. Otherwise, the above steps (i.e., computation of minimum delay) are repeated resulting in a further shift in the request. If t > minT , i.e., shifting the request by t may change the
dB (t)
1 relative order of break points, dt no longer holds in the range < t; t + t >. Here, the request is first shifted by minT + , where is a small number, and the steps for ComputeMinDelay are repeated. The shift minT + will result in changing of relative
dB (t)
1 orders of breakpoints. Finally note that dt in Equation 2 may not always be defined, since B1 (t + ) may be undefined.
3.3 Computation of Minimum Delay Computation of delay under dedicated resources: In a component with a fixed amount of available bandwidth and buffer space, it is straightforward to compute minimum delay before a presentation can be started (min delay). Assuming const as the constant value of available BW, min delay can be computed as min delay = B1 =. Note however, delaying a presentation can not remove an buffer overflow condition in such dedicated environments, since available buffer and BW remain constant.
As mentioned earlier, the minimum delay is also required when a buffer overflow occurs at a breakpoint ti during a feasibility test, i.e., Bi > Bi0 . Here, a delay is introduced until the overflow is removed, i.e., Bi (t + t) = Bi0 (t): (5) Therefore, from Equation 5 and an equation similar to Equation 2,
) ? Bi0 (t) t = Bi (tdB i (t)
Computation of delay under the FGAR policy: In a shared component with fine granularity advanced reservation, the available resources are time dependent, Hence, the computation of min delay is more complex. Let B1 (t) be the initial prefetching amount for a data request with start time t. Similarly, B1 (t + t) represents the initial prefetching amount after a time shift in the same data request by t. Let dB1 (t)=dt represents the rate of decrease in the required prefetch amount. Then dB1 (t)=dt can be estimated as (B1 (t + ) B1 (t))= where is a small number. The required prefetch amounts, B1 (t) and B1 (t + ) are computed using the procedure FeasibilityWithMinimumPrefetching. Now, B1 (t + t) can be estimated as,
As before the steps may need to be repeated if t > minT .
3.4 Minimum Peak Bandwidth Reservation
?
dB1(t)
B1(t + t) = B1 (t) + dt t:
(6)
dt
Once a request succeeds in the feasibility test (after a possible delay), appropriate resources are reserved on behalf of this request. Equation 1 defines the set of feasible allocations. For maximal smoothing of the BW profile, JINSIL selects an allocation where the peak value in the reserved BW, i.e, max1pP p , is the minimum among all feasible allocations (illustrated in Figure 9). We call this allocation a minimum peak BW reservation.
f g
(2)
6
Minimum BW in Modified Available BW
Minimum BW in Modified Available BW
Available BW
Overlow Amount Empty Buffer Space Prefetched Data
Available BW
Peak Value in Reserved BW
Reserved BW
(a) Non−Minimum Peak BW Reservation
Reserved BW
Available BW
Data Consumption Rate
Current minBW
Peak Value in Reserved BW
(b) Minimum Peak BW Reservation
Figure 9: Illustrations of reservations with and without minimum peak BW
OP
t
t
n4
n3
INV
t
n2
t
n1
EP
Figure 11: Illustrations of OP, EP and INV
(C 0 ; 0 ; B 0) f peakBW = lb ; INV = n ;
RsvMinPeakBW
for (;;)
progress in successive iterations in RsvMinPeakBW, and hence the algorithm always terminates.
f
0new = MIN (peakBW;0 ) ; p = FeasibilityWithMinimumPrefetching (C 0 ; 0new ; B 0; INV ) ; if (p == 0)&(B1 == 0) break ; else f INV = ComputeINV (C 0 ; 0new ; B 0 ; p; INV ); peakBW = peakBW + MinimumIncrease(C 0; 0new ; B 0 ; p; INV ) ; g
g
Initial value of minimum peak bandwidth: To compute the initial value of minimum peak bandwidth, we consider the required minimum bandwidth in all intervals, < tp ; tp+1 > assuming the maximum prefetching at tp , i.e.,
lb = 0max f((t ? t ) Cp0 ? Bp0 )=(tp+1 ? tp )g: p
