BI-DIRECTIONAL PERIPHERY CACHING SYSTEMS AND METHODS

Abstract: Systems and methods for obtaining about a hit rate of over about fifty (50 %) percent and up to as much as about eighty (80 %) percent for content request originating from end users that are part of at least one network, the content request being fulfilled by communications with a Cache Farm directly operatively communicating with the end user's network, the end user's network being one of at least two networks directly operatively connected to the Cache Farm. The caching systems and methods of the present application utilize a series of small (in terms of disk capacity) Cache Farms, transparent caches or "injectors" in communication the ISP network border router. The injectors may be clustered together at network access points (NAP). Networks at these NAPs then use WCCP protocol on their routers, or Layer 4 switches, to redirect their traffic to these clusters of injectors or Cache Farm. This redirection occurs over a dedicated high speed "cross connect" from the network border router to the injector farm or Cache Farm. The network border router is programmed to handle OUTBOUND content requests for its end users, and INBOUND content requests for its content provider customers. For the content that is not located on the injector Cache Farm, the injector Cache Farm will communicate with a Central Cache to determine if the Central Cache has the requested content. There is at least about a seventy five (75 %) percent chance, according to the systems and methods of the present application that the requested content will be cached or stored on the Central Cache and thus the end user receives the requested content without use of a NAP or electronic traffic over an Internet backbone.

Description: Bi-directional Periphery Caching Systems and Methods Background of the Invention The present patent application relates generally to caching systems and methods, more particularly, to bi-directional periphery caching systems, which utilize means, such as, for example, small transparent caches, proxy caches or equivalents that perform substantially the same function, for injecting queries or content requests into a Central Cache and, even more particularly, to systems and methods for increasing the hit rate of content inquiries without increasing the external bandwidth of an end user (Internet Service Provider, "ISP") for the content of an Internet site or a content site by using a Cache Farm and a sibling or Central Cache and, most particularly, to systems and methods wherein from about eight percent (8%) to as much as about fifty (50%) percent of the most accessed content is stored in the Cache Farm and about sixty (60%) percent of the remaining most accessed content is stored in the Central Cache. As defined in the present application, an HTTP request is: "Short for Hyper Text Transfer Protocol, the underlying protocol used by the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions World Wide Web servers and browsers (such as, for example, Netscape or Internet Explorer web browsers) should take in response to various commands. For example, when you enter a Uniform Resources Locator (URL) in your browser, this actually sends an HTTP command to the World Wide Web server directing it to fetch and transmit the requested World Wide Web page." as defined at http://www.pswebopaedia.com/, the disclosure of which is herein incorporated by reference. As defined in RFC 1983 (http://www.cis.ohio-state.edu htbin/rfc/rfcl983.html, the disclosure of which is herein incorporated by reference) bandwidth is "Technically, the difference, in Hertz (Hz), between the highest and lowest frequencies of a transmission channel." However, as more typically used, "bandwidth is the amount of data or content that can be sent through a given communications circuit." For our purposes and as used in this application, we refer to the latter definition, the amount of data or content that can be sent through a given communications circuit. Most Internet users take for granted that when a piece of information is sent across the Internet, it will always reach its intended destination. However, the process of sending and receiving that information is remarkably complex. When information is sent across the Internet, the Transmission Control Protocol (TCP) first breaks the information up into packets. The sending computer sends those packets to a local network, Internet service provider (ISP), or online service. From there, the packets travel through many levels of networks, computers, and communications lines before they reach their final destination, which may be across town or around the world. A variety of hardware processes those packets and routes them to their proper destinations. This hardware is designed to transmit data between networks and makes up much of the glue that holds the Internet together. Five of the most important pieces of hardware are switches, hubs, bridges, gateways, repeaters and routers. Switches are important because they link computers and networks together, and allow the possibility of varying the route of traffic. Bridges link local area networks (LANs) with one another. They enable data destined for another LAN to be sent there, while keeping local data inside its own network. Gateways are similar to bridges, but they also translate data from one kind of network to another kind of network. When data travels across the Internet, it often crosses great distances, which can be a problem because the signal sending the data can weaken over the distance. To solve the problem, repeaters amplify the data at intervals so the signal does not weaken. Routers play a key role in managing Internet traffic. The routers job is to make sure the packets are sent to the proper destination. If data is being transferred among computers that are on the same LAN, routers are seldom needed because the network itself can handle its internal traffic. Routers come into play when the data is sent between two different networks. Routers examine packets to determine their destination. They take into account the volume of activity on the Internet, and they send the packets to another router — one that is closer to the final destination of the packet. Midlevel networks hook LANs together using high-speed data communication lines, ethernet, and microwave links. A regional network is a midlevel network in a geographical area. A wide area network (WAN) is another kind of midlevel network. A WAN consists of an organization with many networked sites linked together. When a packet travels from a computer on a LAN in a midlevel network to a computer somewhere else on the midlevel network, a router (or a series of routers) sends the packets to their proper destination. However, if the destination lies outside the midlevel network, the packets are sent to a NAP (Network Access Point), where they are send across the country or the world on a backbone. High speed backbones such as the vBNS (very high-speed Backbone Network Services) can transmit enormous amounts of data — 155 megabits (millions of bits) per second (Mbps). Even faster backbones are being built that will transmit at an astonishing 9.6 billion bits per second. The Internet including the World Wide Web ("web") has, in recent years, developed into an enormous source of information. Many types of information, including but _ . not limited to text, pictures, audio and video, have been made available for retrieval by end users anywhere in the world. Anybody can post any information or content — text, pictures, audio and video — on the web where end users anywhere in the world can easily retrieve it. This makes for the incredible success of the Internet and its currently most used feature, the World Wide Web (also known as www.). The major problem facing the Internet is the growing demand for communication capacity as end users everywhere access information from anywhere in the world. It is estimated that Internet traffic already outstrips all conventional telephone and fax traffic on most international communication lines. More capacity, such as building additional backbones, i. e. very high capacity lines that carry an enormous amounts of Internet traffic, is continuously added, but is a very slow and expensive process and demand continues to outstrip supply. As the Internet traffic increases, the Quality of Service (QoS) decreases. Further, as the users tend to be a significant distance from the content they request, this distance can become a significant factor in their QoS. Internet content is becoming unmeasurable, probably thousands of Terabytes, but a relatively small subset of all this information or content accounts for a huge proportion of what is actually requested for viewing by end users. In order to speed up the transfer of information over the Internet, various caching schemes have been implemented for limiting the distance the information is transmitted and for limiting the amount of electronic traffic that is actually transmitted over the Internet. In general, most caching schemes retain copies of files or content downloaded by one end user in a end user community, such as, for example, a single Internet Service Provider (ISP), so that the content can be viewed by other end users of the same end user community, provided they have access to the same caching server/computer. Caching means that when one end user in an end user community obtains a file or content, a copy of the file or content is retained (on a local server, such as, for example, a proxy server) so that it can be viewed by other end users of the same end user community, provided they have access to the same caching server/computer. Therefore, caching has been used ever since about 1993, about three years after the World Wide Web was created. Caching thus serves the purpose of selecting a subset of all the Internet data or content for which there is a good probability of getting several end users requesting the same data or content. Thus, caching may be used to reduce the data communications capacity needed to serve the end users; this is especially important where that data communications capacity, such as, for example, additional backbone, is limited or expensive. WO 01/27766 _ 4 _ PCT/USOO/26135 Depending on the size and homogeneity of a representative end user community, about thirty to about sixty (30-60) Gigabytes of cache (See "The Measured Access Characteristics of World- Wide- Web Client Proxy Caches," Bradley M. Duska, David Marwood, and Michael J. Feeley, Department of Computer Science, University of British Columbia, in USENIX Symposium on Internet Technologies and Systems, pp 23-35, Monterey, California, December 8-11, 1997, the disclosure of which is herein incorporated by reference.) will reduce the electronic traffic outside the end user community and thus over the Internet by about thirty to about fifty (30-50%) percent. As the content available on the World Wide Web increases, it is highly likely that the required cache size will have to increase over time to retain the hit rate (the proportion of files or content demanded that are served from the cache) of about thirty to about fifty (30-50%)) percent. While these numbers are respectable, it would still give significant additional benefit if the hit rate could be increased to about seventy five (75%) percent or more. With the typical end user behavior, this would currently require 1 ) much larger cache, currently in the order of about two hundred to about four hundred (200-400) Gigabytes, but also 2) require a relatively high number of end users in a specific end user community, currently about several hundred thousand. The reason that such a large end user community is required is that the larger the end user community, the larger the probability that someone else has requested any given file or specific content, especially if the end users share some commonality of interest. The above described situation gives rise to some interesting technology challenges, which have found different solutions. According to one prior system that was proposed by Mirror Image Internet and described in Swedish patent application No. 9603753-6, entitled "Internet Communication System," filed on October 14, 1996, the disclosure of which is herein incorporated by reference, a user USR1 wishing to access information provided for example as a World Wide Web homepage or site by an Internet information content provider, located at a original site of publication somewhere on the Internet, generally sends an information request, specifically a HTTP request to the WWW port, via the multiplexing unit to the Internet first switching point, where the request is routed out on the Internet to finally reach the content provider. The content provider then answers the request, sending the requested information via the Internet back to the user USR1. However, according to the first embodiment of the invention shown in Fig. 1 of the above mentioned Swedish patent, the information request from a user USR1 to USRN is intercepted by the interceptor before it reaches the first switching point. The information request is then examined by the interceptor, which decides whether or not the requested information, for example the information provided by the content provider, exists in a copy or similar form on a local server, often called a "mirror server," arranged in direct communication with the . . interceptor. If a copy or the like of the requested information provided by the content provider is stored at the local server, the request from the user is re-routed to the server, which will then return the requested information to the user. However, if the interceptor determines that no copy or the like of the information of interest exists on the local server, then the information request from the user USR1 to USRN is sent on to the Internet first switching point as in the conventional form of Internet communication. Another solution was proposed by Mirror Image Internet and described in Swedish patent application No. 9803246-9, entitled "An Internet Caching System And A Method And An Arrangement In Such A System," filed on September 24, 1998, the disclosure of which is herein incorporated by reference. One solution described in this application uses a "Central Cache" to which a number of "feeders" or low end computers are connected as shown in Figure 1 of the above Swedish application. The feeders perform a number of time-consuming and time critical tasks in parallel with the central file server for the Central Cache. As a result, the central file server is able to efficiently service relatively more file server content requests because the processing load on the central file server is decreased and the central file server is able to dedicate more processing time to the actual retrieval of cached information files. According to one method of that application, a "Central Cache" is used as a means for combining scalability to millions of end users with cost efficiency. Caching has also been used to solve another Internet communications problem, congestion at the content servers. This content side caching, also know as "reverse proxy," is implemented by locating one or several caching servers or proxy servers in front of the content servers. This gives several benefits, mainly deriving from the fact that a good cache serves objects much faster than a content server does (since it has a much more limited set of tasks to do and therefore normally has a tailored operating system). The reverse proxy thus reduces congestion at the server site, but does nothing for Internet congestion. The idea has therefore developed in the industry to deploy "Backbone Caches," and it has been established that the best location for these Backbone Caches is where traffic is exchanged between different networks. Initially (early 1998), some backbone caches were deployed that led to problems for many applications. Such as, if a Local Cache is not able to re- issue a content request using the user's IP address (and for the subsequent content request to be routed back properly), authentication schemes can be broken. As is known, authentication takes place either before the network traffic interception is started, or on an non-intercepted port. Since the content request is not intercepted and re-issued by the Local Cache, the Origin Server sees the IP address of the user's machine. Authentication takes place as normal, and the Origin Server establishes a session for the user from a specific IP address. _ _ When a "normal" content request is made, it is intercepted by the router and redirected to the Local Cache. The Local Cache then re-issues the content request to the Origin Server. Since the Origin Server now sees the IP address of the Local Cache, and not that of the end-user, authentication is broken. It appears that the various cache vendors have now resolved most of these problems. Backbone Caches, however, suffer from the fact that they have to be present in quite many locations because, with Backbone Caching, each individual ISP has to provide its own Backbone Caching. Therefore, there is a duplication of Backbone Caching in each individual ISP rather than a plurality of ISPs sharing a single Backbone Cache. Thus, even though there is a fair amount of traffic at each Backbone Cache, allowing for a large Cache, each ISP having its own Backbone Cache means that there will be a relatively large number of relatively large Caches in the network between the end user and the content server, each having a high cost but adding relatively little value. This would especially be true if the concept of Backbone Caching takes off, in which case the path from the end user to the origin server would pass through many Backbone Caches. Only one of the many Backbone Caches would deliver the requested content to the content requesting end user, but all of the Backbone Caches would have to handle the cache misses thereby creating bandwidth problems in that the travel route of the request would traverse the Internet between Backbone Caches until the requested content was located on one of the large number of Backbone Caches. Current Backbone Caches are capable of generating HTTP hit rates in about the thirty to about fifty percent (30-50%) range. However, it would be desirable to generate hit rates in about the seventy to about the eighty (70-80%) percent range, thus reducing bandwidth costs for Internet Service Providers (ISPs) and providing each ISP's end users a higher quality of service. As the Internet continues to grow (6,642,000 hosts in 1995 and 15.000,000 in 1996, see, for example, http://www.davesite.com/webstation/net-history.shtml), the amount of data or content that needs to be handled by long haul data communications circuits or backbones continues to grow as well. Adding more circuits/backbones to handle more traffic is a never ending battle of installing hardware such as circuits, hubs, bridges, gateways, repeaters and routers, etc., to handle the ever increasing content/data being requested. To help alleviate this problem, ISPs have installed local caches. As shown in Figure 1, the end users 20, 22, 24 on the network labeled "NETWORK ISP A" 26 go through a "Local Cache" 28 to obtain entry to the Internet 30, and therefore to content sites 32. By forcing end users to go via a local cache 28, the local cache can 'cache' or store locally the content of various content sites. As an example, when end user 24 WO 01/27766 .7. PCT/USOO/26135 enters an HTTP request to obtain access to a content site 32, such as, for example, HTTP://www.example.com/, the browser (not shown) goes to the local cache 28 and the local cache 28 retrieves a copy of the content at the World Wide Web site www.example.com. The local cache 28 then sends a copy of the content retrieved from the World Wide Web site www.example.com 32 to end user 24 and stores a copy of the content retrieved from www.example.com at the local cache 28. When end user 22, communicates with the Internet by going through the same local cache 28 as used by end user 24, and requests access to the World Wide Web site www.example.com 32, the Local Cache 28 will NOT need to go via the Internet 30 to the www.example.com site 32 again in order to obtain the content stored at the World Wide Web site www.example.com, rather the Local Cache 28 will deliver the content that it has 'cached' (stored) from the previous request by end user 24. Clearly, since the Local Cache 28 did not have to access, i.e. send a content request over, the Internet 30 to the web site 32 and wait for a response therefrom in order to obtain another copy of the content for the second (and any subsequent) end user(s), there is a bandwidth savings over the communications circuit 34. Because end user content requests are not traversing the communications circuit 34, the communications circuit 34 can handle more traffic and therefor more bandwidth. In the above example, end users of Network ISP B 36, gain NO benefit, as Network ISP B 36 does NOT employ a Local Cache in the network, so EVERY request for content stored at the World Wide Web www.example.com 32 must traverse ALL THE WAY across the Internet 30 to www.example.com 32 in order to obtain a copy of the content at the World Wide Web site www.example.com 32 and return that content to the requesting end user, for example end user 38. Clearly the transmission of this content request across the World Wide Web via the Internet not only uses relatively more bandwidth than would the content request that is answered by a content request to the Local Cache 28, but also takes more time, as the content request has to travel over the Internet 30 to the server containing the requested content at the World Wide Web site www.example.com 32 and then back to the end user 38. As is known, the amount of bandwidth that is saved is a function of the "byte cache hit rate." Byte cache hit rate is calculated as follows: (size of hits/size of all requested content)* 100 Thus, if a number of end users using an Internet cache requested 500 mega bytes, and 100 mega bytes were served from the Local Cache and 400 mega bytes were not located in the Local Cache and therefore had to be retrieved from the originating World Wide Web site server, the byte hit rate would be: WO 01/27766 _ 8 _ PCT/USOO/26135 (100/500)*100 or 20%. As should be obvious to those skilled in the art, with respect to utilization of resources and speed of return, the higher the byte cache hit rate, the better, in that the end user does not have to wait for the content request to travel over the Internet to the originating content server, and to return to the end user. Additionally, the bandwidth utilization of both the end user ISP and the originating ISP is improved. The end user's ISP benefits because the content request and the subsequent content coming back does not have to traverse back to the computer network access point (NAP). The ISP of the content provider web site benefits in that the content provider web site ISP never sees the content request so the content provider web site does not receive the content request in the form of traffic on its internal network because the content server did not have to transmit the requested content back to the originating ISP network, thus reducing the demands on the content provider content site ISP's internal network or bandwidth. Since cache hit rate is a function of user content requests and disk capacity, the more end user content requests and the larger the disk capacity, the higher the hit rates. More user content requests increase hit rate due to the fact that it is more likely that another user has requested the same object or content located at a specific content server. Clearly, if there is not enough disk capacity to hold the content or objects that the users request, then the hit rate will suffer; therefore, having enough or sufficient disk capacity also increases the hit rate. Of course a higher hit rate means that more objects or content located on the originating content server were served from the cache. Because the cache is closer to the end user than the originating content server site, because the cache is specifically built to quickly deliver objects or content to the end user and because the cache is typically not as overloaded as the originating content server, the end users typically obtain the requested content much faster on a cache hit as opposed to having to wait for the content to be returned from the originating content site stored at a location relatively more remote from the end user than where the Local Cache is located. One possible solution to this low hit rate problem may be to locate a massive "Cache Farm" at a single location. Such a Cache Farm could consist of any number of individual farms consisting of up to about three hundred (300) machines or more with up to 4-CPU's each or more and up to 7 gigabytes of disk capacity or more, for a TOTAL of 1200 CPU's or more and 21 terabytes of cache capacity or more. Using this hardware, it might be possible to achieve hit rates in the about seventy-five percent (75+%) plus range. The problem with this possible solution method is that ALL worldwide traffic would have to be communicated back to the single Cache Farm over the Internet. Utilizing this approach, end users will most likely not _ _ receive a better quality of service; in fact, their service level may decrease because of the relatively high concentration of communications over the Internet backbone. As an example, if an end user in Los Angeles requests content from an originating content server in San Francisco, the content request would have to go via the Cache Farm located in, for example, New York, NY, thus traversing the continent AT LEAST twice to obtain content that is stored only several hundred miles away, as opposed to several thousand miles away in the Cache Farm. This is also true of any European end users, as they have to go all the way to New York, NY, to obtain the content from the originating content site that may reside in Paris or London. Such an approach also means that the end user's ISP system would receive no REAL bandwidth savings, and in many cases the end user's ISP might use extra INTERNAL bandwidth while saving EXTERNAL bandwidth. Thus, when an end user obtains content from the Cache Farm in New York, the ISP does not need to go outside of its own network, so the ISP saves External bandwidth, but the ISP does have to transmit the content through their OWN network an extra 2 or 3 times, thus using more INTERNAL bandwidth than had they used the Internet backbone. The current practice of backbone caching is achieved by using a network device capable of re-routing packets from the normal request path to an alternative destination, based on multiple criteria including, but not limited to: IP address, hardware address, content address, content type. One such method is to put a "layer 4 switch" 40 in the path of all network traffic (see Figure 2). The layer 4 switch will redirect all content requests or traffic to a Cache Farm 42. The problems with this method is that the layer 4 switch is yet another device that a network engineer would need to put into their traffic flow, thus introducing another possible point of failure. Another practice is to use a protocol invented by CISCO Systems called WCCP (see Figure 3). This protocol operates on the ISP's border router and redirects all content requests to a Cache Farm 46. The advantage to this method is that the ISP need not install any new hardware (other than the Cache Farm itself). Both of these prior methods suffer from the following shortcomings: each individual cache would have to have an enormous (such as several hundred gigabytes) amount of disk capacity to accommodate the amount of content needed to achieve a hit rate over about fifty (50%)) percent and, since hit rate is a function of disk capacity AND user content requests, these methods would not have enough user content requests to get hit rates over about fifty (50%) percent. This is because these caches would be handling end user content requests only for a single Internet Service Provider, whereas it is desirable to aggregate user content requests across several Internet Service Providers in order to achieve a higher hit rate. _ _ Thus, there is a need for systems and methods that would aggregate user content requests across at least two and preferably several Internet Service Providers; to generate hit rates in about the seventy to about the eighty (70-80%) percent range; to reduce bandwidth costs for Internet Service Providers and to provide Internet Service Providers users a higher quality of service. Summary of the Invention Current backbone caches are believed to be capable of generating content hit rates in the thirty to fifty (30-50%>) percent range. With implementation of the concepts contained in the present application, systems and methods will allow backbone caches to generate hit rates in the about seventy to about eighty percent (70-80%>) range, thus reducing bandwidth costs for Internet Service Providers and giving their users a higher quality of service. It is therefore a principal object of the present invention to provide systems and methods for aggregating user content requests across at least two and preferably several Internet Service Providers. Another object of the present invention is to provide a backbone caching architecture which generates hit rates in about the seventy to about the eighty (70-80%) percent range. Still another object of the present invention is to reduce bandwidth costs for Internet Service Providers. Yet another object of the present invention is to provide Internet Service Providers users a higher quality of service. Another object of the present invention is to use the aggregate content request information to intelligently decide what is cacheable content and what is popular content (frequently accessed content). Still another object of the present invention is to provide a backbone caching architecture which achieves the performance goals that backbone caches were intended to achieve without incurring a disproportionate added cost of implementation. Yet another object of the present invention is to provide systems and methods which uses periphery caches to make a Central Cache operate more efficiently and to drive more traffic to the Central Cache. Another object of the present invention is to provide systems and methods for leveraging user content requests across multiple backbone providers, i.e., user content requests TO a content server and replies to user content requests FROM a content server. _ _ Still another object of the present invention is to provide systems and methods for aggregating user content requests in such a way that ALL users receive better performance, and in many cases, ISPs save bandwidth. Another object of the present invention is to provide systems and methods for increasing the hit rate of inquiries from an end user for web content without communication over the Internet. Yet another object of the present invention is to provide systems and methods for reducing the external bandwidth required by an ISP. A further object of the present invention is to provide systems and methods for storing from an about eight (8%>) percent to as much as about fifty (50%>) percent of the most accessed web site content in a Cache Farm. Yet a further object of the present invention is to provide systems and methods for storing about eighty (80%) percent of the most accessed web site content in a Central Cache, some of which is duplicated in the Cache Farm. Yet another object of the present invention is to provide systems and methods for communicating between the Cache Farm, the Central Cache and a least two separate ISPs. A further object of the present invention is to create a Backbone Caching architecture which maximizes benefit (hit rate) at a low cost. In accordance with these and further objects, one possible aspect of the present invention includes a caching system for use in a network comprising: a plurality of operatively interconnected end user sites; at least one Cache Farm, operatively positioned relative to the end user sites, for storing content that is frequently accessed by the end user sites; and a Central Cache, operatively connected to the Cache Farm, for storing at least some additional information not stored at the Cache Farm, that is frequently accessed by the end user sites. Another possible aspect of the present invention includes a method for transferring information comprising the steps of: intercepting an information content request from an Internet user directed to a content provider address; determining whether or not the content request relates to content stored in a Cache Farm, the Cache Farm providing at least part of the information provided at the content provider address; and directing the content request to the Cache Farm. One specific example is to install relatively small (in terms of disk capacity) transparent caches as periphery caches. These devices will be called Injectors, since their main purpose is not to provide a huge hit rate, but merely to be low cost devices injecting queries to the Central Cache. This method will both increase the hit rate (since the Central Cache can be an order of magnitude larger than each periphery cache could be), but also significantly reduces the _ - cost of the whole caching system. It would also drive more traffic into the Central Cache than the standard Central Cache model. In particular it will make it faster and easier to reach "critical mass," which is a problem for all caching systems involving ISPs who do not on their own have enough Critical mass. The Injector could also be programmed to make intelligent choices based on type of content requests. Content requests for video stream could, for instance, be redirected to certain video servers. This redirection could be driven off a lookup table for what content resides where (and what content requests should not be redirected at all), as disclosed in Swedish patent application 9603753-6, filed October 14, 1996, the disclosure of which is hereby incorporated by reference. Other objects and advantages of the invention will be apparent from the following description, the accompanying drawings and the appended claims. Brief Description of the Drawings Figure 1 is a block diagram of a prior art caching system, which makes use of a local transparent cache; Figure 2 is a block diagram of a prior art caching system similar to that of Figure 1, except that a Layer 4 Switch is used in conjunction with the local cache; Figure 3 is a block diagram of a prior art caching system similar to that of Figure 1, except that a WCCP protocol is used in conjunction with a local cache; and Figure 4 is a block diagram of the bi-directional backbone central caching systems and methods of the present invention. Detailed Description The systems and methods of the present patent application are designed to efficiently process end user content requests for any one of a plurality of site content or objects from any one of a plurality of networks, including but not limited to, Internet Service Providers (ISP) networks. A Cache Farm for receiving the end user content requests, such as, for example, via a network device, and for storing a plurality of previously received content is operatively connected to a Central Cache for storing a larger amount of previously requested content. If the requested content is available from the Cache Farm, the content is delivered from the Cache Farm to the end user. If the content is not available from the Cache Farm, the request for the content is transmitted to the Central Cache. If the required content is available at the Central Cache the content is delivered to the end user via the Cache Farm and the end user's ISPs internal WO 01/27766 _ 13 . PCT/USOO/26135 bandwidth. If the content is not available at the Cache Farm or the Central Cache, then the content request is transmitted via the Internet for delivery from the content server to the end user via the Internet. While the term "content" is used herein, it is to be understood that the description is not limited to any particular "content" but is intended to include any type content that can be accessed and communicated via the Internet. Because hit rate is a function of disk capacity and number of end user content requests, one purpose of this application is to increase hit rate by increasing disk capacity and at the same time aggregating the end user content requests of several backbone cache users into one Cache Farm. Bi-directional periphery caching is presently preferably achieved, at least in part, by running WCCP, one of a plurality of alternatives, including but not limited to, a switch-based routing, normal routing (which would not be particularly efficient), etc., on the router of an Internet service provider. WCCP is the CISCO developed protocol "Web Cache Control Protocol." This protocol is used to extract content requests from a data or content stream and reroute the content request to a WCCP compliant Cache Farm (See Figure 3). A content request is a request from an end user, or a cache, requesting content from either an origin server or a cache. An example is, when an end user types http://www.example.com/ in his browser location box and hits enter, his browser will generate an HTTP content request for that web page. Bi-directional periphery caching is achieved, at least in part, by running WCCP on the router of at least two and as many as a plurality of and possibly many more Internet Service Providers, depending on certain system constraints, and directing the content requests to a single Cache Farm. By directing the content requests from at least two ISPs to a single Cache Farm, the problem of the number of end user content requests is overcome, as a sufficiently large enough number of end user content requests is available to generate the needed hit rates. By receiving the traffic from several ISPs at a single Cache Farm, the number of end users for the Cache Farm is significantly increased. To address the issue of disk capacity, a Cache Farm that consists of a plurality of [for example, for some applications a single Cache Farm of up to thirty two (32) individual caches may suffice, but in other applications it may be necessary to group together multiple Cache Farms of thirty two (32) into a larger Cache Farm] WCCP compliant caches having several 10s of gigabytes of disk space on each individual cache is presently preferred. Each Cache Farm will only hold the most recently accessed content within its own disk capacity. For content that is NOT stored in the backbone Cache Farm, a sibling or Central Cache is used, such as, for example, the Mirror Image Central Cache, at the location that has about a terabyte (or more) of disk cache capacity, as disclosed in Swedish Patent Application No. WO 01/27766 _14_ PCT/USOO/26135 9803246-9, filed September 24, 1998, entitled "An Internet Caching System And A Method And An Arrangement In Such A System," the disclosure of which is hereby incorporated by reference. As used in this application, a sibling cache means a cache that is used to create a mesh of caches between the current cache and the content site being accessed. In this way, the needed disk capacity is provided by the Central Cache operating as a sibling cache in order to achieve higher hit rates. With all outbound content requests from the ISP being redirected by the router to the Cache Farm, at least about seventy to about eighty percent (70-80%>) of all content requests will be handled within the content requesting end user's ISP network, saving the ISP on bandwidth outside of their network (i.e. using less data or content communications facilities or Internet backbone) and giving their end users faster access to the requested content. Also, all INBOUND content requests to servers located on the particular ISP's network will be intercepted at the Cache Farm as well, keeping about seventy to about eighty (70-80%>) percent of all inbound content requests and subsequent replies off of the ISP's backbone and the ISP's customer's content server. Again, the ISP will save bandwidth on its INTERNAL network, and the customer (being the content provider in this case) will save resources on their server and deliver the requested content to end users faster. Representative Examples of Some Typical Transactions. In the following examples, an 'end user' is a machine requesting content, such as, for example, the content of web pages, typically via a dialup or consumer connection, although any connection type (such as LAN, Tl, partial Tl, ISDN, xDSL, et cetera) will have the same results. A 'content server' is any machine that replies to requests for content with the requested content. A content server could be a web server, an ftp server, a news server, or any type of multimedia or other data or content type server. As shown Figure 4, in the event of an end user requesting content from a content server 83, and the requested content is stored in the Cache Farm, the end user 60 initiates the content request. The content request traverses the ISP's network 62 to the Border Router 64. The ISP's border router 64 directs the content request to the Mil Network Node 66 and specifically to the Cache Farm 68 using a cache as an injector via communication route 70. The Caches Farm 68 checks to see if the requested content is stored therein. If the requested content is stored in the Cache Farm 68, the Cache Farm 68 replies to the border router 64 via communication route 70 with the requested content. The border router 64 then sends the requested content to the end user 60 via communications route 62. Note, that, during this entire transaction, the request for content and the subsequent reply did not utilize the components of WO 01/27766 .1 5. PCT/USOO/26135 ISP Network 80, the communications route 81, 82, the border router 84 or the Internet via the network access point (NAP) 82, which is quite significant. The content itself never had to traverse another ISP's network or even travel to the network access point 82. Thus, the content request was initiated and satisfied without exiting the requesting end user's ISP as long as that ISP was connected to the Cache Farm 68. In the event of an end user requesting content that does NOT reside in the Cache Farm 68, but DOES reside in the sibling Central Cache 74, the end user 60 initiates the content request which traverses the ISP's network 62 to the ISP's border router 64 which decides that the request is for content is handled by the Network Node 66 and redirects the content request to the Cache Farm 68 using WCCP via communication route 70. The Cache Farm 68 checks to see if it has the requested content. If the Cache Farm 68 does not, the Cache Farm 68 generates a content request to the Central Cache 74 via communication route 76. Due to the fact that the Cache Farm 68 and the Central Cache 74 are well connected to each other (typically several 10's of feet, although, this distance could be several thousand miles, as well), the content reply comes back very quickly. In this case, the reply is that the Central Cache 74 does in fact have the requested content, and delivers the requested content to the Cache Farm 68. The Cache Farm 68 then replies to the end user 60 via communication route 70 and delivers the requested content to the end user 60. In the event of an end user from an ISP that does NOT have access to the Mil Network Node 66 requests content from a server that DOES have access to the Mil Network Node 66, the content request will travel from the end user 60 to the border route 64. The border router 64 decides that the content request is bound for ISP 80 and the content request is sent to the NAP 82, then to ISP's 80 border router 84. At ISP 80 border router 84, the requested content is routed to the WCCP Cache Farm 68 via communications route 86 using WCCP. The Cache Farm 68 then checks for the requested content and, if available, delivers the requested content to end user 60, as previously described. Note that during this transaction the network of ISP 80 never had to carry the request for the content or the actual content on the internal network of ISP 80, thus reducing the bandwidth demands on the internal network of ISP 80. The Cache Farm could feasibly be located in a different network access point than the Central Cache and still deliver a reasonably good hit rate/quality of service increase. While it is assumed that the Cache Farm is placed in close physical/network proximity to the Central Cache, it is just as likely that the Cache Farm could be put at a different network access point. This will still deliver content (10%-20%) to end users in an expeditious manner, with the remaining (50%>-60%ι) coming from the Central Cache and still deliver a reasonably good hit rate/quality of service increase. _ _ Larger hard drive capacity could be installed in the Cache Farm and thus serve a higher hit rate from the Cache Farm. The result being that fewer content requests will be transmitted to the Central Cache and will decrease the Central Cache load. Referring again to Figure 4, one illustrative example of the caching system of the present application utilizes a series of small (in terms of disk capacity) Cache Farms, transparent caches or "injectors" 68 which function as entry points to the Central Caches 74. The injectors 68 of this illustrative example may comprise, such as, for example, standard SUN hardware and, presently preferably, have, for example, between about twenty (20) and about fifty-six (56) gigabytes of disk capacity each, 4, 400 Mhz CPU's and 2 Gigabytes of physical RAM. For software, the injectors of this illustrative example must support some protocol to accept requests for content from the ISP or router. They also require a protocol to communicate with the Central Cache. The, presently preferred, protocol and the protocol that will be used to get content requests from the Central Cache is WCCP. WCCP is a CISCO protocol and has many useful features, not the least of which is its ability to scale or expand the capacity of the Cache Farm, or a Layer 4 Switch or similar device that has capabilities similar to WCCP, especially being able to cluster a series of caches into a "Cache Farm," or a group of caches acting as a single larger cache. Currently ICP (Inter Cache Protocol) is a lightweight protocol that is used to query the availability of an object within a cache. Currently the ICP protocol is used to communicate between the Cache Farm and the Central Cache. While ICP is a weak protocol, it presently performs adequately but will most likely be replaced at a future date as the system evolves. Currently, the only known software that supports both of these protocols, the WCCP and the ICP, is available from CISCO, Inktomi, and Novell. All three software versions perform adequately with the systems and methods of the present application, as all three run on standard hardware and are "transparent local caches" that support both the WCCP and ICP protocols. The injectors, running on the above mentioned hardware and software, are, presently preferably, clustered together at network access points (NAP) such as MAE-East, LINX, etc. Networks at these NAPs then use WCCP protocol on their routers, or Layer 4 Switches, to redirect their traffic to these clusters of injectors. As a means of keeping latency low and availability high, this redirection will occur over a dedicated "cross connect" from the customers "border router" to the Mil injector farm or Cache Farm 68, this cross connect will likely be a high speed ATM connection, such as, for example, an OC-3 (155 mbps). Each of these injector farms 68 will utilize WCCP or a Layer 4 Switch to capture content requests both from an end user site and to an end user site which includes an origin server. The border router at the ISP will be setup to handle OUTBOUND content requests for its transit end users, and INBOUND content requests for its content provider customers. WO 01/27766 _1 7 _ PCT/USOO/26135 Because these injector machines 68 have a small amount of disk space (about 18- 56 gigabytes), the injector machines 68 will be able to serve the most popular content directly. For the content that is not located on the injector Cache Farm 68, the injector Cache Farm 68 will communicate with the Central Cache to determine if the Central Cache has the requested content. Because the Central Cache has 1+terabytes of content, it is about seventy five (75%) percent likely that the requested content will be cached or stored on the Central Cache. The injector Cache Farm 68 will decide which content should be stored on its local disks based on how often a specific content is accessed. As content is accessed, the accessed content will be added to the local drive, i.e., the injector Cache Farm 68. When the local drive is filled with content, a cache replacement algorithm, such as, for example, a LRU (least recently used) algorithm will be used to remove old content to make room for the new content, as is known in the art, and is provided by providers of all cache technology, such, as, for example, Inktomi, Novell or CISCO, among others. The main purpose of the injector Cache Farm 68 is to function as a low cost device injecting queries or content requests to the Central Cache. This is done either by configuring the customers (ISP's or corporate/company networks) border router to use WCCP to redirect their content requests to the injector farm or by a Layer 4 Switch. These content requests will initially be HTTP, but ultimately can be anything (FTP, real audio, real video, et cetera). This scenario will dramatically increase cache hit rate due to the fact that hit rate is a function of end user content requests and disk capacity. The Central Cache will preferably have about 1+ terabytes of disk capacity, and will be aggregating end user content requests across at least two and preferably more backbones so the hit rate will be in about the seventy five (75%+) percent plus range. In particular, the systems and methods of the present application will enable the caching system to achieve "critical mass" faster and easier, which is a problem for all caching systems used by internet service providers that do not on their own generate sufficient content requests to reach critical mass. As used in this application, "critical mass" is the level at which the Central Cache begins to operate at an efficiency level unattainable by local caches. Critical mass will be reached sooner due to the sheer number of content requests. Studies show that about eighty (80%>) percent of all Internet traffic is web traffic. If the injector Cache Farm and the Central Cache are installed at the backbone router of a backbone provider, about eighty (80%)) percent of all of the traffic directed to and from the backbone provider would be routed toward the Central Cache, this will be many 100's of megabits per second. This high traffic rate will give the Central Cache the needed end user content requests to start generating high hit rates. In this situation, critical mass is indicative that until there are sufficient end users using a caching system (Cache Farm, and/or Cache Farm and Central Cache) they may actually experience net loss in performance. When a critical mass is achieved, there is a net gain in performance, because more of their requests are speeded up locally, rather than slowed down locally. While the foregoing invention has been described with reference to its preferred embodiments, various alterations and modifications will occur to those skilled in the art. All such alterations and modifications are intended to fall within the scope of the appended claims.

Claims: _ _ What is claimed is: 1. A bi-directional periphery caching system for use in a network comprising: a plurality of operatively interconnected end user sites; at least one Cache Farm, operatively positioned relative to the end user sites, for storing content that is frequently accessed by the end user sites; and a Central Cache, operatively connected to the Cache Farm, for storing at least some additional information not stored at the Cache Farm, that is frequently accessed by the end user sites. 2. The system of claim 1 wherein the Central Cache has storage capacity that is an order of magnitude greater than the storage capacity of the Cache Farm. 3. The system of claim 1 wherein the end user sites include end users requesting content and origin servers supplying information. 4. The system of claim 1 wherein the Cache Farm stores frequently accessed information. 5. The system of claim 1 wherein the Cache Farm holds information until it is retrieved by the Central Cache. 6. The system of claim 1 wherein the transparent Cache Farm captures requests for content and feeds the content requests to the Central Cache. 7. A method for transferring information comprising the steps of: intercepting a content request from an Internet end user directed to a content provider address, the Internet end user being one of a plurality of end users forming at least one network of end users ; determining whether or not the content request relates to content stored in a Cache Farm, the Cache Farm being operatively connected to at least two networks, the Cache Farm providing at least part of the information provided at the content provider address; and directing the content request to the Cache Farm. 8. The method of claim 7 further comprising the step of: WO 01/27766 _20- PCT/USOO/26135 if the requested content is stored in the Cache Farm, obtaining the content and transmitting the content to the requesting Internet end user. 9. The method of claim 8 further comprising the step of: if the requested content is not stored in the Cache Farm, determining whether or not the content request relates to content stored in a Central Cache, the Central Cache being operatively connected to the Cache Farm, the Central Cache providing at least part of the information provided at the content provider address. 10. The method of claim 9 further comprising the step of: if the requested content is stored in the Central Cache, obtaining the content and transmitting the content to the Cache Farm and then to the Internet end user. 11. The method of claim 10 further comprising the step of: if the requested content is not stored in the Central Cache, communicating such to the Cache Farm. 12. The method of claim 11 further comprising the step of: once it is determined that the requested content is not available at either the Cache Farm or the Central Cache, the Cache Farm obtains the content from the content provider address, transmits the content to the Internet end user and then stores the content at the Cache Farm. _ _ 13. A bi-directional periphery caching system for use with at least two networks, the system comprising: a plurality of operatively interconnected end user sites that form a network; and at least one Cache Farm, operatively connected to at least two networks, for storing content that is frequently accessed by the end user sites. 14. The system of claim 13 further comprising: a Central Cache, operatively connected to the Cache Farm, for storing at least some additional information not stored at the Cache Farm, that is frequently accessed by the end user sites. 15. The system of claim 13 wherein the number of networks operatively connected to the Cache Farm is three or more. 16. The system of claim 13 wherein the Cache Farm is directly operatively connected to the networks.

Inventors: CHRISTEN PAUL H P, COOPER IAN H, CHRISTEN, PAUL, H., P., COOPER, IAN, H.
Applicants: CHRISTEN PAUL H P, COOPER IAN H, MIRROR IMAGE INTERNET INC, CHRISTEN, PAUL, H., P., COOPER, IAN, H., MIRROR IMAGE INTERNET, INC.
Application year: 2000
Main classification: G06F12
IPC codes: G06F12, G06F13, H04L29