Algorithms for Effective Variable Bit Rate Traffic Smoothing Zonghua Gu and Kang G. Shin Real-Time Computing Laboratory EECS Department University of Michigan Ann Arbor, MI 48109, USA
[email protected] Abstract The transfer of prerecorded, compressed variablebit-rate video requires multimedia services to support large fluctuations in bandwidth requirements on multiple time scales. Bandwidth smoothing techniques can reduce the burstiness of a VBR(Variab1e Bit Rate) stream by transmitting data at a series of f i e d rates, simplifgzng the allocation of resources in video servers and the communication network. RCBR (Re-negotiated Constant Bit-Rate) service model seems ideally suited for smoothed V B R traffic, which is piece-wise CBR(Constant Bit Rate). Jiang [4] proposed a dynamic progmmming algorithm to compute the optimal regotiation schedule given the relative cost of renegotiation and client buffer size. We show that the renegotiation schedule produced by his algorithm has high peak rates and frequent renegotiations. We propose another algorithm that wmputes a renegotiation schedule that has a slightly higher cost than the optimal schedule, but has other desirable properties, such as lower peak rate and lower frequency of renegotiations. We also consider proxy-based online smoothing, and propose an adaptive heuristic algorithm to generate renegotiation schedules at runtime without knowledge of future frame size infomation. W e compare the schedule computed by the algorithm to the optimal schedule computed with full knowledge of future frame sizes.
KEY WORDS Multimedia, Tkaffic Smoothing, VBR, Dynamic Programming, Network QoS
1 Introduction An extraordinarily broad range of applications are enabled by the capacity to efficiently manage digital multimedia information. Examples include digital libraries, video and image servers, distance learning and
387
collaboration, interactive virtual environments, and shopping and entertaining services. Many of these applications require the playback of stored video over a high-speed network. For continuous playback at the client, strict quality-of-service (QoS)must be provided in an end-to-end manner. Variable-bit-rate(VBR) compressed video can exhibit multiple-time-scalebit-rate variability. This traffic burstiness is inherently at odds with the goal of designing efficient real-time storage, retrieval and transport mechanisms capable of achieving high utilization. As a general real-time design principle, less bursty workloads are easier to manage. In light of the inherent multiple-time-scale burstiness of VBR video, several techniques have been proposed for reducing its rate variability. 1. Use CBR encoding instead of VBR encoding for MPEG videos. This approach involves information loss at certain playback time periods with high data rate, such as action scenes or scene transition periods, which may have a significant impact on useperceived video quality. 2. At runtime, selectively drop frames, or reduce individual frame sizes by re-encoding at a coarser quantization level. This approach has similar detrimental effects on user-perceived playback quality as CBR encoding. 3. Smoothing by work-ahead is possible for video data which can be sent ahead of schedule with respect to its playback time, subject to the dual constraints that i) the data is available to be sent, and ii) the client has sufficient buffer space to receive it. Smoothing can be done by either the video server, or a smoothing proxy that sits on the path between the video server and the client. Work-ahead smoothing of stored video by the
server does not introduce delay, while a smoothing proxy will introduce client playback delay.
It is preferable to minimize the frequency of bandwidth renegotiations for two reasons:
In this work we focus on the third approach smoothing by workahead. This paper is structured as follows. Section 2 considers the problem of precomputing the optimal RCBR renegotiation schedule that minimizes the total system cost for stored video transmission, where all future frame sizes are known in advance. Section 3 considers the problem of online proxy-based smoothing with no advance knowledge of future frame sizes, and proposes an effective heuristic that produces a renegotiation schedule at runtime with reasonable performance metrics. Section 5 presents conclusions.
1. Each renegotiation carries a certain amount of overhead for the service provider, which is likely to be high relative to the cost of reserved bandwidth itself.
2 2.1
RCBR Renegotiation Schedule for Server-based Smoothing RCBR Service Model
Grossglauser [2] proposed a network service model named Renegotiated Constant Bit Rate (RCBR) service. The basic idea is to augment standard (static) CBR service with a renegotiation mechanism. In static CBR service, at the time of call setup, an endsystem initiates a signalling message requesting a certain constant bandwidth from the network. In the forward pass, each switch performs an admission control test, and if this is successful, makes a tentative reservation and passes on the call setup message to the next switch along the path. On the reverse path, if all the switches have admitted the call, the tentative reservation is confirmed, and the call is allocated a VCI. Since the traffic is described by a single number, the admission control test is trivial. Resources corresponding to the requested rate are reserved at each contention point. For CBR service, this would mean small buffer sizes at switches in addition to billing or other housekeeping information. However, users of RCBR service are given the option to renegotiate their service rate at any time. Renegotiation consists of sending a signalling message along the path, requesting an increase or decrease of the current service rate. If the request is feasible, the network allows the renegotiation, and upon completion of the renegotiation, the source is free to send data at the new CBR rate. During renegotiation, a switch controller does not need to recompute routing, allocate a VCI or acquire housekeeping records. This reduces the renegotiationoverhead. The actual implementationof the renegotiation mechanism can be through software (for example, the Tenet Realor through time Channel Administration Protocol [l]), hardware (for example, the ATM signalling protocol proposed as ITU standard).
2. There is a certain probability of renegotiation failure, which depends on the degree of network utilization and the burstiness of competing traffic.
However, the frequency of renegotiation can not be too low, since that would mean that the reserved bandwidth tend to be much higher than the actual trans mission bandwidth. We need to strike a balance between the desire to minimize the frequency of bandwidth renegotiationand the opposite desire to increase network utilization, that is, the amount of reserved bandwidth that is actually used for transmission. The actual cost of bandwidth renegotiation depends on the actual implementation of the signalling mechanism, and is therefore difficult to quantify. But assuming that somehow a service provider has assigned a certain amount of cost to each renegotiation attempt relative to the negotiated bandwidth itself, we propose an algorithm based on dynamic programming to compute the optimal bandwidth renegotiation schedule, and compare our approach to that of [4]. Intuitively, a zero renegotiation cost results in a renegotiation schedule that exactly follows the original bandwidth plan, while an extremely high renegotiation cost results in the reservation of the peak bandwidth throughout the video playback time. In order to make this paper self-contained, we briefly describe the algorithm [4] of computing the o p timal RCBR renegotiation schedule.
2.2
The One-Step Algorithm for Computing Optimal RCBR Renegotiation Schedule
Suppose the system provides M possible transmis, .,Rw). Here we assume discrete sion rates ( R I Rz, time slots that start at the beginning of each frame time. We say that the system is at stage k when it is at the beginning of time slot k. Assume the client has a buffer size of B bytes, and the video has a total of N frames with frame sizes (fi, f2,. . .,IN).Denote the state of the system at stage k by &(b, T ) , where b is the amount of data in the client buffer and T is the reserved rate in time slot k. Denote by Gk(b,T ) the set of states which can be reached at stage k + 1 from state D I , ( r~),without violating the buffer constraint. Note that the actual transmission rate is allowed to
..
388
be lower than the reserved rate in order to avoid an excessively large number of rate renegotiations using RCBR service.
for b + r - f k > B for b + r - f k C 0
(1) Equation 1 says that if transmitting at the reserved rate r is going to cause client buffer overflow in the next time slot, i.e., when b + r - f k > B, a lower transmission rate which equals B fk - b may be used. Otherwise, the transmission rate is equal to the reserved rate. For any &+I (b', r') E Gk(b,r ) , the transition cost '&,r)-@',r') is defined as:
a result, the effects of work-ahead smoothing have already been taken into account, and we can safely assume that the reserved rate must be greater than or equal to the actual transmission rate. Otherwise, there will be sustained periods of packet loss and severe QoS degradation. Suppose there are S segments in the smoothed piecewise CBR transmission schedule, and the frame rates for the S segments are smoothed-rate[k],k = 1,.. . ,S. Instead of running DP on the N frames. Instead we only need to run DP on the S CBR segments. In lieu of Equation 1, We have the following relationship:
+
That is, the cost of a path is equal to its total bandwidth cost plus the total renegotiation cost. The problem of finding an optimal RCBR renegotiation schedule is converted to a shortest-path problem that can be solved by means of forward search in dynamic programming. 2.3 The Two-step Algorithm for Com-
puting Optimal RCBR Renegotiation Schedule First, we use the MPEG video smoothing algorithm proposed by Feng [5]to compute the optimal transmission schedule subject to client buffer size constraints. This algorithm results in a piecewise CBR transmis sion plan that has 0
Smallest peak bandwidth,
0
Largest minimum bandwidth,
0
Fewest possible bandwidth changes,
among all feasible bandwidth plans. Given the optimal transmission plan computed u s ing this algorithm, we would like to obtain the optimal RCBR renegotiation schedule that has the minimum total cost (bandwidth cost renegotiation cost)with dynamic programming. Here we adopt the notation used in Jiang's algorithm. However, our starting point here is not the original MPEG video trace, but the smoothed piecewise CBR bandwidth plan, which already accounts for client buffer size limitations. As
+
{Dk+l(4I
TI E {9,R2,...,RM})
+ +
for r 2 smoothedrate[k 11 f u r r' < smoothedrate[k 11 (0 (3) where Dk(r) denotes the system state at CBR segment k with reservation rate T , and Gk(r) denotes the set of system states reachable from state Dk(T) without violating the constraint that the reservation rate has to be greater than or e,qual to the actual transmis-
Gk(T) =
sion rate. For any DL+i E G f ) , the transition cost is defined the same as in Equation 2. The 'h-cr:) Dynamic Programming algorithm is then used to produce a renegotiation schedule. In short, Jiang's one-step algorithm considers the client buffer size constraint while running DP on the original video trace to obtain the optimal renegotiation schedule, while our two-step algorithm considers the client buffer size constraint at the first step, when the optimal transmission schedule is computed, and then runs DP on the smoothed transmission schedule. Next we show that the two-step algorithm obtains slightly suboptimal total cost values, but the resulting bandwidth reservation plan is much smoother in terms of peak bandwidth and frequency of rate changes.
2.4
Algorithm Evaluation
We use the first 10,000 frames (approximately 7 minutes) of MPEG encoded Star Wars video trace obtained from Bellcore [3] to carry out the following evaluation. As The original MPEG trace is highly bursty with a peak frame rate of 161,726 bytes/frame and an average frame rate of 16,834 bytes/frame, which is an order of magnitude smaller than the peak rate. If static CBR service were used to transmit this video over the network, then network utilization would be only around 10%. Figure 1 shows the transmission and reservation schedules computed from Jiang's one-step DP algorithm with buffer size 500 KB and relative renegotia-
389
Figure 1: The transmission and reservation schedules obtained from the one-step algorithm.
Figure 2: The transmission and reservation schedules obtained from the two-step algorithm. tion cost Cries = 1,000,000 versus a bandwidth cost of 1per byte.' The upper piece-wise CBR curve is the reservation schedule. The actual transmission schedule coincides with the reservation schedule except at periods when it's lower than the reservation schedule and is highly bursty. These are the time periods when transmission according to the reservation schedule would result in client buffer overflow and therefore a lower rate has t o be used. As far as the network is concerned, since RCBR service is used, only the reservation schedule matters in terms of call admission control (CAC) and traffic management. The occasionally bursty transmission schedule does not have any impact on the network, so it is not a cause for concern. However, it may cause disk arm scheduling problems for the video server, which must fetch data from disk 'Note that the relativc cost of rcncgotiation Cnegis assigncd somewhat arbitrarily. Further rescarch is needed to accurately quantify Cneg.
according to the transmission schedule. Since we are only concerned with network issues in this study, we will focus our next discussion on the reservation schedule. Figure 2 shows the transmission and reservation schedules computed from our proposed two-step DP algorithm with the same buffer size and relative renegotiation cost. Again, the upper piece-wise CBR curve is the reservation schedule. The actual transmission schedule coincides with the reservation schedule except at periods where it is lower than th&reservation schedule. Since the transmission schedule is computed from Feng's (51 optimal video smoothing algorithm, it is reasonably smooth without the bursty periods as in the case of Jiang's algorithm. The reservation schedule forms an envelope around the transmission schedule. The lower the renegotiation cost, the tighter the reservation schedule envelopes the transmission schedule. If the re-negotiation cost is zero, then the reservation schedule would be the almost the same as the transmission schedule, taking into account the discrete and finite number of available reservation rates inherent in the algorithm. Table 1 compares the various statistics of the two different reservation schedules computed using the one-step and two-step algorithms. As we can see,the two-step algorithm achieves a much smoother reservation schedule in terms of peak rate and number of rate changes at a slightly higher (a few percentage higher, to be more precise) total cost (bandwidth plus renegotiation). Client buffer size is 500KB for Table 1.
3
RCBR Renegotiation Schedule for Proxy-based Smoothing
In Section 2 we have considered algorithms for computing RCBR renegotiation schedules for video server initiated smoothing for stored videos. Traffic smoothing may also be performed at a smoothing proxy along the end-to-end path from the video server to the client. This may be desirable for a number of reasons. For example, the video server may not have the necessary software or hardware resources to perform smoothing, or it may not have the clients' buffer size information in order to compute a smoothing schedule.
3.1
A Model for Proxy-based Smoothing
Rexford [7]proposed a model for proxy-based online smoothing. Again we assume a discrete time model, with a total of N frames for the video, and frame sizes are (fl, fi, . .. ,f ~ ) .Note that proxy-based smoothing necessarily involves a client playback delay of length eo, which is called the smoothing window. Therefore it is suitable for non-interactive communication, such as passive recipients of a live trans
390
Renegotiation Cost Num Rate Changes(1 step) Num Rate hanges(2 step) Peak Rate(bytes/frame)(l step) Peak Rate(bytes/frame)(2 step) 2 step cost penalty
0.5M 40 24
52800 28100 3.55%
1.OM 2.OM 28 12 17 8 47500 39100 28100 28100 1.18% 2.20%
3.OM 10 8 36200 28100 1.40%
4.OM
7 7 28000 28100 1.65%
Table 1: Comparison of statistics of the one-step and two-step reservation schedules. The row labeled 2 step cost penalty refers to the percentage by which the cost of the two-step schedule exceeds the one-step schedule. Client buger size is 500KB.
3.2
mission, but not for interactive situations like videoconferencing. In general, a large smoothing window results in a longer playback delay and a smoother transmission schedule. The smoothing proxy has a buffer size Bs and smoothes the incoming video from the video server into a Be-bit client buffer. We consider two different cases: for the case of transmitting stored video, the proxy has full knowledge of all the frame size information before the transmission starts. This information can be transmitted from the video server before the start of video playback, or the proxy can permanently store this information for frequently streamed videos. We call this the infinite lookahead case, with lookahead interval P = N . The other case is that the proxy does not have any information of future frames from the video server, and it has to compute a transmission schedule based solely on the size information of frames already in its cache. This can happen, for example, for live video transmissions. We call this the no lookahead case, i.e. with lookahead interval P = 0. Using these constraints, the server can compute a schedule from time T to time min(.r w P, N w). For the infinite lookahead case, the smoothing algorithm is executed only once, while for the no lookahead case the smoothing algorithm must be executed at least N / w times, where N is the total number of frames in the video and w is the size of the smoothing window. However the proxy could conceivably compute a new schedule at every time unit to incorporate the most recently available frame size information. To strike a balance between computation overhead and smoothing gains, the proxy can execute the smoothing algorithm once every a time units (1 5 Q 5 w ) , which is referred to as the slide length. Rexford 171 showed that a sliding length Q = w/2 works almost as well as a = 1. In this paper we adopt a smoothing window of 400 frame slots and a = 200, that is, the smoothing algorithm is executed every 200 frame slots over the next 400 frames.
+ +
+
RCBR Renegotiation Schedule Computation
The case of infinite lookahead is very similar to the server-based smoothing case, except that the upper and lower transmission constraints are tighter due to the additional constraints of finite proxy buffer size and smoothing window size. We can use either the %step or the 1-step algorithm to compute renegotiation schedules. Based on the superiority of the 2-step algorithm, we will use it in the following discussions. DP is a global optimization technique that requires knowledge of the frame sizes of the entire video. Therefore, it does not work for the no lookahead case, where the proxy only has size information of w frames into the future. Here we propose an adaptive heuristic algorithm to make online renegotiation decisions, and show that it achieves reasonable performance with acceptable computation overhead. The proxy executes the smoothing algorithm shown in Figure ?? every a (slide length) frame slots to compute a smoothed transmission schedule for the next w (smoothing window) frames residing in its local buffer. However, the transmission schedule is only followed for the next a frame slots, after which the smoothing algorithm is executed again to take advantage of the size information of the newly arrived Q frames. At a certain time t , we use MaxRate to denote the maximum transmission rate for the smoothed transmission schedule in the nezt a frame slots, and ReservedRate to denote the current bandwidth reservation using RCBR service. The reservation rate is set to be discrete, i.e., ReservedRate E (RI,R2,. . . ,R M ) . If the current reservation is not enough to prevent packet loss in the next Q frame slots, i.e., ReservedRate < MaxRate, then we have no choice but to renegotiate for a higher bandwidth. Here we choose to renegotiate for the minimum bandwidth in the set ( R I ,R2,. . . ,R M )that is greater than Mcd?.de. If the current reservation is enough to sustain the maximum data rate in the next a frame slots, then we make a decision
391
based on WastedBandwidth, which denotes the cumulative amount of bandwidth that is reserved but not used (“wasted”), that is, the cumulative amount by which reserved bandwidth exceeds transmission bandwidth. If WastedBandwidth is greater than a threshold value WastedBandwidthThresholdthen we renegotiate for a new bandwidth, again the minimum bandwidth in the set (RI, Rz,. . . ,RM)that is greater than MazRate. Else we keep the current reservation. The parameter WastedBandwidthThreshold measures how long we can keep the reserved bandwidth unchanged if it is greater than the actual bandwidth in use in order to avoid the (potentially high) cost of renegotiation. A higher renegotiation cost Creneg implies a higher threshold value, and vice versa. Obviously, a judicious choice of the WastedBandwidthThreshold parameter is crucial to the effectiveness of the heuristic algorithm H. In practice we have found threshold values anywhere work well, but the optimal between 0 and 10 * Genes choice of WastedBandwidthThreshold depends on a number of factors, such as renegotiaion cost, buffer sizes of client and proxy, size of smoothing window, burstiness of the original video, etc. In order to avoid the difficult task of selecting a good threshold parameter, we propose an adaptive algorithm that dynamically changes the threshold value in order to achieve good performance. The idea is as follows: Instead of choosing a particular threshold value at the beginning and use it throughout the video transmission, we use a set of K threshold values (T1,Tz ,...,TK),evenly spaced between 0 and 10 * Crcncg, and keep track i = of the cumulative cost cumuZative-cost(T~), (0,1,. . . ,K) that would have resulted if we had used T, as the threshold d u e . During the time period of a frame slots, the cumulative cost values czLmuZative-cost(Ti),i = (0,1,. . .,K) are updated, and WastedBandwidthThresholdthat is going to be used next time is set to be the threshold value in .., T K ) that has incurred the lowthe set (Tl,Tz,. est cumulative cost so far, i.e., the threshold value with the best performance 50 far. At the beginning of each time period of a frame slots, after computing the smoothed transmission schedule, we use WastedBandwidthThreshold value that was set in the last time period to run the heuristic algorithm H to make renegotiation decisions.
3.3
Algorithm Evaluation
All computation in this section is conducted with the full-length Star Wars video trace. Five cases are considered:
Infinite Lookahead with DP(IL/DP) The proxy has full knowledge of all future frame sizes (infinite lookahead) and the %step DP algorithm is used to compute the optimal RCBR renegotiation schedule. This case achieves the lowest possible total cost for proxy-based smoothing, and is used as baseline for evaluating the other cases.
N o Lookahead with Adaptive Heuristic(NL/AH) No lookahead case, using the heuristic algorithm with adaptive threshold parameter.
No Lookahead with Optimal Heuristic(NL/OH) No lookahead case, using the heuristic algorithm with optimal choice of the threshold parameter, which can only be determined in retrospect, after the video transmission is over. Therefore it is not feasible in practice and only serves as a yardstick to measure the inherent limitations of the heuristic algorithm itself and how well the algorithm with adaptive parameter performs relative to the algorithm with optimal parameter.
No Lookahead with DP(NL/DP) No lookahead case, using the 2-step DP algorithm to compute the optimal RCBR renegotiation schedule. Again only possible in retrospect and not feasible in practice. Only serves as a yardstick to determine the lowest total cost achievable for smoothing with no lookahead.
Renegotiate Upon Rate Change(RURC) Renegotiation schedule identical to transmissions schedule, i.e., renegotiate for the needed bandwidth whenever the smoothed transmission schedule dictates a transmissionrate change. The cost of this case grows linearly with renegotiation cost Creneg. The resulting renegotiation schedule has network utilization of loo%, and as many renegotiations as the number of rate changes in the transmission schedule. Three metria are used to evaluate the performance of the above five algorithms: cost penalty, total number of renegotiations during the entire video transmission and network bandwidth utilization. Cost penalty is the percentage by which the total cost of any of the four algorithms NL/AH, NL/OH, NL/DP, RURC exceeds the baseline algorithm IL/DP, which is the best possible situation with the lowest cost for proxy based smoothing. Network bandwidth utilization is the percentage of total bandwidth reservation that is actually used for transmission. Figures 3 - 5 show the comparison of the five algorithms in terms of the three metrics in the face of Werent bandwidth renegotiation cost.
392
:t
,E'-
9
./'
1
1
8
(0
I8
I
0
20
R*aanCahlMW.
5
10 R"cc5lnMIPMI
15
m
Figure 3: The cost penalty of (NL/AH, NL/OH, NL/DP, RURC) relative to IL/DP. Client buffer size is 0.5MB. Sliding window smoothing is used with a smoothing window of 400 frame slots and sliding length Q = 200, i.e. a new schedule is computed every 200 frame slots.
Figure 5: Bandwidth utilization, i.e., the percentage of total bandwidth reservation that is actually used for transmission.
Figure 4 Number of bandwidth renegotiations for 5 different renegotiation schedule computation algorithms.
4
We can draw the following conclusions: 1. For all three metrics, NL/AH and NL/OH have relatively similar performance, but both have relatively poor performance when compared to NL/DP and IL/DP. &om this we can conclude that adaptive choice of WastedBandwidthThreshold achieves most benefits of optimal choice of the WastedBandwidthThreshold, but the inherent limitations of the heuristic algorithm H itself causes NL/AH and NL/OH to have relatively poor performance despite a good choice of the threshold parameter. 2. For all three metrics, there are visible differences between ILiDPand NL/DP when Bdient = 5MB, but very small differences when Bdient =
0.5MB. (Note that the performance figures for client buffer size 5MB is not shown for space limitations.) For Bclient = 0.5MB1client buffer is the bottleneck, so optimal reservation schedules computed with infinite lookahead algorithm(ZL/DP) and no lookahead algorithm (NL/DP) are very similar. That is, having a window of 400 frames available for smoothing is essentially equivalent to having infinite lookahead knowledge of future frame sizes, since the small client buffer size limits the usefulness of looking ahead beyond 400 frames. But for Bdient = 5Ml3,smoothing window is the bottleneck so IL/DP has a distinct advantage over NL/DP.
Related Work
Hui Zhang (111 proposed a service model called Renegotiated Deterministic Variable Bit Rate Service (RED-VBR) that is similar in spirit to RCBR. The difference is that RED-VBR builds the renegotiation service on top of a deterministic variable bit rate (DVBR) service with the Deterministic Bounding Interval Dependent (D-BIND) traffic model, while RCBR builds the renegotiation service on top of a constant bit rate (CBR) service. RED-VBR is more suitable for un-smoothed VBR traffic while RCBR is more suitable for smoothed VBR traffic, which is piecewise CBR. In fact RCBR, is a degenerate case of RED-VBR, since the D-BIND traffic parameter for a CBR segment is just a single number: the bandwidth of the CBR segment. Zhang also proposed segmentation algorithms for both the offline and online situations for renegotiation, but their metric of evaluation ( renegotiation failure probability) is different from ours. The online segmentation algorithm
393
[2] M. Grossglauser, S. Keshav, D. Tse, “RCBR A Simple and Efficient Service for Multiple TimeScale Traffic” Proc. ACM SIGCOMM 95.
works somewhat similarly to the online heuristic algorithm we propose here. There are three parameters (a,/3 and MIN-RENEG-INTERVAL. If not enough resources are reserved, a renegotiation immediately takes place, and the new traffic specification is chosen so that each bounding rate is Q times its currently measured value. For downward renegotiaion, if the transmission rate has fallen below the currently reserved rate by a factor of p, AND there have been ar least MIN-RENEG-INTERVAL frames since last renegotiaion, then lower D-BIND parameters are renegotiated for. Our work uses the cumulative WastedBandwidth as the value to watch for in making downward renegotiaion decisions, which we believe to be a more reasonable heuristic. We also proposed an adaptive algorithm that avoids explicit specification of the WastedBandwidthThreshold p& rameter.
5
(31 M. W. Garrett, A. Fernandez, “Variable Bit Rate Video Bandwidth Trace Using MPEG Code” Available at the ftp site: thumper.bellcore.com/ pub/ vbr.video.trace/MPEG.description.
[4]Zhimei Jiang, Leonard Kleinrock, “A General Optimal Video Smoothing Algorithm’’ Proc. IEEE Infowrnm 98 Pg. 676.
[5] Wu-chi Feng, F. Jahanian, S. Sechrest , “An Optimal Bandwidth Strategy for the Delivery of Compressed Prerecorded Video ” A CM/SpringerVerlag Multimedia Systems Journal, Vol. 5, No. 5, pp. 297-309, September 1997. [6] Wu-chi Feng, J. Rexford , “A Comparison of Bandwidth Smoothing Techniques for the Thinsmission of Prerecorded Compressed Video ” IEEE INFOCOM 1997, Kobe, Japan, pp. 58-66, April 1997.
Conclusions
Jiang’s dynamic programming algorithm [4] achieves an optimal bandwidth reservation and transmission schedule subject to client buffer size constraints. However, the schedule thus obtained contains undesirable large peaks in bandwidth reservation requirements, which in turn implies a high renegotiation failure probability. We propose a two-step method: (1) compute an optimal transmission schedule using the optimal video smoothing algorithm in [5], and (2), run dynamic programming on the smoothed transmission schedule to obtain a reservation schedule. Simulation results show that the two-step algorithm produces a reservation schedule that has lower peak rate and less frequent rate changes than that produced by the one-step algorithm at the expense of slightly higher total system cost. Next we consider the case of proxy-based online traflic smoothing, and propose an effective heuristic algorithm that performs reasonably well with low computation overhead. We propose a heuristic algorithm that adaptively changes the crucial threshold parameter, and show that it achieves similar performance to the optimal choice of the threshold parameter.
References [l] A. Banerjea and B. Mah, “The Real-Time Channel Administration Protocol”, Proceedings of the Sewnd International Workshop on Network and Operating System Support for Digital Audio and Video, Nov 1991.
[7] Subhabrata Sen, Jennifer Rexford, Jayanta Dey, James Kurose, Don Towsley, “Online smoothing of variable-bit-rate streaming video,” IEEE IltuLns. on Multimedia An extended version appears as a University of Massachusetts computer science technical report 98-75, 1998. [8] Jennifer Flexford, Subhabrata Sen, and Andrea Basso, “A smoothing proxy service for variable bit-rate streaming video,” Pmc. Global Internet Symposium, December 1999.
[9] Alton Pu, Crispin Cowan, “A Distributed RealTime MPEG Video Audio Player”. Fifth International Workshop on Network and Operating System Support of Digital Audio and Video (NOSSDAV’95). April 18-21,1995. Durham, New Hampshire, USA.
[lo] S. Chong, S.Q. Li, and J. Ghosh, “Predictive dynamic bandwidth allocation for efficient transport of real-time VBR video over ATM.” IEEE Journal on Selected Areas of Communications, 13:1323, Jan 1995 [ll] H. Zhang and E. Knightly, “RED-VBR A Renegotiation-Based Approach to Support Delay-Sensitive VBR Video,” ACM Multimedaa Systems Journal, 5(3):164176, May 1997.
1121 The ns website, http://www.isi.edu/nsnam/ns/.
394
