Distributing Layered Encoded Video through Caches

Authors:

Jussi Kangasharju Felix Hartanto Martin 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 1998. S. McCanne and M. Vetterli, “Joint source/channel coding for multicast packet video,” in

Proc. of IEEE International Conference on Image Pro-cessing, Oct. 1995. M. Vishwanath and P. Chou, “An efficient algorithm for hierarchical compression of video,” in

Proc. of IEEE International Conference on Image Processing, Nov. 1994.

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. rl(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 = (c1,c2,…,cM), with 0 cm L for m=1,…

M : cache indicator. cm = 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 (cm j),

proxy delivers video. If some layers are missing (cm < j), server

tries to stream missing layers cm+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) Bc(j,m): blocking probability of the

request for a j-quality stream of video m in cache configuration c.

Bc(j,m) = 0 for cm j. Bc(j,m) can be calculated using

Kaufman-Roberts algorithm in O(CML) time.

The expected blocking probability is:

Blocking probability formula

Bc(j,m) = 1 -

where Sc(j,m) = { n Sc : bc . N C – bc(j,m)}

Reference for loss model used in calculating blocking probability:K. W. Ross, Multiservice Loss Models for Broadband TelecommunicationNetworks, Springer–Verlag, 1995.

Stream delivery model (3) The throughput of requests for j-quality

streams of object m is p(j,m)(1-Bc(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 ul,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 23.1-41.7% 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 10-150 Mbits/s (between 1-15% of the total bandwidth required to stream all requested movie).

Cache capacity G varies from 12-560 Gbytes (could store from 0.9-41.7% 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.