I. INTRODUCTION. A. Background

Transcription

1 A Local Area Content Delivery Network with Web Prefetching L. R. Ariyasinghe, C. Wickramasinghe, P. M. A. B. Samarakoon, U. B. P. Perera, R. A. P. Buddhika, and M. N. Wijesundara Abstract The exponential growth of internet has resulted in an estimated 2.2 billion users accessing more than 600 million websites with millions of terra bytes of data. Internet users increasingly demand high bandwidth content such as HD and 3D video. This strains the access networks being unable to expand at the same rate as the demand mostly due to financial constraints than technical constraints. Techniques such as web caching and web pre-fetching were developed in order to reduce the user perceived latency when accessing popular content. Content Delivery Networks (CDNs) such as Akamai provide the advantage of better performance and high availability through a network of distributed servers hosting a large portion of the internet content by offloading traffic directly served from the content provider's origin infrastructure. In this paper, the authors attempt to combine these three techniques namely; prefetching, caching and the CDN approach to further reduce the user perceived delay in accessing the web. Through a real implementation the performance of the proposed system is compared with existing architectures. Keywords CDN, Web Caching, Web Prefetching, Proxy Caching, Distributed Storage. A. Background I. INTRODUCTION With the increased use of internet for communication, business, education and entertainment, the users increasingly demand multimedia rich content delivered on demand and without delays. This sudden and peak demand for high bandwidth content often congests access networks, increasing the user perceived delay. This degrades the overall user experience. Web caching is a technique that stores frequently requested content closer to the user. Such content can be served faster during repeat requests. Caching can be subdivided in to proxy caching [1] and browser caching [2]. While browser caching deals with a single user, proxy caching often caters to a large set of users. One drawback in both types of caching is that the first request to any content will always be served by the origin server. Therefore, the first request will always be served slower than the subsequent requests. Web Prefetching is a technique which attempts to solve this drawback by predicting the future requests and by fetching the web contents to the cache prior to the user requests. CDNs [3,4] have emerged as another technique often used by the content provider to host the content in a globally distributed set of servers known as CDN surrogates, so that the end user will automatically be redirected to the closest server for faster service. The CDNs have evolved as a service provided by a third party to the content provider, in order to improve scalability and performance in delivering the content. However, a CDN node chosen by the content provider as closest or best suited for a particular client may not always deliver content as fast as expected. L.R.Ariyasinghe, C.Wickramasinghe, P.M.A.B Samarakoon, U.B.P Perera, R.A.PrabhathBuddhika and M.N.Wijesundaraare with the Department of Electronic & Computer Engineering, Sri Lanka Institute of Information Technology, Malabe, Sri Lanka. (dcn09c3-0647@my.sliit.lk; dcn09c3-0536@ my.sliit.lk; dcn09c3-0568@my.sliit.lk; dcn09c4-0806@my.sliit.lk; prabhath.b@sliit.lk; 1 This is because all CDN nodes exist outside the LAN of any particular user. Therefore, the internet connection speed often becomes the bottleneck, even for content hosted on CDNs. In the paper, authors attempt to extract the advantages of Web Caching, Web Prefetching and Content Delivery Networks by proposing a novel architecture which introduces a Local Area Content Delivery Network (LACDN). B. The Drawbacks in Generic Proxy Caching Approach 1) Limited cache capacity:although, theoretically unlimited cache capacity is available, in a practical scenario cache size of a proxy server is restricted to a certain maximum. When the capacityincreases, the performance of the cache will get degraded. This is due to the management and search overhead of the cached content. 2) Processing and network delays: The proxy cache has to process requests to new content as well as cached content. Therefore, when the cache size is larger, a longer search delay will be added to all requests. Both the WAN and the LAN linksof the proxy cache can get congested adding to the user perceived delay. 3) Absence of streaming media caching facility:although the popular proxy cache servers such as Squid [5] perform the caching of static content well, most servers will not cache streaming media and video content due to the size and the need to stream the data on demand which requires real-time processing. Although there are several third party applications can be found on the internet for squid to perform this type of caching, the reliability of those applications [6,7] is unsuitable for enterprise use. Squid developers have already begun developing squid to perform video data caching, this however is still experimental.since IIS can be enabled for streaming media caching up to some level, it is been employed as a reverse proxy which reduce the load in the origin server side. Not in the LAN side.

2 We aim to overcome these drawbacks in traditional proxy caches by introducing a Local Area Content Delivery Network. II. PROPOSED LOCAL AREA CONTENT DELIVERY NETWORK ARCHITECTURE The proposed Local Area Content Delivery Network mainly consists of three sub systems. Those sub modules can be represented as; 1. CDN Main Node with Web Prefetching Module 2. CDN Surrogate 3. Proxy Cache Server. A. Operation of the Local Area Content Delivery Network Architecture When a new client HTTP request comes to the CDN Main Node via the proxy cache server, the main node will search for the requested URL by matching with the prefetched URLs. If there is a match, it is a CDN hit. Otherwise it is a CDN miss. In any case CDN Main Node will forward the request to the origin server. If it is a CDN hit, when the initial HTTP response (which contains the initial HTML tags of the page) arrives from the origin server, CDN Main Node will accept the HTTP response and modify the original HTTP response by replacing all the original path names of the image URLs, JavaScript URLs and CSS URLs, by the path names of the relevant local surrogates, where those images, scripts and CSS documents are already prefetched and cached in. Then this modified responseis forwarded to the proxy cache server which will cache this initial modified HTTP response and forward it to the requesting client. Client browser will go through the modified response and request all the contents of the web page from the relevant local CDN surrogate directly. Fig. 1.Proposed LACDN architecture The CDN main node acts as the control node where key decisions are taken. CDN surrogates serve as the main storage facility for the proposing system. The surrogate acts as the cache server as well as the web server in the new architecture. The proposed architecture can accommodate any number of CDN surrogates. The Web Prefetching Module running on the CDN Main Node downloads web contents that will be requested in the future according to a pre-defined algorithm. Such contents, once downloaded, are stored in a CDN surrogate according to a chosen distribution algorithm by the CDN Main Node. The CDN Main Node has direct access to the internet in addition to Local Area Network (LAN) access. A proxy cache is situated in between the CDN Main Node and the client nodes. All the client browsers are configured to direct any requests to outside servers to the proxy cache server. For any requests to local servers, browsers will bypass the proxy cache server. If it is a CDN miss, the request is forwarded to the origin server. The response is forwarded to the proxy cache server which will cache the response and forward it to the client. If there is a proxy cache hit, irrespective of the CDN hit or miss status, the proxy cache will serve the client. The initial request is forwarded to the origin in order to verify the freshness of the content already available in the CDN surrogates.when, a subsequent request comes to the proxy cache server to fetch the same content again, proxy cache server will respond using the modified initial HTML response,previously received from the CDN Main Node during the first transaction. In such cases, only the initial HTML page is served by the proxy. Thereafter, embedded contents of the page will be served by the CDN surrogates. This significantly reduces the load on the proxy server. In addition, since the size of such HTML pages are much smaller compared to embedded contents such as images, CSS scripts and Java scripts, the capacity required on the proxy cache is relatively less.figure 2 depicts the operation of the algorithm. 2

3 = Total processing delay of CDN main node to fetch the entire page = Packet modifying delay = Total processing delay of squid to fetch the entire page Here, can be defined as (2) Where, n is the total number of HTTP transactions to fetch the entire page is the round trip time of the i th HTTP transaction ( ) (3) = Delay of the CDN main node for the i th HTTP transaction (4) = Number of tags in the initial HTML page = Average time taken (in seconds) to rewrite a one tag ( ) (5) = Delay of squid for the i th HTTP transaction Therefore, equation can be represented using the following ( ) ( ) ( ) (6) This mathematical representation can be used to model five different situations in a network infrastructure, including the newly proposed architecture as illustrated below. Those are the total delay ( ); 1. for a direct request from origin without having the browser cache, proxy cache or CDN main node 2. for a direct request from origin having only the browser cache enabled, but no proxy cache or CDN main node 3. for a request with the squid proxy cache server only 4. for a request with proxy cache and the CDN main node but with a proxy miss and acdn miss and 5. for a request with proxy cache with the CDN main node with a proxy miss and a CDN hit Fig. 2.Algorithm of the LACDN architecture The total delay taken to load the whole page in the client browser ( ), (in response to the initial request, squid cache miss will be there)can be represented mathematically as a function of delays added by the proxy cache server, CDN main node and the URL re-writing process. For the first two scenarios, ( ) will equal to because in those test cases, and values are becoming zero. For the next three scenarios, Table 1represents application of the proposed equation in order to calculate ( ) (1) = Total round trip time to fetch the entire page 3

4 TABLE 1 MODELING OF THE PERFORMANCE EVALUATION EQUATION Testing Scenario Squid cache only Squid + CDN (Squid miss and CDN miss) Squid + CDN (Squid miss and CDN hit) Analysis III. WEB PREFETCHING Based on different heuristics web pre-fetching predicts web objects expected to be requested in the near future, but these objects are not yet requested by the users. Then these predicted web objects will be fetched from the origin server and placed in the local cache of the network. Ultimately web pre-fetching helps to build an effective web cache by increasing the cache hit ratio and reducing the end user experienced latency.the prefetching techniques can be implemented on server, proxy or client side. When summarizing prefetching according based on the location, several advantages and drawbacks can be found in the three approaches [8]. However in recent years, considerable attention has been paid to proxy-based prefetching since it is more effective and more accurate in predicting the correlated pages of many websites in the similar interests for more homogeneous users [9,10,11]. A. Web Content Prefetching Module Delay for the initial request Within the proposed architecture, web content prefetching module and the CDN main node runs in the same machine as separate processes. For the prefetching purpose, access log of the proxy server will be used. A special configuration file will be provided for configuring the time to start the content prefetching. Since any LAN is having a considerable idle time with in the day, this time can be used for the web prefetching process to run. Therefore the impact on network performance raised because of the high bandwidth consumption of web prefetching can be minimized. At the pre-configured time, content prefetching module will examine the proxy cache server s access log 4 to find the web pages to be prefetched. This selection will be done according to the proposed prefetching policy. Then the web contents of the selected pages will be fetched from the origin servers and cached within the LAN surrogates for future use. Inside each surrogate, a surrogate log will be maintained, which contains all the key information of the cached web contents. Each time when a new web object (content of a web page) is being cached, surrogate log will get updated with the relevant web object information. After prefetching all the contents of a given web page, a consolidated surrogate log (which is in the CDN main node machine) will be updated with the prefetched page URL. When prefetching a CSS of a particular web page, using a special regular expression module will intelligently rewrite all the image URL paths of the CSS, using the path of the appropriate surrogate where all the images of that web page are cached in. B. Distribution Algorithm for the Web Content Prefetching Module Two distribution algorithms are proposed for the prefetched web contents to be distributed among the surrogates. 1) Distribution based on the extension of the web object name:when prefetching the contents (web objects) of a given web page, the relevant objects can be distributed among the LAN surrogates based on the extension of the web object name. Following example extensions can be catered through the proposed algorithm. Image extensions:.jpg,.png,.gif,.svg Script and Style Sheet extensions:.css,.js The algorithm will not get limited to the above mentioned extensions. It can cater up to n number of different extensions via n number of surrogates. A special configuration file will be provided for the users to configure relevant extension names along with the paths of the surrogates. When non-configured extensions appear in the prefetching set, algorithm will follow a generic rule to cache those contents in a common surrogate. Path of that common surrogate is also needed to be configured, using a special key word called ANY with the relevant surrogate path. 2) Distribution based on the given domain name of the page URL: When the prefetch occurs, the prefetching contents can be distributed among the surrogates based on the given domain name of the page URL. For this purpose also a configuration file will be provided in order to configure the relevant domain names along with the paths of the surrogates. Top level domain name of the prefetching page URLs or any of the secondary level domain names can be used for the distributing page s web content among the surrogates. If there is a page which is going to be prefetched, but none of the domain names of that page URL are configured in the configuration file, saying, the relevant surrogate to cache the contents of the page,

5 algorithm will use another generic rule to distribute the web contents. In such a case algorithm will check for the first letter of the top level domain of the page URL and follows the following generic distribution rule. 3) Generic Rule: Identify the first letter of the top-level domain name of the page URL;select the appropriate surrogate path based on the alphabetical order among the available n number of surrogates. C. Web Content Prefetching Policy Though, we are still working on a new web prefetching policy, for the moment we have used the following policy as the generic web prefetching policy. Always for the next pre-fetch, prefetching algorithm will fetch the contents of all the web pages requested in previous day of the same week. IV. DELIVERING OF YOUTUBE VIDEO DATA AS A CONTENT A. Need of integrating video content delivery Figure 3 presents the streaming media (video data) access distribution of the HTTP trace SLI76 proposed content delivery approach will mainly concern about YouTube video content delivery, instead of catering other video streaming sites. C. Proposed Video Content Delivery Architecture During a prefetch for normal web pages, content prefetching module will identify the YouTube videos which will belong to the predicted prefetching set according to the proposed web prefetching policy. Then all the identified videos will be prefetched from YouTube server and cached inside one of the given surrogate which is acting as a video streaming server. Similar to the web page content prefetching process, module will update the appropriate surrogate log and the consolidated surrogate log. When a new client requests comes via the proxy to the CDN main node for an already prefetched video, packet modifying function of the CDN main node will get triggered. Therefore the initial HTTP response packet from the YouTube server will be modified by the main node in a way, which will force the requesting client to fetch only the YouTube video from the relevant surrogate instead of requesting it again from the origin server. The modified initial HTTP response will be forwarded to the proxy, where the proxy will cache the modified packet and send it to the requesting client. Only the HTTP requests to fetch the rest of the page s contents will go to the YouTube server. Requests to fetch the video will be forwarded to the video streaming surrogate inside the LAN. Relatively high bandwidth consuming web content (video file) will be delivered from the local area CDN. Regarding the subsequent requests for the same video, proxy will cater the needs using the modified initial HTTP packet which has been already cached. Fig. 3: Video access distribution Results were taken by analyzing YouTube video requests from a unique sub set of LAN clients from the SLI76 access log. Clients were uniquely identified based on the requesting IP from the access log. Access distribution simply shows that the video accessing preference of a unique set of LAN users keeps overlapping, on the same set of videos repeatedly. Therefore the proposed content delivery system will be equipped with a proper video content delivery module in order to cater the user s video streaming need in an effective way compared to a generic proxy caching approach. B. Concern of YouTube Video Content Delivery YouTube stands as the most widely accessed video streaming site around the world [12,13,14]. According to YouTube s official statics page, over 800 million unique users visit YouTube each month and over 3 billion hours ofvideo are watched each month [15]. Therefore the 5 D. Importance of Integrating Video Content Delivery with Prefetching Currently there is no direct facility in squid to cache video data; different developers have introduced third party plug-ins for squid to perform YouTube video caching. Although they are having different success rates those applications can t create an effective web cache compared to the proposed architecture, because when pre-fetching integrates with web caching ultimately it will make an effective web cache which can have a higher cache hit ratio compared to ordinary web caching. Therefore the videos cached by the proposed architecture can have a higher hit ratio compared to the videos cached by above mentioned third party applications. V. RESEARCH FINDINGS For the initial experimental analysis of the system, we have taken a HTTP trace from the student proxy access log of our institute. A. Nature of the Trace In this experimental simulation, it is assumed that each user is accessing the web from a dedicated machine.

6 Therefore, each user is having a separate browser cache. No information is been shared between the browser caches. Trace TABLE 2 TRACE SLI76 ANALYSIS SLI76 Total Requests Sum of distinct requests from each user 3913 Therefore the Hit Ratio for the trace SLI76 can be taken from the following equation So the Hit Ratio comes for the trace SLI76 is: 61.01% For the taken SLI76 trace, Figure 3 represents the size distribution of the tested web objects. (7) Total size of the requests: MB, in the scenario 1 without having any caching facility, (only the RTT) total time (in seconds) taken to replay the HTTP requests in trace SLI76: s Squid only TABLE 3 EXPERIMENTAL RESULTS FOR TRACE SLI76 For the 2 nd, 3 rd and 4 th scenarios, times taken for replays are taken as a summation Summation of the initial requests replay duration can be represented.as: cache Squid+CDN (Squid Miss and CDN Miss) Squid+CDN (Squid Miss and CDN Hit) s s s (8) If we take the probability of a CDN Hit as P, proposed architecture can be evaluated for two extreme cases. If P=1, (Best case), response time improvement for initial requests can be calculated as: If P=0, (Worst case), extra delay added by the CDN main node for initial requests can be calculated as: (9) (10) Fig. 4.Web objects size distribution The proposed content delivery architecture is tested for the HTTP trace SLI76 and results were obtained using four testing scenarios. 1. Only having the direct connection (browser cached also disabled, only the RTT is there) 2. Squid cache only 3. Squid proxy with the CDN (Squid miss and CDN miss) 4. Squid proxy with the CDN (Squid miss and CDN hit) The event, CDN hit can be defined as a content hit and the event, CDN no hit can be defined as a content miss. Therefore it s clear that, for the initial requests new architecture will achieve a speed improvement of 82.75%, when P=1. If P becomes 0, extra delay added by the system will become 1.79% compared to the squid only approach. For the sub sequent requests, performance will depend on the local network performance including the load of the proxy server (squid).andthesurrogates. B. Reduction of the Caching Overhead In the squid only approach, squid will cache all the contents (web objects) of the cacheable web pages including the initial HTML pages. Therefore, if squid only architecture is employed as the caching mechanism to cache the responses of the above mentioned HTTP trace, Total cache size of squid will be: KB (291.98MB) 6

7 In the proposing architecture, if all the contents of the pages in the trace SLI76 are cached in the surrogates and if the probability of the content hit ratio (P) is taken as 1 (all the contents are requested), then only the initial HTML pages (modified initial HTML responses) will be cached in squid. Therefore, in the scenario two, Squid s total cache size will be: KB. Ultimately, the total cache size reduction will be: KB ( MB Cache size reduction performance will become: 98.66% C. Performance Statistics of the New Architecture for Browsing YouTube Videos We have measured the video download time with respect to the file size, comparing the new approach and the squid cache only approach. In the following graphs, points labeled as origin server represents the performance of the current squid only approach, while the CDN surrogate points represents the performance of the novel approach. ratio of the contents inside the surrogates, taken to be as 100%, the cache size reduction of squid will become 98.66%, compared to a squid only network architecture. Proposing architecture will clearly provide a large storage of caching capacity because of the multiple CDN surrogates, comparing with the squid only caching approach. Because, the new architecture is distributing the local network cache among multiple surrogates, load on the squid proxy will get reduced. Since the new approach is having multiple surrogates, if a one surrogate goes down, larger amount of the local network cache will be saved while removing SPOF (Single-Point-Of-Failure) regarding the local network web cache. A. Future Work 1) Designing the most appropriate web pre-fetching policy for the proposed content delivery architecture:the most critical point of the newly proposed CDN is the, web content prefetching policy. Clearly, the overall effectiveness of the local area CDN depends on the hit ratio for the contents inside the surrogates. If the content hit ratio increases, the degree of advantage gaining for the LAN users from the proposed system will increase with a significant amount. But if the content hit ratio becomes zero (worst case), the system s performance will degrade to the normal squid only performance. Therefore designing a web prefetching policy which increases the content hit ratio for the proposed network has become more important. Although the novel architecture is currently using a generic web prefetching policy which is based on the history based web prefetching category, we are currently working on a new prefetching policy, which is more towards content based web prefetching techniques based on an ANN (Automated Neural Network). Fig. 5. Experimental results of YouTube video browsing VI. CONCLUSIONS It is clear from the results that the proposed content delivery system will deliver a performance in between % and -1.72% for browsing web pages during the initial requests, when the content hit probability (P) is varying in between 1 and 0, compared to the generic squid only caching approach. However, when analyzing the simulation test results for the proposed web prefetching policies, in can be concluded that the best values for (P), floats near 0.7. Therefore it can be concluded that for the tested HTTP trace (SLI76) proposed architecture will obtain a speed improvement of % compared to the current squid cache only architecture. Regarding YouTube video data browsing the proposed architecture will increase the video download time in a comparatively very large amount, compared to the squid caching approach, in both the first and the subsequent requests categories, because in a YouTube page, most high bandwidth consuming content (video file) will be delivered internally form the LAN. Also, if the hit 7 2) Improving the cache replacement policy for the CDN surrogates:currently, the architecture is using generic LRU(Least Recently Used) as the cache replacement policy for the surrogates; we are looking forward to propose the most appropriate cache replacement policy by going through simulation experiments for various replacement policies like DWCG [16](Distributed Web Caching for Global Performance) LFU (Least Frequently Used), GDS (Greedy Dual Size) and GDSF (Greedy Dual Size Frequency). REFERENCES [1] Daniel Zeng, Fei-YueWangandMingkuan Liu. (2004, Aug.). Efficient Web Content Delivery Using Proxy Caching Techniques. [Online].IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS. 34(3).pp Available: [2]A Hierarchical Internet Object Cache, A. Chankhunthod, P.B. Danzig,C. Neerdaels, M. F. Schwartz, and K. J. Worrell.

8 [Online].Available: ml [3]A.Vakali, and G. Pallis, Content Delivery Networks: Status and Trends, IEEE Internet Computing, IEEE Computer Society, pp , November-December [4] MukaddimPathan.(2009, February).Content Delivery Network (CDN) Research.Directory.[Online]..Available:. /~apathan/cdns.html [5]Squid. (undated). squid-cache.org. [Online]. Available: [6]G. J. Conklin, G. S. Greenbaum, K. O. Lillevold, A. F. Lippman, and Y.A. Reznik, Video coding for streaming media delivery on the Internet, IEEE Transactions on Circuits and Systems for Video Technology, vol. 11, Mar [7]M. Hemy, U. Hengartner, P. Steenkiste, and T. Gross, MPEG system streams in best-effort networks, InProc.IEEE Packet Video 99, Apr [8] B. Zhijie, G. Zhimin, and J. Yu, A Survey of Web Prefetching, Journal of computer research and development, 46(2), (2009), pp [10] Q. Liu, Web Latency Reduction With Prefetching, PhD thesis, University of Western Ontario, London(2009). [11] Y.f. Huang and J.M. Hsu, Mining web logs to improve hit ratios of prefetching and caching. Knowledge-Based Systems, 21(1), (2008), pp [12] MrTop10. (undated). Top 10 Video Streaming Sites. [Online]. Available: [13]sproutinsights. (undated). 6 Great Video Sharing Sites for Business.[Online].Available: /08/video-sharing-sites-businesses/ [14]gizmo s.(undated). The Top 5 Video Streaming Websites.[Online]. Available: [15]YouTube.(undated).Statistics.[Online].Available: /t/press_statistics/ [16] Wijesundara, M.N., Tay, T.T., An object replacement strategy for global performance in distributed web caching, International Conference on Communication Technology., ICCT., 2003, pp [9] J. Domenech, J. A. Gil, J. Sahuquillo, and A. Pont, Using current web page structure to improve prefetching performance, Computer Network Journal, 54(9), (2010),