Hello UUplink,
> Hi Scott--Let me say at the outset that I know
> practically nothing about NOVL's proxy/cache system, but
> would be quite interested in hearing more about the
> parallels you see with the Mirror Image system.
I wanted to make sure that I was up-to-date on the Mirror Image systems, and so I have re-visited their web site to see if their overall architecture had changed. It doesn't appear that anything different is going on, so I'll take a couple stabs at trying to explain some of what they are up to ...
The "parallels" are not necessarily what exist ... it's the partnering. What Mirror Image has built is a "hierarchical cache network" and they are using a variety vendors products to create this network. From their web pages:
Our patented technology is fully compliant with the ICP standard. This ensures interoperability with ICP-compliant local caching systems, including leading products from CacheFlow, Cisco, Cobalt, Entera, InfoLibria, Inktomi, Network Appliance, Netscape, and Novell-based systems from Compaq and Dell, as well as Squid freeware.
So they are not building a "competitive" product, but they are actually building, what I call, the "network on top of the network" ... this is also implementing what I see as "object routing". If you visit their web site, they even have some of the drawings to look at, and those familiar with how normal packet routers are interconnected, might start to notice the similarities.
In the quote above, the ICP protocol is also very much like a "router discovery protocol" ... it's a way for caches to talk with other caches to determine the best source (or route?) to request a piece of content. (i.e. a web page, a GIF or JPG picture, etc.)
> Also, what I know about MII is based on just a few weeks
> of limited online research. If you have talked to the
> company then you likely have a more useful perspective.
;-) I will admit that I have been working in this space since ~1996/1997 when I went back to Novell for a stint. I immediately was drawn to the natural fit of the proxy/cache model to the OSI model and the "upstream" evolution of technologies. I'm actually working on a personal project involving these caches and caching protocols right now ... ;-)
> Re. "pure storewidth"--The crux of the MII system seems
> to be the so-called "injection" technology whereby a
> sizable, and presumably relevant, fraction of regional
> web traffic is directed from major ISP's to MII's very
> large (2 TByte) hardware cache devices.
I don't see anything on their web site to indicate changes, so I'll go with what I have been told by them in the past. The way this is done is by installing a "local cache" server as an ISP or corporation. Many are already doing this due to "local" benefits of cache servers. Mirror Image partners with numerous vendors, all who support the ICP protocol. ( mirror-image.com )
A "Local Cache" has the ability to intercept web requests (or for the clients to be configured to use one) and check their local storage to see if they already have requested and stored the requested content. If they have, the local cache just gives the content to the user's browser.
But here is where things get interesting. If there is a "cache miss", meaning that the requested item is not available, the Local Cache will go get the content for the user. The issue becomes "Where does it go to get the content?"
The Local Cache has the option of going directly to the "origin web server" (the actual web site that was requested) or use a protocol like ICP to "ping" other caches in the Internet to see if they might have a copy. Mirror Image is charging people to be able to "ping" their caches ...
> These devices are located near the edges of the web in
> order to reduce the number of router hops needed to
> convey information to local (e.g. in country) users.
Yes ... they are actually built in "hierarchical" patterns ... or "peering" patterns. Again, very much like packet routers. ;-)
On a side note, to view a "public" version of such a network, you can visit this site:
- ircache.net
- Give it time to load ... it's Java
- click the "Start up Plankton" button ...
- double click a 'year/month'
- then double click a 'day file' ...
- give it a little time and you'll get to see the latest map of a public caching hierarchy ... it will load a global map, and you can also view the map by "topological arrangement" ...
> These CAPS (content access points) also must employ
> efficient search and cache purging algorithms, although I
> don't know to what extent these are proprietary to MII.
Many of the rules on how to "age" content are already included in the web pages and objects themselves. The headers can provide details on the lifetime of the information. But there are enhanced capabilities that are provided by the various vendors ... Mirror Image has theirs, Akamai has theirs, etc.
> Contrast the MII approach with the typically smaller
> cache sizes used by such companies as ISLD and AKAM.
So in reading Georges newsletter again, he talks about 2TB of content ... not "per server" but in their network. So this is really not much different, and is actually not a really big number. (For example, I'm pricing out a 200GB subsystem just for my own personal use at home ... built out of $250 40GB Maxtor drives ... ;-)
> The larger caches permit storage of streaming media files
> and other large semi-temporary files that cannot be
> readily accomodated by smaller caches, and thus consume
> bandwidth each time they are accessed.
I'll do some digging around, but again the fact seems to be that MirrorImages network is built out of smaller caches ... so it's the aggregated total that is larger.
As I'm writing this, I just realized that I am going through a proxy/cache at my office right now (live! while posting this! ;-) and it's got a 20GB hard drive for cache. It would only take 100 machines like mine to total 2TB. (He says while scrambling for a calculator ...
> For international traffic the regional caching of such
> files saves the ISP's data transmission costs since the
> large files only have to go through the carrier network
> once.
Exactly. Once a cache in MirrorImages network fetches content once it is in that cache, to be given to requesting browsers, until it's lifetime expires.
> Private networks like ISLD try to make the transmission
> extremely efficient wrt point-to-point routing. But as I
> understand things, their tradeoff between bandwidth and
> storewidth is strongly biased towards bandwith.
And now you are getting to a point that I really like ...
ISLD is using "packet" bandwidth, routed through their network to try and provide performance. But you can't cache packets efficiently.
But if you are working with "objects", whole pages of content, whole graphics, or whole media files, you have the ability to route them between your caches. The cache become "object routers" ... ;-)
> How easy would it be for ISLD and similar companies to
> design/implement an alternative large cache scheme that
> would be as effective as MII's? This is the question I
> would particularly like to resolve.
I will argue that outside of some details it is actually very easy. Yes, MirrorImage has taken a good approach, but Akamai is out there, SandPiper, RealBroadcastNetwork, and others. I actually bought InterVU (ITVU) quite a while ago (~$30) because they were at least different in their focus on hierarchical multimedia distribution and caching.
> I believe Gilder's point is that when transmission speed
> is limited by the speed of light (i.e. all optical
> switching) and the volume of traffic has expanded
> enormously from todays volume, then the only other way to
> speed things up will be to house virtually the entire web
> locally. Hence the term "pure" storewidth.
Exactly. Move all of those "objects" closer to the end users ... don't make them waste all those packets ... use a higher level of intelligence and "route objects" through the infrastructure. And there are even more services yet to be seen ...
> I doubt that this has informed you beyond what you
> already knew. Hope to draw some more comments out.
So the best part is that we are actually very much in sync with our understanding ... sorry for the massive post ...
Scott C. Lemon |
