Hello Frank,
I appreciate you viewpoint on this area ...
> As in medicine, each remedial prescription for a particular ailment
> must be studied for any of the ill side-effects it may cause,
> resulting from contraindicatives. Take your local caching solution,
> for example.
Agreed! This is an area that extensive testing and experimentation is going on right now. The key word is "local" ... ;-)
> Caching would allow much faster downloads in the beginning,
> granted, if the caches were in, say, regional offices, as opposed
> to none at all, or in a national repository. But what would this do
> to other parts of the 'net? What would this do to the performance
> of the network edge? The edge would get swamped, if this model were
> to suddenly reach high levels of penetration, to the point of
> diminishing returns, and then none at all, because normal capacity
> sizing has rendered the edge to be capable of only that which it
> _currently_ must support. Kinda like natural selection. Of course,
> the edge could be bolstered, but whose responsibility is that?
I'm not sure that I understand your analysis here. For successful caching to be implemented, IMHO, it would require hierarchical caching to be implemented throughout the infrastructure. Also, IMHO, it would be augmented with broadcast preloading of caching based on access analysis. So caches (object routers) would be installed in parallel with packet routers/switches. Hierarchy is the key ...
> In electric power company jargon, this displacement effect being
> caused by the caching action could be likened to 'load shedding' of
> power between neighboring generation plants or companies on the
> same grid, just before the breakers are set to blow. On the
> Internet, it could likewise be called load shedding, or, more
> appropriately, load "shifting." For, in the end, much greater
> amounts of traffic would then flow, not less, and although it might
> seem like there is an advantage gained, more traffic is then
> permitted to flow on the "backbones," perhaps sooner in time than
> otherwise, which in turn engenders more demanding forms of traffic
> to get through which cannot be cached. Namely, real time traffic.
> But how is this real time stuff going to get through to the limited
> edge resources, when the edge is busy coping with downloads from
> caches in regional offices?
In our current testing we are seeing 40%-80% cache hits on a local cache ... which actually creates about a 50% decrease in outbound traffic over time. Again the benefits being gained even more from properly designed hierarchies.
> The contraindicative? Now that the pipe is filled to the home to
> the point that it is bursting with that super-fast cache download
> of your favorite interactive game release (that still takes about a
> half hour to download, even under ideal conditions), where's the
> room for that UDP voice application going to come from on that
> limited feeding straw you call an access line? I've exaggerated to
> make a point.
This is where bandwidth throttling has to take place, or shifting the large downloads to a different medium. i.e. satellite broadcast of data
> Even if this were to work to everyone's favor, who would pay for
> the fat pipes needed between the local caching engines and the
> ISP's distribution nodes? Certainly, a single cache would render
> minimal effect for most ISPs' purposes, that is, for those with any
> appreciable geographic coverage; there would be a need for
> several-to-many of them.
Single caches would have minimal effects on the grand scale of things ... however again I would predict that properly implemented hierarchies are where the gains will be seen. Today the new class of communications companies that are laying the fiber seem to have no problem setting aside fiber for their packet routers ... why not set aside some strands for object routers?
> How many caches would be required throughout the ISP's serving
> territories? The caching engines and the pipes would represent
> large incremental and recurring costs to already cash-strapped
> ISPs, who, in the main, are looking to cut costs, not increase
> them... The ISPs, in turn, would have to re-distribute the cost
> burden of acquisitions and upkeep to end users.
Caches do not have to be big expensive boxes to provide benefits. I understand your statements, however I wonder if the costs are really that high for the benefits that would be seen in shifting the routing of repetitive objects to a parallel network ... I don't know the answer here, but you bring up some good issues.
> Are end users ready for this? Some are, most are not... because it
> runs counter to what the Internet is 'supposed' to be: Cheap. Uuhh,
> better make that, very inexpensive.
We already are seeing ISPs installing caches and having customers using them ... most of these are based on fairly inexpensive hardware/software platforms. (i.e. <$10,000)
> If we go back to the beginning and analyze the needs of users, all
> messages do not demand the same levels of immediacy in their
> receipt. Some emails, many LAN messages, some database updates,
> some voice-mail trickles, etc., can wait. This, however, is not the
> case today, since the fairness rules on the 'net do not distinguish
> between an email message and r-t voice, at least not in the favor
> of voice packets...
This is the whole concept behind proxies and caching ... there are a huge number of objects that are traversing the Internet that are duplicates, and don't need to come from the origin server ... a cached copy would work just fine.
> In fact, email gets the priority, since VoIP is using UDP packets
> which lack the guaranteed delivery mechanisms that TCP allows in
> the transport layer for applications such as Email and http.
E-Mail protocols are not yet properly architected to take advantage of cached networks. Again, with a little work on the protocol while the transition to IMAP4 takes place, this could change. HTTP and most web objects however are ready to take advantage of object based routing.
> And while email is subject to TCP windowing delays, and restarts,
> it does in fact enjoy the guarantees that TCP avails itself to,
> since sooner or later that email does get through, ordinarily in
> one piece. Kinda like a backwards set of priorities, wouldn't you
> say?
Yep ... and I would believe that intelligence in the infrastructure, based on an end-node talking to a local cache creates an environment for the proxy to better control the COS and QOS that the protocol would experience ...
I think this is a facinating area and is going to continue to grow ... there is considerable research that a variety of companies are doing. For those interested in more, you could visit: nlanr.net
Scott C. Lemon |
