Distributing Layered Encoded Video through Caches Authors: Jussi Kangasharju Felix HartantoMartin Reisslein Keith W. Ross Proceedings of IEEE Infocom 2001, April 22-26, 2001, Alaska, USA.

Layout Introduction Model of layered video streaming Optimal Caching Negotiation About Stream Quality Queuing of Requests Is Partial Caching Useful?

Introduction Layered encoded video is appropriate for heterogeneous environment like the Internet. Using cache server between clients and servers is beneficial. Questions: Which videos and which layers in the videos should be cached given a limited cache size and bandwidth? Methodology: based on stochastic knapsack 2-resource problem.

Model of layered video streaming with proxy Video streams are stored on origin servers. Popular streams are cached in proxy. Clients direct their requests to appropriate proxy. If requested stream is cached, it is delivered from proxy to client over LAN. Otherwise, origin server delivers stream through WAN to proxy, which in turns, delivers to client.

Layered Video Pre-encoded using layered encoding techniques: J. Lee, T. Kim, and S. Ko, “Motion prediction based on temporal layering for layered video coding,” in Proc. of ITC–CSCC, Vol. 1, July S. McCanne and M. Vetterli, “Joint source/channel coding for multicast packet video,” in Proc. of IEEE International Conference on Image Pro-cessing, Oct M. Vishwanath and P. Chou, “An efficient algorithm for hierarchical compression of video,” in Proc. of IEEE International Conference on Image Processing, Nov A video consists of a base layer (basic quality information) and enhancement layers (quality enhancements). Benefits: flexible streaming services; flexible pricing structures.

Layered Video Model There are M video objects (CBR encoded). Each video has L layers. r l (m) : rate (bit/sec) of layer l, l = 1,..,L of video object m, m = 1,…,M. j-quality stream: a stream consisting of layers 1,2,..,j. T(m), m = 1,…,M: length in sec. of video m. R(j,m): revenue accrued from providing a j- quality stream of video m.

Proxy server model Bandwidth for streaming media from origin servers to the proxy is fixed at C (bit/sec). Proxy has a finite storage capacity of G (bytes). Caching strategy: cache contents are updated periodically based on the estimates of client’s request pattern. cache complete layers of video objects to maximize the revenue accrued from the streaming service. give layers of popular objects priority over less popular objects, based layer over enhancement layers.

Proxy server model (2) Request arrival: Poisson process with rate (req/sec). p(j,m): the popularity of the j-quality stream of video m. p(j,m): arrival rate of requests for j-quality stream of object m. c = (c 1,c 2,…,c M ), with 0  c m  L for m=1,…M : cache indicator. c m = i if layer 1 through I of video m are cached. Space occupied is (1)

Stream delivery model Client sends a request for j-quality stream of video m to proxy: If all requested layers are cached (c m  j), proxy delivers video. If some layers are missing (c m < j), server tries to stream missing layers c m +1,…,j at rate to client. If there is sufficient bandwidth the request is served and a bandwidth of is occupied for T(m) seconds. Otherwise, request is considered BLOCKED.

Stream delivery model (2) B c (j,m): blocking probability of the request for a j-quality stream of video m in cache configuration c. B c (j,m) = 0 for c m  j. B c (j,m) can be calculated using Kaufman-Roberts algorithm in O(CML) time. The expected blocking probability is:

Blocking probability formula B c (j,m) = 1 - where S c (j,m) = { n  S c : b c. N  C – b c (j,m)} Reference for loss model used in calculating blocking probability: K. W. Ross, Multiservice Loss Models for Broadband Telecommunication Networks, Springer–Verlag, 1995.

Stream delivery model (3) The throughput of requests for j-quality streams of object m is p(j,m)(1-B c (j,m)). The total revenue of streaming service is: The goal is to cache object layers to maximize total revenue rate R(c).

Optimal caching Maximizing revenue rate R(c) is analytically intractable and exhaustive search over cache configuration are prohibitive for realistic problem. Solution: using heuristics.

Utility heuristics Assign each of the ML video layers a cache utility u l,m, l = 1,…,L, m = 1,…,M. Movie layers are cached in decreasing order of utility. If the movie layer with the next highest utility doesn’t fit into the remaining cache space, skip this movie layer and try to cache the next highest utility movie layer. When a layer of an movie is skipped, all other layers of this movie are skipped too.

Utility definitions

Evaluation of heuristics Test the performance of heuristics in small problems to compare the heuristic against the exhaustive search. Parameters: M = 10, L = 2. C is varied from 3-15 Mbits/s. Cache capacity G varies from 3-7 Gbytes (could store from % of total movie data). Movie has average length of 1 hour. Rate of each layer is chosen randomly from a uniform distribution between 0.1 and 3 Mbps. Request rate is 142 requests/sec. Request type and movie requested drawn from a Zipf distribution with parameter 1.0. Revenue of each movie layer is uniformly distributed between 1 to 10.

Average error obtained with each heuristic compared to exhaustive search. Small link: 3 Mbit/s. Large link: 15 Mbit/s. Small cache: 3 Gbytes. Large cache: 7 Gbytes. Conclusion: heuristics achieve performance very closed to the optimum in most cases.

Evaluation of heuristics (2) Parameters: M = 1000, L = 2. C is varied from Mbits/s (between 1-15% of the total bandwidth required to stream all requested movie). Cache capacity G varies from Gbytes (could store from % of total movie data). Movie has average length of 1 hour. Rate of each layer is chosen randomly from a uniform distribution between 0.1 and 3 Mbps. Request rate is 142 requests/sec. Request type and movie requested drawn from a Zipf distribution with parameter 1.0. Revenue of each movie layer is uniformly distributed between 1 to 10.

Some conclusions from evaluation of heuristics Revenue density heuristic has the best performance of the three heuristics. Especially when we have shortage of one resource (link bandwidth or cache size). If both resources are in short, try to increase cache size before increasing link bandwidth. When requests are not very skewed significant increase in link capacity and cache size to keep the revenue at the same level. When requests are very skewed, we can have the same revenue with less resource. Request rate has much less effect on the revenue than the Zipf-parameter.

Stream quality negotiation If client’s request is blocked, the service provider tries to offer a lower quality stream of requested object. Question: How much additional revenue is incurred with this “negotiation”? Answer: Not much. Study the case when L = 2. Revenue incurred from successful negotiation is:

Queuing of Requests If a request is blocked, the server put that request in its queue and serve it later when resource becomes available. Question: How much additional revenue does it bring? Answer: Not much. Simulation: request time out 5 minutes; queue of finite size. Queue priority: arrival time, required resources, and potential revenues.

Is Partial caching useful? In system where clients are only interested in complete streams (always request all layers) and no revenue is incurred for partial systems. Question: Is caching partial streams beneficial? Answer: No.