Multimedia Proxy Caching Mechanism forQuality Adaptive Streaming Applications in The Internet

Reza Rejaie, Haobo Yu, Mark Handley, and Deborah Estrin

AT&T Labs – Research USC/ISI ACIRI at ICSI

IEEE Info COMM 2000 pp 980 - 989

- this papers proposes a proxy caching mechanisma proxy caching mechanismfor layered-encoded multimedia streamsfor layered-encoded multimedia streams in the Internet to maximize the delivered quality ofpopular streams to interested clients

- a proxy cache resides close to a group of clients

- requested streams are always delivered from theoriginal servers through the proxy to clients. Thus,the proxy is able to intercept and cache thesesteams

- the proxy can significantly increase the delivered quality of popular streams to high BWclients despite the presence of a bottleneck onits path to the original server

- the proxy can also reduce the startup delay,facilitate VCR-functionalities, and reduce loadon the server and network

- compare to the other enhancing approaches,such as mirror servers, proxy caches havelower storage and processing requirements

- recall that, the architecture of layeredquality adaptation mechanism without theproxy is as following figure:

- with the proxy, the big image of the systemwill be as following:

cong

esti

on c

o ntr

ol

ACKE

R

CacheController

prefetching request

Layer0

Layer1

Layer2

Layer3

Cache

Quality Adaptation

proxy

available BW

- to maximize the delivered quality toclients while obeying congestion controlledrate limits, streaming applications shouldmatch the quality of delivered streamwith the average available BW on thepath.

- Thus the quality of cached streams Thus the quality of cached streams will depend on the available BW (on thewill depend on the available BW (on thepath between the server and the proxy)path between the server and the proxy)to the first client that retrieved the to the first client that retrieved the streamstream

- however, quality variations of the cached stream are not correlated with the quality variations required by quality adaptation ( on the proxy-client path ) during the new playback

- this means that the quality adaptation moduleat the proxy may attempt to send some datathat do not exist in the cache (the missing datamay be caused by either congestion or thequality adaptation module of the server)

- this results in requiring of data prefetchingdata prefetching (done by the proxy) during the idle time or when delivering for the higher quality flow

- note that performing “data prefetching” fora cached stream can be considered as the quality adjustment of that stream

- to allow fine-grain adjustment, each layer ofthe encoded stream is divided into equal-sizedpieces called “segments”“segments”

- the proxy prefetches missing segments thatare required by the quality adaptation along theproxy-client path and are missing in the cache

- main contributions of this paper are novelnovelprefetchingprefetching and fine-grain cache replacementfine-grain cache replacementalgorithmsalgorithms for multimedia proxy caching

- the interaction of the two algorithms causesthe state of the cache to converge to anefficient stateefficient state such that the quality of acached stream is proportional to its popularity,and its quality variations are inversely proportional to its popularity

Main AssumptionsMain Assumptions::

1. using Rate Adaptation Protocol (RAP) withoutthe implementation of packet retransmissionmechanism

2. using Hierarchical Encoding

3. all streams are linear-layered encoded whereall layers have the same constant BW ( forsimplicity )

Delivery ProcedureDelivery Procedure::

- clients always send their requests for aparticular stream to their correspondingproxy

- when a proxy receives a request, it checksthe availability of the requested stream

- the rest of the delivery procedure variesfor cache miss or a cache hit

Relaying on a cache miss:

- if the requested stream is missing from thecache, the request is relayed to the originalserver.

- the stream is played back from the serverto the proxy via an RAP connection

- the proxy then relays data packets towardthe client through a separate RAP connection

- in the cache miss scenario, the client doesnot observe any benefit from the presence ofthe proxy cache

Prefetching on a cache hit:

- on a cache hit, the proxy acts as a serverand starts playing back the requested stream

- as a result, the client observes shorterstartup latency

- in case of the mismatch between the qualityof the cached stream and the requirement ofthe proxy’s quality adaptation module, the proxyshould prefetch the missing segments from theserver ahead of time

- two possible scenarios:1. PlaybackAvgBW <= StoredAvgBW2. PlaybackAvgBW > StoredAvgBW

- all the prefetched segments during a sessionare cached in both scenarios

PlaybackAvgBW <= StoredAvgBW

PlaybackAvgBW > StoredAvgBW

Prefetching MechanismPrefetching Mechanism: “sliding-window”: “sliding-window” - prefetching a segment from the server will take at least one RTT of the server-proxy path - thus, the proxy must predict a missingsegment that may be required by the qualityadaptation module in the future

- quality adaptation adjusts the number ofactive layers according to random changes in theavailable BW, the time for upcoming adjustmentis not known aa prioripriori

- tradeoffs:the earlier the proxy prefetches a missing

segment, the less accurate is the prediction,but the higher is the chance of receiving the prefetched segment in time

- the server should deliver the requested segment based on their priority, otherwise theprefetching stream will fall behind the playback

- note that the prefetched segments are alwayscached even if they arrive after their playouttimes

- the proxy maintains the playout time for each active client

- at the playout time, tp, the proxy examines the interval [tp+T, tp+T+], which is called the “prefetching window” of the stream, and identifies all missing segments within this window

- the proxy then sends a single “prefetching request” that contains an ordered list of all these missing segments in a prioritized fashion

- to loosely synchronize the prefetching stream with the playback stream, after seconds, the proxy examines the next prefetching window and sends a new prefetching request to the server

- when the server receives a prefetching request, it starts to send the requested segments based on their priorities (layer numbers)

- a new prefetching request preemptspreempts the previous one. If the server receives a new prefetching request before delivery of all the requested segments in the previous request, it ignores the old request and starts to deliver segments in the new request (this preempting mechanism causes the prefetching and the playback to proceed with the same rate)

- the average quality improvement of a cached stream after each playback is determined by the average prefetching BW

- multiple prefetching sessions can be multiplexed

Replacement AlgorithmReplacement Algorithm::- goal: converge the cache state to an efficientefficient state

- the conditions of the “efficient” state:1. the average quality of each cached

stream is directly proportional to its popularity. Furthermore, the avg quality of the stream must converge to the avg BW across most recent playbacks

2. the quality variations of each cached stream are inversely proportional to its popularity

Replacement Pattern:

- layered encoded streams are structured into separate layers, and each layer is further divided into segments with a unique ID

- as the popularity of a cached stream decreases, its quality-- consequently its size-- is gradually reduce before it is completely flushed out

- once a victim layer is identified, its cached segments are flushed from the end.

- if flushing all segments of thethe victim layervictim layer does not provide sufficient space, the proxy then identifies a new victim layer and repeats this process

Popularity Function:

- in the context of streaming applications, the client can interact with the server and perform VCR-functionalities (i.e., Stop, FF, Rewind, Play).

- intuitively, the popularity of each stream should reflect the level of interest that is observed through this interaction

- assume that the total playback time of each stream indicates the level of interest in that stream for example, if a client only watches half of one stream, its level of interest is half of a client who watches the entire stream. This approach can also include weighted duration of fast forward and rewind with proper weighting

- define the term “weighted hit (whit)”

where PlaybackTime: the total playback time of a session (second) StreamLength: the length of the entire stream (second)

- the proxy calculates weighted hits on a per-layer basis for each playback

- the cumulative value of whitwhit during a recent window (called the popularity windowpopularity window) is used as the popularity indexpopularity index of the layer

- the popularity of each layer is re-calculated at the end of a session as follows:

Where P denotes popularity denotes the width of the popularity window

NoteNote ! !- adding and dropping layers by quality adaptation results in different PlaybackTimes in a session and consequently affects popularity of a cached layer

- applying the definition of popularity on a per-layer basis is compatible with the proposed fine-grain replacement mechanism. The reason is that layered encoding guarantees that popularity of different layers in the same stream monotonically decrease with the layer number. Thus, a victim layer is always the highest in-cache layer of one of the cached streams

- the length of a layer does not affect its popularity, because whitwhit is normalized by stream length

Simulation SetupSimulation Setup::

- ns-2 simulator- RAP without error control mechanism [no retransmission scheme]- two sets of simulations:

1. focusing on evaluating the prefetching algorithm

2. focusing on the replacement algorithm

- in all simulations the server-proxy link is shared by 10 RAP and 10 long-lived TCP flows. One of the RAP flows is used to deliver multimedia streams from server to the proxy’s cache; the other 19 flows present background traffic, whose dynamic results in available BW changes that will trigger adding and dropping of layers

- to limit the number of parameters, all streams have 8 layers, the same segment size of 1 KB, and layer consumption rate of 2.5 KB/s

Evaluation Metrics:

- Completeness

* the percentage of a stream residing in the cache

* this metric allows us to trace the qualityevolution of a cached stream after each playback

* defined on a per-layer basis* the completeness of layer ll in

cachedstream ss is defined as:

where “chunk”: a continuous group of segments of a single layer of a cached stream chunk(l): the set of all chunks of layer l Ll, i : the length (in terms of segments) of the ith cached chunk in layer l RLi : the official length of the layer

- Continuity

* the level of smoothing of a cached stream* also defined on a per-layer basis* the continuity of layer ll in cached stream

ss is defined as follows:

where a layer break occurs when there is a missing segmentin a layer

Results:

- Prefetching

- Replacement Algorithm

* to examine the hypothesis that the state of the cache gradually converges to an“efficient” state as result of the interactionbetween prefetching and replacement algorithm

* the resulting quality due to cache replacement depends on two factors: streampopularity and the BW between the requestingclients and the proxy

* 10 video streams with lengths uniformlydistributes between 1 and 10 minutes. Stream#0is the most popular one

- the cache size is set to be half of the totalsize of all 10 streams

- to study the effect of stream popularity,BWsp >= BWpc

- to study the effect of client’s bandwidth,BWsp < BWpc