Scalable proxy caching algorithm minimizing clientõs buffer size and channel bandwidth q

Transcription

1 J. Vis. Commun. Image R. xxx (2005) xxx xxx Scalable proxy caching algorithm minimizing clientõs buffer size and channel bandwidth q Hyung Rai Oh, Hwangjun Song * Department of Computer Science and Engineering, POSTECH, Republic of Korea Received 8 April 2004; accepted 22 January 2005 Abstract This paper presents a scalable caching algorithm of proxy server with the finite storage size minimizing clientõs buffer size and constant-bit-rate channel bandwidth. Under the general video traffic condition, it is observed that the amount of decreased clientõs buffer size and channel bandwidth after caching a video frame depends on the relative frame position in the time axis as well as the frame size. Based on this fact, we propose an effective caching algorithm to select the cached frames by using the normalized buffer size. Finally, experimental results are provided to show the superior performance of the proposed algorithm. Ó 2005 Elsevier Inc. All rights reserved. Keywords: Proxy server; Scalable caching; ClientÕs buffer size; Channel bandwidth 1. Introduction In the recent years, the demand of video service over network has been increasing very fast, and it is feasible due to the fast development of network and digital video processing technologies. Generally, video needs a larger amount of data compared with other media. Thus, it is indispensable to employ effective video compression q This work was supported by Korea Research Foundation Grant (KRF D00468). * Corresponding author. Fax: address: hwangjun@postech.ac.kr (H. Song) /$ - see front matter Ó 2005 Elsevier Inc. All rights reserved. doi: /j.jvcir

2 2 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx algorithm to reduce the amount of data. So far, digital video coding techniques have advanced rapidly. International standards such as MPEG-1, 2 [1], and 4 [2], H.261 [3], H.263/+/++ [4], and H.264 [5] have been established or under development to accommodate different needs by ISO/IEC and ITU-T, respectively. The compressed video data are generally variable-bit-rate due to the generic characteristics of entropy coder and scene change/inconstant motion change of the underlying video. Generally speaking, the variability of compressed video traffics consists of two components such as short-term variability (or high frequency variability) and long-term variability (or low frequency variability). Buffering is quite effective in reducing losses caused by variability in the high frequency domain while it is not effective for handling variability in the low frequency domain [11]. On the other hand, constant-bit-rate video traffic may be generated by controlling the quantization parameters and it is much easier to handle over the network, but the quality of the decoded video may be seriously degraded. Furthermore, video requires the stringent network quality-of-service (QoS) due to its generic time constrain characteristic for the smooth display. These facts make the problem more challenging. Until now, a large amount of research efforts have been devoted to the networks supporting guaranteed QoS and video coding that is adaptive and robust to network conditions. Proxy server has been widely employed to reduce the response time delay and improve the network utilization [8,9]. Proxy server is closely located to clients. When a client wants some data, proxy server intercepts the request message and provides the data if possible. Otherwise it contacts the remote original server, and then saves the received data in storage devices and forwards them to the client. As a result, the response time is significantly reduced in terms of client, the load of server can be reduced, and network utilization can be improved since the number of duplicated data decreases. Recently, proxy server has been extended to seamless video services over network while Web caching is a dominant application until now. However, it is almost impossible to store all data at proxy server in the case of video since proxy server generally has a limited storage size. Hence it is very important to determine which parts of data must be stored at proxy server. Caching algorithm handles this problem. Several approaches have been proposed so far. Prefix caching, proposed by Sen et al. [10], is a special form of selective video caching, which involves caching only a group of consecutive frames at the beginning of the video sequence to smooth and reduce the bit-rate of VBR video. Wang et al. [7] proposed a video staging algorithm in, which prefetches to the proxy a portion of bits from the video frames whose size is larger than a pre-determined cut-off rate, to reduce the bandwidth in the server-proxy channel. Dan and Sitaram [12] proposed a Generalized Interval Caching (GIC) policy in, which caches short video objects as well as intervals or fractions of large video object. The policy orders all intervals in terms of increasing interval size. It allocates cache to as many of the intervals as possible. Hence, the GIC policy still maximizes the number of streams served from cache with a larger number video segments and video objects. Yu et al. [13] proposed QoS-adaptive proxy caching, which adapts fairly well to network bandwidth variations and achieves good quality under different network conditions by media-characteristicweighted replacement policy, network-condition-and-media-quality-adaptive resource-management mechanism, pre-fetching scheme and request and send-back

3 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx 3 scheduling algorithms. And, Miao and Ortega [6] proposed a scalable selective caching that is partial caching strategies specifically designed for streaming video. They proposed Selective Caching for QoS networks (SCQ) and Selective Caching for Best-effort networks (SCB). These algorithms are frame-wise caching schemes in which SCQ algorithm reduces the required maximum buffer size and SCB algorithm prevents underflow at the client. However, it is observed that the performance of caching algorithm generally depends on the relative frame positions in the time axis as well as the frame size under the general traffic condition. Hence, we consider an effective caching algorithm minimizing the required clientõs buffer size and the channel bandwidth between the remote original server and client, which is achieved by selecting cached frames minimizing the normalized buffer size defined in the followings. In the followings, it is assumed that the time delay and cost between proxy server and client is negligible compared with those between remote server and proxy server, and thus the cached data at the proxy server is almost instantly available for the display at the client. Thus, the client buffers for proxy server can be kept in a very small size. Consequently, the required clientõs buffer size in the proxy-to-client channel is negligible compared with that in the server-to-client channel. The logical system architecture under the consideration is shown in Fig. 1. This paper is organized as follows. Basic definitions are described in Section 2, problem formulation and details of proposed caching algorithm are presented in Section 3, experimental results are provided in Section 4, and finally concluding remarks are given in Section Basic definitions We assume that video consists of N frames, the size of each frame is R i bytes, and its temporal sampling rate is T s second (Typical values is 1/25 or 1/30 s). Hence the total size is calculated by R total ¼ XN i¼1 R i ; And let ~c denote the positions of cached frames (it is called the cached frame vector in the following), i.e., ~c ¼ðc 1 ; c 2...; c N Þ; Fig. 1. Logical system architecture under the consideration.

4 4 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx where c i indicates whether the ith frame is cached or not, which is defined by 0 if the ith frame is not cached; c i ¼ 1 if the ith frame is cached: Now the following condition must be satisfied when the available storage size of proxy server is M c. ~c ~R T 6 M c ; where ~R ¼ðR 1 ; R 2 ;...; R N Þ and the dot operator is the vector inner product. By the way, some of M c must be reserved for the instant display before the data from the remote original server arrive, that is, prefix caching is required for at least round trip time between remote original server and client. The required prefix caching size is denoted by M prefix. We also assume that the channel bandwidth is constant-bit-rate BW ch, and the initial latency, the time delay between the display time at client and the time that the transmission begins at the sender, is d, that is, R i is consumed for the display at time t = i. Generally speaking, BW ch must be larger than the average rate defined by BW avg = R t /NÆT s for the smooth display at the client since the compressed video traffic is burst as mentioned earlier. Now, the following equation must be satisfied to avoid the clientõs buffer underflow to cause the display time delay. BW ch P BW avg : For the simplicity, it is assumed that the client starts to display out at t = 0 and thus sender begins transmitting at t = d since the initial latency is d. The cumulative frame rate at time t, which means the video data consumption curve at the client at time t, is defined by SðtÞ ¼ Xt i¼0 R i : Now, BW ch ð~cþ and S ~c ðtþ indicate the required constant-bit-rate channel bandwidth and the cumulative frame rate at time t when the cached frame vector is ~c, respectively. Thus, S ~c ðtþ is defined by S ~c ðtþ ¼ Xt i¼0 ð1 c i ÞR i : And, the slope function is defined by L ~c ðtþ ¼ S ~cðtþ : t Since the client retrieves the cached frames from the proxy server at the time when those frames need to be displayed and it is assumed that the time delay is very short between proxy server and client, the condition for the smooth display at client can be described as follows: X t i¼ d BW ðiþ P S ~c ðtþ for all t 2½1; NŠ;

5 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx 5 where BW(i) is the channel bandwidth at the ith frameõs time. Actually, S ~c ðtþ is thought of as the video data consumption curve at the client when the cached frame vector is ~c while P t i¼ dbw ðiþ is the data supply curve from the server-to-client channel. P Under the constant bit rate (CBR) channel whose bandwidth is BW ch, t i¼ d BW ðiþ is simply calculated by BW ch(t + d). To avoid clientõs buffer underflow, the following condition must be satisfied: BW ch ð~cþ ¼max fl ~cðtþg; t 2½1; NŠ; 16t6N since BW ch ð~cþ P L ~c ðtþ, t 2 [1, N] must be satisfied. And, the time that the peak bandwidth is required is defined by t peak ¼ arg max fl ~cðtþg: 16t6N The time that the maximum buffer size is needed is defined by ( ) X t t max ¼ arg max BW ðiþ S ~c ðtþ : 16t6N i¼ d 3. Problem formulation and proposed caching algorithm In this scenario, we assume that server-to-proxy channel provides guaranteed constant bandwidth service, but the higher bandwidth service is provided at the higher cost. On the other hand, proxy-to-client channel is fast and reliable at the even lower and fixed price. Now, we address how to determine the cached frame vector~c minimizing the required clientõs buffer size and the channel bandwidth BW ch ð~cþ. As shown in Fig. 2, SCQ algorithm selects the frame at t peak, and then the results of the buffer occupancy and the channel bandwidth are shown in the figures. SCQ effectively reduces the channel bandwidth and the clientõs buffer size simultaneously as shown in Fig. 2 when the BW ch ð~cþ curve looks like almost convex, and thus t peak moves to t peak T s after caching the peak frame. But, this condition is generally not satisfied. Under the general traffic condition, the amounts of reduced buffer size and peak bandwidth depend both the frame size R i and the corresponding frame position as shown in Fig. 3. In this paper, we study the proxy caching problem under the generalized traffic condition. Now our problem is to determine ~c to minimize the required clientõs buffer size and the peak bandwidth simultaneously with constraints of proxy serverõs storage size and time delay. Thus, we can formulate the given problem as follows. Problem formulation. Determine ~c to minimize the required clientõs buffer size and the peak bandwidth subject to ~c prefix ~R T 6 M c M prefix ; d 6 d max ; where~c prefix is the indicator vector with 1 at the positions of prefix cached frames and d max is the tolerable maximum initial latency. As mentioned earlier, t max and t peak do not change when S ~c ðtþ looks like almost convex. However, it is observed that t max

6 6 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx Fig. 2. Performance of SCQ algorithm proposed in [6]. and t peak change after caching a frame when S ~c ðtþ is not generally convex as shown in Fig. 3. When the S ~c ðtþ is not convex as shown in the figure, the amounts of the decreased buffer size and the reduced bandwidth after caching the i 1 th frame are less than those after caching the i 2 th frame although the peak bandwidth occurs at the

7 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx 7 Fig. 3. An example when the cumulative frame rate curve is not convex. i 1 th frame. The reason is that the frame position requiring the peak bandwidth change from t peak to t 0 peak. Furthermore, it is uncertain that caching a frame with a larger size is more effect than caching several frames with a small size. It means that the reduced amount of clientõs buffer size relies on both the relative frame position in the time axis and the frame size. As a solution, we consider the normalized buffer size that is the decreased maximum buffer size after caching a frame divided by its frame size R i, which is defined by B norm ð~c aft Þ ¼ Bð~c befþ Bð~c aft Þ ; R i where Bð~c bef Þ and Bð~c aft Þ are the maximum buffer size before and after the kth frame caching, respectively (The only difference between ~c aft and ~c bef is that c k = 1 and c k = 0, respectively). That is, Bð~c bef Þ¼max fbw chð~c bef Þ S ~cbef ðtþg; 16i6N Bð~c aft Þ¼max 16i6N fbw chð~c aft Þ S ~caft ðtþg: Table 1 Statistical properties of test MPEG trace files Trace files Minimum value (Bytes) Maximum value (Bytes) Average (Bytes) Standard deviation (Bytes) Star Wars , Terminator ,

8 8 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx Hence, B norm ð~c aft Þ means the decreased buffer size per 1 byte when caching the ith frame. And several frames may have same normalized buffer size. In this case, we choose a frame to maximally decrease the required channel bandwidth. Actually, Table 2 Comparison of cached frame sequences between SCQ and proposed algorithms when test video sequence is Star Wars Method Sequence of cached frames SCQ 0,1,2,3,4,960,948,936,924,915,912,909,906,900,897,894,891,888,885,882,879,876,873,870,867, 864,861,858,855,853,852,850,849,848,847,846,845,844,843,842,840,837,834,832,831,828,826, 825,823,822,821,820,819,817,816,815,814,813,810,807,804,803,802,801,798,795,793,792,791, 789,788,787,786,784,783,781,780,777,774,771,770,768,765,764,763,762,760,759,758,757,756, 753,750,747,744,741,740,739,738,735,733,732,729,728,727,726,723,720,717,714,711,709,708, 707,705,704,703,702,701,700,699,698,697,696,693,690,687,684,681,678,676,675,674,673,672, 669,668,667,666,663,660,657,654,651,648,645,642,639,636,634,633,632,631,630,627,624,623, 621,620,619,618,617,616,615,614,613,612,611,610,609,607,606,605,604,603,602,601,600,599, 598,597,596,595,594,593,592,591,588,587,586,585,583,582,581,580,579,578,577,576,575,574, 573,572,571,570,569,568,567,565,564,562,561,558,557,556,555,554,553,552,551,550,549,548, 547,546,545,544,543,542,541,540,539,538,537,534,531,528,527,526,525,524,523,522,521,520, 519,518,517,516,515,514,513,512,511,510,509,508,507,506,504,503,502,501,500,499,498,497, 496,495,494,493,492,491,490,489,487,486,485,484,483,482,481,480,479,478,477,476,475,474, 472,471,470,468,467,465,464,463,462,461,460,459,458,457,456,455,454,453,452,451,450,449, 448,447,444,442,441,440,439,438,436,435,433,432,431,430,429,428,427,426,425,424,423,422, 421,420,4935,4933,4932,4929,4928,4927,4926,4925,4924,4923,4920,4919,4918,4917,4908,419, 418,417,4907,4906,4905,4902,4899,4896,416,414,4894,4893,4892,4890,4887,411,4884,4883, 4882,408,4881,4880,4878,4875,4872,4869,4867,4866,4865,4864,4863,4862,4861,4860,4859, 4858,4857,4856,4855,4854,4853,4852,4851,4850,4849,4848,4847,4846,4845, Proposed algorithm 0,1,2,3,4,816,852,792,828,768,864,804,612,876,840,756,780,708,744,588,576,600,636,888,624, 732,696,684,552,672,528,648,900,540,516,720,564,492,912,660,480,468,924,504,936,456,360, 372,420,432,948,384,960,444,408,348,336,396,972,324,984,312,300,288,276,264,252,240,216, 996,228,204,120,849,132,846,144,822,108,843,825,858,855,168,606,759,1008,156,819,789,765, 729,96,762,192,786,735,615,180,813,771,609,738,699,1020,618,705,798,621,795,675,603,582, 861,810,831,84,579,801,834,783,585,774,1032,741,546,678,867,711,558,549,870,573,726,702, 681,2472,882,2616,2388,885,2676,1044,1056,522,2808,1068,669,2820,1080,591,2772,2136,879, 2832,2400,837,2460,2424,753,2844,2436,570,2796,2448,693,2592,2160,555,3732,2568,594, 2784,2412,777,3720,2580,747,2604,2652,891,2664,3060,807,4680,3132,714,3576,3144,519, 4668,3048,723,3156,3036,663,3564,3168,72,3072,3120,1092,666,4788,1104,897,3228,2148,873, 3552,3240,687,3084,3252,717,3468,3096,561,3204,4848,633,3024,3456,750,3108,3000,1116, 483,4836,1128,630,3504,2484,627,3516,3528,543,4740,3180,459,3012,3780,24,3768,4656,909, 3540,2880,462,3480,3336,1140,486,2988,1152,525,2649,4884,597,3444,3300,489,3888,3312, 894,3324,3432,1164,513,3192,1956,639,3492,2700,510,3216,3912,36,2976,4041,651,4752,4824, 1176,48,4056,1980,369,2712,4152,906,4704,3420,915,4872,3408,1188,645,4896,1968,654,4212, 2520,60,3600,3588,453,4860,2892,1200,903,4692,1992,537,2628,3717,2324,567,2724,2928, 2325,531,2904,2328,465,4716,2496,642,4644,2856,2336,534,2868,4164,657,4908,2688,3804, 366,4284,2340,450,2556,3864,495,4272,2562,3805,690,4830,3876,927,3276,3936,12,4632,3264, 3806,429,4728,3882,426,3396,4782,3807,477,4689,2352,498,4800,3900,363,2916,4620,3808, 918,3672,3867,357,4046,4734,2343,921,3288,3915,501,3660,3948,933,4296,2532,3809,939, 4299,3918,423,2736,4224,3810,930, The underlined numbers in the Tables indicate the prefix caching.

9 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx 9 Table 3 Comparison of cached frame sequences between SCQ and proposed algorithms when test video sequence is Terminator-2 Method Sequence of cached frames SCQ 0,1,2,3,4,1224,1218,1164,1158,1157,1156,1155,1154,1153,1152,1150,1149,1148,1147,1146, 1145,1144,1143,1140,1137,1134,1128,1116,1110,1107,1105,1104,1103,1102,1101,1100,1099, 1098,1097,1095,1094,1093,1092,1091,1090,1089,1086,1085,1084,1083,1082,1081,1080,1078, 1077,1076,1075,1074,1072,1071,1068,1065,1062,1059,1057,1056,1053,1050,1049,1048,1047, 1044,1043,1041,1038,1035,1032,126,975,972,963,961,960,957,954,951,948,840,831,828,816, 813,120,810,807,804,803,802,795,793,792,791,790,789,786,516,372,117,115,114,785,784,783, 513,504,113,112,111,110,109,108,782,781,780,501,500,499,498,492,486,369,366,363,360,107, 106,105,104,103,102,101,779,778,777,100,99,776,775,774,773,772,357,354,348,98,97,96,5907, 5905,5904,771,5903,5901,5900,5899,5898,5897,5896,5895,5894,5886,5884,5883,5882,5881, 5880,5823,5820,5808,5805,770,5804,5803,5802,5799,5796,5784,5781,5778,5775,5772,4008, 768,4005,3999,3996,3993,3990,3987,3984,765,763,762,3981,3978,3972,761,760,347,345,342, 339,338,336,3969,3966,3963,3960,3951,3948,3945,3942,3939,3936,3933,3930,3927,3924,333, 3922,3921,3918,3915,3912,3909,3906,3903,3901,3900,3897,3894,331,330,3891,3890,3889, 3888,95,3887,3886,3885,3884,3883,3882,3881,3880,94,3879,3878,3877,3876,3875,3874,3873, 93,3872,3871,3870,3867,3864,2475,2473,2472,2471,2470,2469,2467,2466,759,756,2465,2464, 2463,754,753,2461,750,2460,749,747,329,328,327,5769,5767,5766,5765,5764,5763,3861,3858, 3810,3807,3804,2457,2454,2452,2451,2450,2449,92,2448,2445,2443,2442,2441,2440,2439,2280, 746,326,91,5762,5761,2268,2259,2256,2250,2247,2244,90,2232,5760,5759,2231,2230,2229, 2226,2220,2210,2208,745,744,5758,5757,5756,5755,5754,5751,5750,5749,5748,2196,5745,2193, 325,5744,5743,5742,5741,5740,5739,2192,324,5738,5737,5736,5735,5734,5733,2191,2184,5732, 5731,5730,2181,2178,2172,89,5729,5728,5727,5726,5725,5724,2169,2166,2163,2160,2151,88,87, 5723,5722,5721,2150,2149,2148,5720,5719, Proposed algorithm 0,1,2,3,4,545,1163,236,1061,240,837,181,204,645,810,864,979,1202,585,1040,695,471,47,876, 652,638,1154,952,604,908,863,900,650,1075,168,187,375,1200,18,300,628,890,189,167,432, 1168,492,850,744,480,474,943,308,114,758,511,398,667,674,1175,42,444,507,483,368,468, 1149,804,365,975,62,914,912,296,1164,69,401,927,633,1124,1121,843,1018,420,991,1140,32, 144,35,414,264,658,904,86,716,1203,737,836,708,1005,819,12,625,702,473,573,318,854,1029, 590,840,17,968,305,1232,373,516,46,360,656,399,924,155,785,75,999,1192,278,353,852,1067, 596,523,60,224,127,182,203,218,848,448,994,393,178,903,223,883,553,679,653,11,668,1997, 506,128,1310,1143,2253,61,2216,191,2338,410,280,505,1080,1466,1859,1661,2335,2340,527, 2333,486,1020,2653,2654,1522,2837,2278,2293,1384,2648,2642,544,3864,1044,2651,2477,2626, 2441,1764,2644,2650,3047,82,776,2576,2657,3210,3948,2660,2656,3734,1276,176,131,1908, 1116,1770,3972,2603,2283,2189,3824,3836,315,3912,422,1314,1866,3618,1083,2414,2641,2449, 2645,2658,2761,1056,3799,3627,3223,2527,2649,1941,1145,4176,1394,2659,2647,1032,2474, 4183,636,1371,4220,5581,2593,2662,2596,4922,4066,2090,5864,1176,5198,3012,548,2094, 5234,2456,23,4896,1684,2699,120,4790,3640,3478,3337,108,3080,1738,4151,2059,4239,5565, 2663,2646,2600,2605,2579,2570,2037,4452,1279,2139,5819,4377,3897,1252,4670,4799,2031, 5168,1148,4915,2970,4388,3672,644,4236,16,1306,4203,761,3811,4271,1488,5824,4247,6201, 926,2887,6187,4418,5258,5268,2816,2843,276,19,3020,5053,3240,4104,1439,4206,99,1596, 5417,654,1356,4114,4479,5702,4665,1704,5950,5789,4547,460,2247,388,4314,3596,2215,2891, 2343,4615,2859,192,4296,5105,4055,2171,5804,2429,1302,987,6089,103,5701,1709,2655,2599, 4199,2236,2212,2336,5534,2100,2363,1432,3960,5866,50,6161,1047,3575,5011,5661,2005,1105, 624,891,5718,3291,5432,1248,3106,5796,5807,294,2880,5778,5733,2571,3907, The underlined numbers in the Tables indicate the prefix caching. we need to search the frame to be cached in the interval 1 6 i 6 t peak instead of the whole interval 1 6 i 6 N. The reason is that caching any frames after the t peak frame does not decrease the channel bandwidth and the required maximum buffer size. As a

10 10 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx result, the required computational complexity is significantly reduced. Therefore, the proposed caching algorithm can be summarized as follows: Rule 1. Cache the frame maximizing B norm ð~c aft Þ for 1 6 i 6 t peak. Rule 2. When several frames have the same normalized buffer size, cache the frame minimizing BW ch ð~c aft Þ L ~caft ðtþ. Fig. 4. Performance comparison among prefix, SCQ and proposed caching algorithms when test trace file is Star Wars: (A) maximum buffer size and (B) channel bandwidth.

11 4. Experiment results H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx 11 In the experiment, the test trace files [14] are Star Wars (240*352 size) and Terminator-2 (QCIF size) encoded by MPEG-1, whose lengths are 40,000 frames. The encoding structure is IBBPBBPBBPBB (i.e., 1GOP consists of 12 frames) and I- frames, P-frames, and B-frames are encoded with quantization parameters 10, 14, and 18, respectively. The encoding frame rate is 25 frames per second. As a result, Fig. 5. Performance comparison among prefix, SCQ and proposed caching algorithms when test trace file is Terminator-2: (A) maximum buffer size and (B) channel bandwidth.

12 12 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx the output traffics are variable-bit-rate and their statistical properties are summarized in Table 1. During the experiment, the initial latency is set to about 167 ms and thus the corresponding prefix caching size (M prefix ) is set to the size of the first five frames as shown Table 2 and 3 (The underlined numbers in the Tables indicate the prefix caching). The required maximum buffer size at the client and the channel bandwidth are employed as performance measures. The experimental results are presented in Tables 2 and 3 and Figs Tables 2 and 3 show the cached frame se- Fig. 6. Performance comparison between SCQ and proposed caching algorithms when caching ratio is relatively low (Test trace file is Star Wars): (A) maximum buffer size and (B) channel bandwidth.

13 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx 13 quences of SCQ and proposed algorithms. In these tables, the remarkable differences are observed. The corresponding performance is given in Figs It is observed that the proposed algorithm can significantly reduce the clientõs maximum buffer size compared with prefix caching algorithm and SCQ algorithm as shown in Figs. 4 7A. The difference becomes more dominant when the percentage of cached video is relatively low. As shown in Fig. 6A, the buffer size can be maximally reduced by 35.6% when about 2.7% of Terminator-2 traffic is cached compared with SCQ. Fig. 7. Performance comparison between SCQ and proposed caching algorithms when caching ratio is relatively low (Test trace file is Terminator-2): (A) maximum buffer size and (B) channel bandwidth.

14 14 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx Furthermore, it is observed that the maximum buffer size of the proposed algorithm almost monotonically decreases while that of SCQ sometimes increases in a small range as the percentage of cached video increases. It means that the proposed algorithm works more efficiently than SCQ. In addition, we also observed that the required channel bandwidth is quite a little reduced compared with the prefix caching and SCQ algorithms when the percentage of cached video is relatively low as shown in Figs. 4 7B. Like clientõs buffer size, the performance improvement is more remarkable when the percentage of cached video is relatively low. As shown in Fig. 7B, the bandwidth can be maximally reduced by 12.2% when about 7.03% of Star Wars traffic is cached compared with SCQ. 5. Conclusion In this paper, we have proposed an effective scalable caching algorithm of the proxy server with the finite storage size. It is observed that the performance of caching algorithm depends on both the relative frame position in the time axis and the frame size under the general traffic condition. The proposed caching algorithm has considered this observation by using the normalized buffer size as a criterion to determine which frame is cached. By experimental results, we have shown that the proposed algorithm can minimize clientõs buffer size and channel bandwidth. Actually, the proposed approach is based on the full search method, and the computational complexity is reduced by effectively selecting candidates of peak points. Finally, the proposed algorithm is also scalable since we do not need to determine the caching sequences when the total caching space size changes. References [1] ISO/IEC (MPEG-2): Generic coding of moving pictures and associated audio information, Nov [2] ISO/IEC JTC1/SC29/WG11, Overview of the MPEG-4 standard, ISO/IEC JTC1/SC29/WG11 N4030, March [3] ITU-T Recommendation H.261: Video codec audiovisual service at p*64kbps, March [4] ITU-T Recommendation H.263 version 2, Video coding for low bitrate communication, Jan [5] Joint Video Team of ISO/IEC MPEG and ITU-T VCEG, JVT-G050, Draft ITU-T recommendation and final draft international standard of joint video specification (ITU-T Rec. H.264/ISO/IEC AVC), [6] Z. Miao, A. Ortega, Scalable proxy caching of video under storage constraints, IEEE Journal of Selected Areas in Communications 20 (7) (2002) [7] Z. Zhang, Y. Wang, D.H.C. Du, Video staging: A proxy-server-based approach to end-to-end video delivery over wide-area networks, IEEE/ACM Transactions on Networking 8 (4) (2000) [8] L. Rizzo, L. Vicisano, Replacement policies for a proxy cache, IEEE/ACM Transaction on Networking 8 (4) (2000) [9] J. Shim, P. Scheuermann, R. Vingralek, Proxy cache algorithms: design, implementation, and performance, IEEE Transactions on Knowledge and Data Engineering 11 (4) (1999) [10] S. Sen, J. Rexford, D. Towsley, Proxy prefix caching for multimedia streams, in: Proceedings of IEEE Infocom. 99, New York, USA, 1999.

15 H.R. Oh, H. Song / J. Vis. Commun. Image R. xxx (2005) xxx xxx 15 [11] Z. Zhang, J. Kurose, J. Salehi, D. Towsley, Traffic smoothing, statistical multiplexing and call admission control for stored video, IEEE Journal on Selected Areas in Communication 15 (6) (1997) [12] A. Dan, D. Sitaram, A generalized interval caching policy for mixed interactive and long video workloads, Proceedings of SPIE 2667 (1996) [13] F. Yu., Q. Zhang., W. Zhu, QoS-adaptive proxy caching for multimedia streaming over the internet, IEEE Transactions on Circuits and Systems for Video Technology 13 (3) (2003) [14] KAIST. Available from: <