Peter, that is all truly very fascinating to me. Thanks for bringing those ideas to the discussion.
I take it that you see directory- and policy-based decision processes scaleable across the entire 'net. Would this be similar to the way that some web accelerators portend to work for their ISP-, ASP-, enterprise- and content-provider customers. For example, Alteon's web switch, and its growing number of peers in this space?
And if so, would this also mean, then, that each ISP pop that participated in this scheme would need to be so provisioned, or would normal IETF RFCs cover the tab?
Does this take place at the conventional router and associated ISP server levels? Or, is what you are suggesting going to take place at some higher stratum in the stack above Layers 3/4, and outside of the realm of traditional routers, DNS servers and other ISP services?
Say, at some "virtual Internet" layer so as to avoid the everyday and mundane conflicts which are now legendary among the pluralistic-ISP, multi-routervendor, and multiple-directoryservices platforms?
And if these directory and policy based decision processes took place at a higher layer, then how would we account for (or be able to mitigate) the extra time that it would take to go up and down the stack in such a way as to make these extra steps transparent to the user?
One would hardly expect to maintain the advantages of ASIC-based packet forwarding if these processes needed to be handled in software. I'm all ears.
Two weeks ago I would have been even more skeptical about such an approach. And then I met Selina Lo of Alteon at an IEEE meeting on e-commerce solutions, and she answered many of my questions to my satisfaction. Not that I don't have additinal questions, as you can see from the above, but I now feel somewhat more confident in some web acceleration processes. And if you are going to be making calls around the 'net in the way that you've described or proposed, then you are going to need a fair deal of web acceleration.
So, like I say.. I'm all ears.
Regards, Frank |
