The time structure of video streaming, which does not exist in normal Web object delivery, could benefit to the caching strategy: if we would know that a cached.
Reuse time based caching policy for video streaming Tingyao Wu, Koen De Schepper, Werner Van Leekwijck and Danny De Vleeschauwer Alcatel Lucent - Bell Labs, Copernicuslaan 50, B-2018 Antwerp, Belgium Email: {tingyao.wu, koen.de schepper, werner.van leekwijck, danny.de vleeschauwer}@alcatel-lucent.com Abstract—In this paper, we investigate the proxy video caching problem and propose a specific caching replacement strategy for segmented video streaming. The proposed caching algorithm makes use of the natural linear time structure of video streaming, which fits the philosophy of the optimal MIN algorithm. By observing the watching positions of active viewers at a certain point of time, the replacement approach computes the exact reuse time or, if not available, the predicted reuse time for stored video segments, and discards the segment that is supposedly to be used the furthest in time. Evaluations performed on a trace of a real Video-On-Demand (VOD) service show that the proposed caching algorithm substantially improves the hit ratio, especially for small caches.
I. I NTRODUCTION Today, massive multimedia content (e.g., YouTube or VideoOn-Demand) dominates the traffic and consumes a major fraction of bandwidth in the Internet. Proxy caching for video streaming has been adopted to meet the increase in video data and the application of multimedia technology. The proxy caching technology can effectively decrease the burden of the server, reduce the network bandwidth consumption and reduce the end-user’s latency. It may also alleviate network congestion and the bandwidth bottleneck to some extent. The main idea of proxy caching is to deliberately place proxy caches throughout the network and cache the videos which are visited frequently to the nearest proxy around end users [1]. Choosing an appropriate caching replacement strategy plays an important role in designing a caching proxy, as it is key to achieving high cache efficiency. Typically, the classical caching replacement strategies, such as Least Recently Used (LRU) and Least Frequently Used (LFU), are still widely used in proxy caching, because of their simplicity, the least computational cost and relatively acceptable performance. On the other hand, it has been proven [2] that the optimal caching algorithm, MIN (also called Belady’s optimal algorithm, or the OPT algorithm [3]), is the most efficient caching algorithm as it always discards the content that will not be needed for the longest time in the future. Since it is generally impossible to predict how far in the future information will be needed, this is not implementable in practice. From this viewpoint, LRU and LFU can also be seen as a prediction of future usage for cached content [4], as they assume that the least recently/frequently used content in the past will also be the least used in the future. In segmented video streaming, a video is chunked into a sequence of video segments (typically 2 to 10-second length per segment) and transmitted orderly. Based on this genuine time structure, one may ascertain that the (k + 1)-th, (k + 2)th, ..., video segments will be requested shortly after the k-th segment of the same video is being consumed, assuming there is no interruption or jump during watching the video. This fact allows us to know at the proxy which segment(s) will be requested and delivered by when, if we keep an eye on the
moving positions of active viewers. In other words, we could partially foresee the requests from clients for the duration of each requested movie. The time structure of video streaming, which does not exist in normal Web object delivery, could benefit to the caching strategy: if we would know that a cached video segment will be requested, we would prefer to keep this segment in the cache and look for an alternative replacement. Indeed, this property of video streaming has been successfully used in designing caching algorithms. For example, in [5], a chunk-based caching algorithm (CC) is proposed. In the algorithm each cached video segment is assigned a value, which is determined by the number of viewers who are watching the video but have not requested the segment yet. The value can be interpreted as the number of guaranteed hits that the segment will receive. The higher the number of guaranteed hits of a segment is, the less chance this segment will be evicted from the cache. We argue that the exact reuse time (ERT) for a cached segment is the most crucial criterion for determining the cost of keeping a segment in the cache. The reuse time refers to the time that a cached segment will be reused, independent on the number of active viewers of the video. The principle of reuse time (RT) based caching algorithm, which approximates the replacement strategy towards the MIN algorithm, is to evict a video segment which will be used in the longest foreseeable time. The ERT of a segment is the simple time difference between the concerned segment and the watching position of the closest coming viewer for the segment. For segments for which no ERT can be calculated (for instance, the first segment of a movie), a popularity prediction method can be taken to predict their reuse time. This paper is organized as follows: in section II, some related studies are introduced. In section III, we present the scenario that we address, the underlying assumptions and the algorithm in detail. The experimental results on a real VOD trace and the relevant analysis are presented in section IV. The conclusions will be given in section V. II. R ELATED WORK Many studies have been conducted on designing Web caching algorithms to save traffic over the Internet and reduce user-perceived delays [6]. Among them, LRU, LFU, LFU-dynamic aging (LFU-DA), greedy-dual-size-frequency (GDSF) and adaptive replacement caching (ARC) are the representatives which have been widely used. However, not many segmented video-specific caching studies are carried to make use of the characteristics of video streaming. Indeed, caching for video streaming differs from caching large Web objects. First, the segments from the same movie follow a linear time structure; they are usually requested sequentially.
Second, the dynamicity of videos has a different character in the sense of popularity [7]. In [8], a segment-based buffer management approach to proxy caching of large media streams was proposed. It divides video objects such that succeeding segments are double in size and the replacement always starts from the largest group. Besides, the approach paid more attention to reducing the delayed start, and used two different schemes for the beginning part and the latter part of videos. In [9], by observing that video users searching for some specific content are sensitive to the initial delay but accept a small shift of the starting point, the authors proposed a segment-based caching algorithm to maximize the user satisfaction by trading off between the initial delay and the deviation of starting point. In [5], the natural time structure of video streaming has been observed and used in the proposed caching algorithm, in which a value is assigned to each cached video segment. The value is equal to the number of coming viewers who will definitely request the segment later, by monitoring their current watching positions. However, assigning the same value to different segments for the same number of coming viewers probably does not fully use of the time information, as these segments also have their internal time difference and are requested sequentially. III. R EUSE TIME BASED CACHING ALGORITHM A. Scenario The investigated server-proxy-client network structure is illustrated in Fig. 1. The proxy cache lies at the proxy, where multiple client requests are dealt with. When a client request arrives, the proxy will check whether the requested content exists in its cache. If yes the content will be sent to the client directly, which results in a “hit” for the cache. Otherwise, the proxy has to ask for the content from the server and then forward it to the client, which leads to a “miss”. Meanwhile, the proxy would decide whether the new retrieved content will be kept in the cache, and if the cache is full, which content will be evicted. As a preliminary research for using the reuse time, in order to eliminate other influential factors, we make the following assumptions: • Instantaneous delivery between server, proxy and clients: this means that the time of transmitting content between three entities is not taken into account; the movie segments can be instantaneously delivered. • No interruption or jump: we assume that clients do not stop watching movies as long as requesting the first movie segment; they request the movie from the beginning to the end, segment by segment. • Equal movie length and size: each movie is assumed to be 5400-second length (=1.5 hours) and each segment is assumed to have the same size. B. Reuse time based caching algorithm 1) Online tracking: To compute the reuse time of a segment, we keep track of three levels of information: movielevel information, active viewer’s information and segmentlevel information. For the movie-level information, we maintain a movie ID list {Mi } (M = |{Mi }|) at the cache proxy. This movie list
Proxy server
Server
Fig. 1.
Clients
Server-proxy-client network structure
can be ranked on any set of rules. In this study, we take the recency (similar as the movie level LRU) of movies as the standard to organize the movie list. When a new movie request comes, the position of the newly requested movie will be adjusted to the position of top recency, and the reuse time of all segments from the movie will be updated accordingly. Note that only request of the first segment influences the recency of the movie; requests for all segments but the first do not change its rank in the movie list. A movie ID will be eliminated from the movie list, only if there are no active viewers, and none of its segments is cached. Together with the movie list, we also track the viewer’s information, including the number of active viewers Vi and their individual requesting time Tij (1 ≤ i ≤ M , 1 ≤ j ≤ Vi ) for movie Mi . Vi is monitored all the time: denote the current time T and the movie length L, if T −Tij > L, Vi is decreased by 1. In the segment level information, two matrices are maintained. The binary matrix CM ×N ∈ {0, 1} (N = L/S, the number of segments per movie; S: segment length) represents the cache status for all movie segments: C(i, k) = 1 means that the k-th segment of movie Mi is already stored in the cache. The other matrix RM ×N monitors the reuse time for each segment. 2) Reuse time computation: The matrix RM ×N keeps the reuse time for each segment. In practice, the calculation of reuse time is two fold. Exact reuse time. A segment that will definitely be consumed by an active viewer has exact reuse time (ERT). The ERT can be calculated as the time distance between the positions of the segment and the closest coming viewer. 0 Suppose Tik is the watching position of the closest com0 ing viewer for the k-th segment of movie Mi : Tik = min (T − Tij ), then ∀j, T −Tij ≤S×k
0 R(i, k) = S × k − (T − Tik ).
(1)
Predicted reuse time. In some cases, the closest coming viewer is unknown. For instance, the reuse time of the first movie segment is not always guaranteed: we are not sure after how long time there will be a request for the movie (i.e. the first movie segment). Then the reuse time for the segment can not be computed directly and has to rely on popularity prediction. As popularity prediction is not the main concern in
this paper, we adopt two simple prediction methods to compute the predicted reuse time (PRT) for uncertain segments. One method (denoted as RT LN) is to assign an arbitrary large reuse time for them, resulting in these segments to be replaced prior to those with exact reuse time. The weakness for RT LN is that suppose one movie only has one active viewer and another popular movie has multiple viewers, it is desired to keep the beginning segments of the second movie in the cache, instead of later segments of the first movie. A simple but improved method (denoted as RT F REQ) is then to use the request frequency (similar as LFU) to predict the reuse time for uncertain segments. Indeed, the reuse time for the first segment R(i, 1) is directly related to the popularity of the movie. The more popular the movie is, the less the reuse time will be. Then the frequency of requests for the movie within a certain window is taken as predicting the reuse time: R(i, 1) = W/Hi ,
(2)
where W denotes the length of the past observing window and Hi is the number of requests for movie Mi in it. For movies without any requests in the observing window W , an arbitrary large value is assigned, as we do for RT LN . As long as R(i, 1) is determined, the reuse time for its following uncertain segments is calculated as R(i, k) = R(i, 1) + S × k.
(3)
3) Algorithm: After the reuse time of each cached segment is computed or predicted, the replacement algorithm is implemented as follows: (1) Segment-level reuse time. We select one cached segment xi with the maximal reuse time per movie, and aggregate them into set X: X = {xi |xi = argmax R(i, k)}.
(4)
∀k, C(i,k)=1
If there are multiple segments with equally maximal reuse time in one movie, then the segment furthest away from the beginning is chosen. The segment with maximal reuse time in set X will be evicted, as it is supposedly to be used in the furthest future. If a tie exists, a set Y (Y ⊆ X) is constructed by collecting all tied segments from set X and then go to (2). (2) Movie-level instant popularity. This criterion focuses on the number of active viewers, representing the instant popularity of the candidate movies/segments. We retrieve a movie list to which the segments in Y are belonged, and find a set of segments Z (Z ⊆ Y ) of which movies have the least viewers. If |Z| = 1, the segment in Z will be evicted. Otherwise go to (3). (3) Movie-level recency. If |Z| > 1, we choose the segment whose parent movie is at the LRU position of the movie list Mi . IV. E XPERIMENTS A. Dataset The dataset employed in the evaluation consists of a request trace of the VOD service of a leading European telecom operator, measured over a period of 32 days. The request trace consists of 8392 unique users spread across 12 city regions
issuing requests for 4971 different movies within this period, resulting in a total of 75013 requests. A request includes the initial request time, movie ID, client ID and city ID. The request rate during peak hours is around 250-500 requests per hour. Considering 1.5-hour movie length, the peak number of concurrent active viewers is between 375 and 750. A more detailed analysis of this VOD trace can be found in [10]. Only the trace of initial request time and the request movie IDs are used in the simulation. Two close requests for different movies from the same client are considered as two independent requests from different clients, as we assume that there is no interruption or jump, and movies are played from the beginning to the end. The original movie-level trace is then rewritten to a segment-level trace: a request to movie Mi at time t in the movie-level trace is divided into a series of segment requests at time t+(k −1)×S, 1 ≤ k ≤ N . After the division for each movie request, the segment requests are aggregated and re-ranked in the ascending time order. Although in reality, the length of a movie segment can be about 2 to 10 seconds, to ease the simulation and reduce the computational burden, we restrict the possible lengths of segment to be 5400, 2700, 1350 and 540 seconds. This does not alter the relevance of our results, as in practical implementation, short segments can be aggregated in large logical unit. According to the third assumption in section III-A, the possible number of segments per movie is then 1, 2, 4 and 10, depending on the chosen segment length. B. Simulation results The performance of caching algorithms is evaluated by the hit ratio, the ratio between the number of segment requests that can be served from the cache proxy and the number of segment requests sent by clients. The investigated cache size is selected as the integer multiples of the movie size so that we could intuitively analyze the relevance between the cache size and the hit ratio. A cache whose size is equal to 1 movie means that it could hold 1 segment (or 10 segments) when the segment length is 5400 seconds (or 540 seconds). Fig. 2 shows the hit ratios achieved by the MIN, LRU, CC and RT algorithms over different cache sizes with each sub figure a different cache size, ranging from 1 to 250. Note that for the RT F REQ, the window size for collecting requests to estimate PRT for uncertain segments is set to be 5400 seconds, i.e., 1 movie length. We observe that: (1) Although the RT and the CC algorithms beat the LRU in all cases, the RT is superior to the CC, especially for small caches. For example, when the cache size is 10 movies and the segment length is 540 seconds, the hit ratios for RT F REQ, RT LN and CC are 27.70%, 27.59% and 21.19% respectively, while the traditional LRU and the M IN (the upper boundary) obtain 9.43% and 31.72% hit ratios. (2) The benefits of using the RT and the CC algorithms diminish as the cache size increases. That is expected, as in a big cache quite a lot of cached segments which are not to be used soon stay in the cache, thus become the candidates for the LRU replacement. (3) RT F REQ achieves the highest hit ratio among the compared algorithms in small caches; however its advantage is not maintained in a big cache. We conjecture that this decreasing is due to the inappropriate window size for predicting the reuse time.
RT_FREQ: Comparisons on different window sizes over various cache sizes
Comparisons on RT, CC and LRU caching algorithms over different cache capacities. cache size = 1
1350
20 10 0
540
5400 2700
Length of segment cache size = 50
40 30
540
60 50
8 ML
16ML
32ML
20 10 0 1 ML
2 ML
30
5400 2700
1350
cache size = 100
40 30
2 ML
16ML
32ML
16ML
32ML
60 50
4 ML
8 ML
16ML
32ML
40 30 1 ML
2 ML
cache size = 250
70 RT_LN
65
Hit ratio (%)
RT_FREQ
MIN
75
Segment Length: 540 secs
70
Segment Length: 1350 secs
65
Segment Length: 2700 secs Segment Length: 5400 secs
60
CC
60
LRU
55 1 ML
LRU
8 ML
Window size
80
75
4 ML
Window size
Length of segment
MIN
1350
8 ML
Window size
cache size = 50 70
540
cache size = 250
5400 2700
4 ML
Window size
50
20 1 ML
80
Hit ratio (%)
4 ML
30
40
Length of segment
55
2 ML
60
Hit ratio (%)
Hit ratio (%)
Hit ratio (%)
540
cache size = 100
50
1350
5
0 1 ML
70
5400 2700
10
Length of segment
60
20
1350
Hit ratio (%)
30
40
Hit ratio (%)
5400 2700
Hit ratio (%)
Hit ratio (%)
Hit ratio (%)
5
cache size = 10
15
40
10
0
cache size = 1
cache size = 10
15
2 ML
4 ML
8 ML
16ML
32ML
Window size
540
Length of segment
Fig. 2. Hit ratios of the RT, CC, LRU and MIN algorithms over different cache sizes.
Fig. 3. The performance of RT F REQ on different window sizes over various cache sizes. ML: movie length
Hit ratio of RT_FREQ with the best window size, compared with other caching algorithms 80
TABLE I H IT RATIOS (%) OF DIFFERENT CACHING ALGORITHMS . T HE SEGMENT LENGTH IS 540 SECONDS . 1 11.17 11.04 5.67 1.28 11.82
size (# movies) 50 100 45.04 53.61 41.16 48.10 39.58 47.93 26.96 39.43 53.65 64.15
250 66.03 61.56 61.56 58.60 77.33
70
60
50
Hit ratio (%)
methods RT F REQ RT LN CC LRU MIN
Cache 10 28.49 27.59 21.29 9.43 31.72
40
30
To verify the conjecture, we check the hit ratios of RT F REQ in different window scales on various cache sizes, which are shown in Fig. 3. The x axis in Fig. 3 represents the window size that we use to estimate the reuse time for uncertain movie segments. It can be seen that the choice of window size directly influences the estimation of the RT algorithm, especially for big caches. For instance, the optimal window size is 1 movie length when the cache can only hold 1 movie, while the optimal size is 16 movie lengths (=1 day) when the cache size is equal to 250. This can be explained from the characteristics of frequency estimation. A small window size captures the instant movie popularity within a short period while a large window size could present the relatively global popularity. For big caches, the instantly popular movies identified by a small window size could evict some globally - but not instantly popular movies out of the cache, thus waste the cache size. Fig. 4 and Tab. I re-organize the hit ratios of the 540-sec segment length in Fig. 2, in which the hit ratio of RT F REQ performed on its best window size is presented. One interesting observation is that the RT LN algorithm seems to be the transient method between the RT F REQ and the CC algorithms: its performance is very close to the RT F REQ when the cache size is small, but slowly moves towards that of the CC as the cache size increases. Recall
MIN 20
RT_FREQ RT_LN CC
10
LRU
0
1
10
50
100
250
Cache size
Fig. 4. Hit ratios of all caching algorithms over different cache sizes. RT F REQ: the best window size is employed
that in RT LN , uncertain segments are always assigned an arbitrary large number without deliberate prediction. Indeed, for small caches, the movie level popularity prediction is not crucial; the competitions mainly happen between segments with small ERTs. This explanation can also be supported by the hit ratios of RT F REQ with 1-movie cache size and 540secs segment length (see the first plot of Fig. 3), where the hit ratio is almost flat for any window size. However, a big cache arises competitions between ERT segments and PRT segments, thus a good movie-level popularity predictor could correctly predict the reuse time for uncertain segments, enhancing the survival chance for segments in popular movies. To further study the relevance of exact and predicted reuse time of cached segments, we investigate the status of a segment when it is hit,
Hit and replacement partition for RT_FREQ caching algorithm. SL = 540 Hit partition
5
5
x 10
4.5 4 Hit on LRU
# of hits
3.5 3
Hit on PRT
2.5 2
Hit on ERT
1.5 1 0.5 0
1
5
10
50
100
250
Replacement partition
5
7
x 10
ERT replaced
# of replacements
6
PRT replaced PRT + # viewers
5
PRT + # viewers + LRU 4
LRU replaced
3 2 1 0
to prevent an unpopular movie from staying in the cache too long time. The simulation was done based on a few assumptions simply due to the easy implementation of the experiments. However, we believe that loosening these assumptions does not greatly change our fundamental conclusions. For instance, if the content can be delivered instantaneously between the server and the proxy, an extra retrieval cost function for each cached segment should be added into our reuse time based caching policy. The assumption of non-interruption or jump during watching movies also has little influence to the RT algorithm: if one active viewer stops watching a movie, the RT algorithm simply updates the reuse time for the next viewer. This will also be studied in the future.
1
5
10
50
100
250
Cache size
Fig. 5. Hit and replacement partitions for the RT F REQ algorithm with the best window size. SL: segment length
and partition the hit segments into three categories, “hit on LRU” (no request within the past observed window), “hit on PRT” (segments with PRT) and “hit on ERT” (segments with ERT); similarly, the status of a replaced segment is classified into “ERT replaced”, “PRT replaced” and “LRU replaced”. For the category “PRT replaced”, it can be further separated into “PRT+# viewers” or “PRT+# viewers+LRU” when a tiebreaker is needed. Fig. 5 shows the cumulative number of hit or replaced segments for RT F REQ in different categories with the best window size for the corresponding cache size and the 540-sec segment length. As can be seen, the segments with ERT are rarely be replaced when the cache size is larger than 50, and contribute to a large percentage of hits. C. Discussions and future work We have demonstrated that the RT caching algorithm is superior to the CC and the LRU strategies in our simulation for various cache sizes. The reuse time for segments that will be requested is easily calculated, but the reuse time for uncertain segments relies on popularity prediction. In our simulation, we used a simple frequency based predictor to estimate the next expected request time for the first segment of a movie. We have already seen the simple popularity predictor helps the caching algorithm to estimate the RT for uncertain segments and make a correct replacement decision. In the future, we will employ more advanced popularity prediction methods (for instance, reservoir computing [11]) and make a better prediction. The competition between segments with ERT and segment with PRT will also be investigated. Recency is the investigated criterion to rank movies in our simulation. We believe that this could be improved as well by replacing it with another elaborated ranking method. For example, in [5], the authors presented a movie-level scoring algorithm which upgrades a movie gradually. The benefit is
V. C ONCLUSIONS In this paper, we have presented the idea of using the reuse time of movie segments for cache replacement strategy in segmented video streaming. We have shown that using the exact reuse time is a method to obey the principle of the MIN algorithm as it is based on the extraction of the time structure of video streaming and foresees which segments will be requested by when in a close future. Two different approached are employed to compute the RT of cached segments. We demonstrated that the proposed replacement strategy considerably enhances the hit ratio, comparing with the traditional caching algorithms. ACKNOWLEDGMENT This work was partially supported by the European project: Open ContEnt Aware Networks (OCEAN), grant agreement no. 248775. R EFERENCES [1] W. Liu, C. Chou, W. Wen, and X. Du, “Proxy caching for interactive streaming media,” Journal of Computer Research and Development, vol. 43, no. 4, pp. 594–600, 2006. [2] B. Van Roy, “A short proof of optimality for the MIN cache replacement algorithm,” Information Processing Letters, vol. 102, no. 2, pp. 72–73, 2007. [3] L. Belady, “A study of replacement algorithms for virtual storage computers,” IBM Systems Journal, vol. 5, pp. 79–101, 1966. [4] L. Shi, Z. Gu, L. Wei, and Y. Shi, “An application study of Zipf’s law on web cache,” International Journal of Information Technology, vol. 12, no. 4, pp. 49–58, 2006. [5] D. Hong, D. De Vleeschauwer, and F. Baccelli, “A chunk based caching algorithm for streaming video,” in Proc. the 3th workshop on Network Control and Optimization (NetCOOP), Ghent, Belgium, Nov. 2010, pp. 33–40. [6] S. Podlipnig and L. B¨osz¨ormenyi, “A survey of web cache replacement strategies,” ACM Comput. Surv., vol. 35, pp. 374–398, December 2003. [Online]. Available: http://doi.acm.org/10.1145/954339.954341 [7] M. Cha, H. Kwak, P. Rodriguez, A. U-Y, and S. Moon, “I tube, you tube, everybody tubes: analyzing the world’s largest user generated content video system,” in Proc. the 7th ACM SIGCOMM Conference on Internet Measurement, 2007, pp. 1–14. [8] T.-L. Wu, P. Yu, and J. Wolf, “Segment-based proxy caching of multimedia streams,” in Proc. the 10th International Conference on World Wide Web, Hong Kong, 2001, pp. 36–44. [9] W. Tu, E. Steinbach, M. Muhammad, and X. Li, “Proxy caching for video-on-demand using flexible starting point selection,” IEEE TRANSACTIONS ON MULTIMEDIA, vol. 11, no. 4, pp. 716–729, Jun. 2009. [10] J. Famaey, T. Wauters, and F. D. Turck, “On the merits of popularity prediction in multimedia content caching,” in Proc. the 12th IFIP/IEEE International Symposium on Integrated Network Management (IM), Dublin, Ireland, 2011. [11] T. Wu, M. Timmers, D. De Vleeschauwer, and W. Van Leekwijck, “On the use of reservoir computing in popularity prediction,” in Proc. Internet, Valencia, Spain, Sep. 2010, pp. 19–24.
