The Impact of Replacement Granularity on Video Caching Elias Balafoutis, Antonis Panagakis, Nikolaos Laoutaris and Ioannis Stavrakakis Computer Networks Laboratory Department of Informatics & Telecommunications University of Athens, Greece

Overview Introduction An Intuitive (or simplistic) Approach System Architecture Proposed Scheme Simulation Future Work

Introduction Network Caching: Bring content close to demand points Caching benefits: Reduce access latency Reduce network traffic Reduce server load Increase content availability Rapid of growth of Multimedia applications over internet Video Caching becomes particularly important

Video Caching Video Peculiarities Large Size Rate Variability Structure Large Size and Structure inspired Partial Video Caching Partial Caching Prefix Caching Sliding Window No existing partial caching schemes in which cache contents are dynamically updated based on demand

An Intuitive (Simplistic?) Approach Assumptions Two objects, One cache p1, p2 : request probabilities for objects 1 and 2 respectively Request interarrival time > download time (i.e. replacement procedure is completed before the arrival of a new request) Two Scenarios Scenario 1 : Partial Caching is not allowed Replacement unit: A complete object Scenario 2: Partial Caching is allowed Replacement unit: Half an object

An Intuitive (Simplistic?) Approach Scenario 2: Three possible states Object 1 is in the cache Object 2 is in the cache Half of each object is in the cache Cost on Cache Miss: 1 Cost on partial Cache Hit: 0.5 Total Cost: Scenario 1: Two possible states Object 1 is in the cache Object 2 is in the cache Cost on Cache Miss: 1 Total Cost: C1 ≥ C2

System Description Clients request videos from a group of servers All servers and all videos have equal access costs A proxy server is installed in a Local Area Network There is abundant bandwidth in the LAN to support video streaming Client requests are directed to the proxy The proxy caches the most popular videos trying to reduce the requests that reach the server.

Internal Proxy Architecture Request manager Schedules the transmission of the prefix (if any) Forwards request for the suffix to the origin server Cache manager (the focus of this work) Allocates the storage resources to the requested videos Note Request pattern at the cache manager (and at the server) is different, in general, from the request pattern at the request manager (for example batching of request could be used)

Cache Manager Receives the missing segments of the requested video from the server and decides: How much space to dedicate to the video Which of the missing parts to cache Which data to remove from the cache to make room for the new data. (Replacement Algorithm) In traditional web-like caching schemes, only the replacement algorithm needs to be determined.

Optimal Static Policy Assumptions Partial Knapsack problem N videos Known popularity ranking (i.e. p1>p2 … > pN) All Videos have the same size V Cache Size : S Cache portion for video i: ci Static Policy: No replacement is performed Performance metric: Byte Hit Ratio Partial Knapsack problem Maximize given that Optimal solution: Highest Popularity First (HPF) Highest Popularity First The most popular object are cached until capacity is reached. Only the last vide may be partially cached (the least popular that fits in the cache)

Proposed Scheme The Cache Manager uses a fixed Replacement Unit smaller than a complete video (Chunk) When the requested video is not in the cache (Cache Miss) It’s initial segment with the size of one chunk are stored in the cache The replacement algorithm selects a video for removal. The last segment of the selected video with the size of one Chunk are removed For each additional request for the same Video (Cache Hit or partial Hit) An additional (consecutive) chunk is being cached In that way, only prefixes (initial consecutive parts) of its video are cached. The size of the chunk determines the replacement granularity and it is a design parameter

Simulation Model (1/3) Performance Metrics Byte Hit Ratio For each request: BHR(x): Average BHRi on an interval x (x: number of requests or a time interval) Steady State BHR (ss-BHR) = BHR(x), for large x, assuming that no popularity changes occur in x. Responsiveness The ability of the system to adapt to changes in popularity. The time needed for BHR to reach 90% of its steady state value, starting with an empty cache.

Simulation Model (2/3) Request Pattern Request Distribution Independent Reference Model : Each video i, is requested with probability pi, independently of previous requests Request Distribution Zipf-like distribution: Arrival Pattern Poisson with mean rate λ Modeling of popularity changes Transposition of the Zipf-like request distribution

Simulation Model (3/3) Simulation Parameters System Parameters Default Values Video Size / Duration 1000 units / 1 hour Cache Size 100 videos Number of available videos 1000 Relative Cache Size 10% Zipf parameter 0.8 Request arrival rate 30 req/hour

Simulation Results Cache State The effect of Cache Size The effect of Popularity Distribution The effect of Chunk Size in Steady State BHR The effect of Chunk Size in Response Time BHR under changes in popularities Dynamic Regulation of the Chunk size

Cache State Assumptions Small Chunk Size Large Chunk Size 5 videos Zipf popularities The cache is initially empty Optimal Static Allocation (HPF) Chunk Size = 2 units Chunk Size = 100 units Small Chunk Size Long transient period Steady state similar to the optimal Large Chunk Size Short transient period Large oscillations around optimal state

The effect of Cache Size

The effect of Popularity Distribution

The effect of Chunk Size in Steady State BHR Small Chunk Size => higher BHR

The effect of Chunk Size in Response Time Small Chunk Size => higher BHR => very large response time

BHR under changes in popularities Rare popularity changes Small Chunk Size => Higher Average BHR Often popularity changes Large Chunk Size => Higher Average BHR

Dynamic Regulation of the Chunk size Main Idea Use small chunk at periods were BHR is stable (popularity remains the same) Switch to a larger chunk size, when BHR reduces (a change in popularity occurs) Switch back to a small chunk size, when steady state has been reached

BHR under changes in popularities (revisited) Rare popularity changes Dynamic Chunk Selection => Higher Average BHR Often popularity changes

Future work Study alternative segmentation schemes of video into chunks Different chunk size for each video Variable chunk sizes Exploit segment based caching to differentiate based on: Server-Proxy distance Link costs Content provider requests