Cisco cache director overview

From: John Scharber <jscharbe@dont-contact.us>
Date: Mon, 22 Sep 1997 12:20:35 -0700

This is a very early draft I'm working on for a paper, I would love any comments please fill free to rip it apart.

Next sections should cover Inktomi, NetCache, and Squid. I will post if there is interest

John Scharber

Cisco Cache Director

Provides caching for HTTP 1.0 and HTTP 1.1 protocols only. The Cisco CE2050 provides 128MB of RAM storage and 24GB of cache storage. There is a single 10/100 Meg bit Ethernet interface, and a serial console cable. It supports a Maximum of 900 concurrent sessions per cache server with the ability the to cluster up to 32 servers on a single "home" router. When there is more than one cache server on a home router, the Web Cache Control Protocol distributes the load by dividing the IP address space into 256 discrete groups and dividing them evenly amongst all cache servers. If a cache server is added or removed, then WCCP re-divides the work long among the remaining servers and if possible the cached data is transmitted to the new servers. If the data is not found in the local cache cluster, data is forwarded to a cache farm at the ISP's main facility, and finally to the actual server itself. If all cache servers fail traffic is routed to the actual server by default.
User can control what gets cached by creating an access list enabling or disabling specific domains, IP addresses or MIME types. By default HTML documents are cached for up to 24 fours depending on a number of factors, and MIME data is cached for up to one week. A user selecting reload on their browser forces a refresh of cache.
The Cisco name and their dominance of the Internet backbone may be this products biggest strength. In addition, it has a very strong story on performance, scalability, and ease of use. However, one needs to study it features closely to understand some of the limitations and drawbacks in Cisco implementation
The Web Cache Control Protocol has several problems starting with the fact it is not based on an open standard or RFC. Beyond that its method for doing distribution (division of the IP address space) amongst cache server can be severely flawed depending on where sites fall in the IP addressing scheme. For example, if my most active sites where in the lower half of my address space then adding a second server would do little to increase by capability. To my knowledge there is not study of popular sites and their address space that would support this method of load balancing. In addition, it's not clear how this scheme maps into the IPv6 world.
The Cisco Cache server only supports caching of traffic on port 80. Based on Cisco estimate that 40% to 80% of all Internet traffic is redundant and then factoring in the fact that only ~35% of all network traffic is HTTP based (from Internet Traffic Archive), they can only address 14% to 28% of the actual redundant information problem.
Next there are problems with Cisco fault tolerance scheme. While it does provide for uninterrupted continuance of service in the event a single cache server is lost. It provides no redundancy of data, so it is possible that all 24GB of cached data will need to be downloaded again from the source. This also brings to light one of the other problems with WCCP, since there is never more than on copy of the data in a cache cluster, there can be no load balancing between multiple server for high volume documents (. e.g. media driven events such as the Mars landing, etc.)
Support for Open standards is anther draw back in the product. A good example of this is the lack of support for the Internet Caching Protocol version 2 (heck any version). This truly prevents an ISP from maximizing the efficiency of their network for several reasons. For instance, if the Cisco Cache director support ICP then an ISP could set up a cache peering point with other ISP and query their servers to avoid traffic out side of the peering point. With out this capability, the ISP is forced to transit all cache traffic back to the main facility where in theory the ISP has created a cache farm. Or anther example would be long haul facilities such as between the United States and the Far East. Here caching is highly desirable but it would require that both end use Cisco hardware and Cache servers, but in reality the bulk of the current caches are CERN, Squid, Netscape, etc (not to mention new products coming out). If an ISP has based their network on Bay or anther ve!
ndor they are simply out of luck.
Received on Mon Sep 22 1997 - 15:03:32 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:07 MST