Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Web Desktops, Web Applications, Thin Client -- Ignore unavailable to you. Want to Upgrade?

To: PJ Strifas who wrote (38)	12/3/1999 10:40:00 PM
From: Frank A. Coluccio	Read Replies (1) \| Respond to of 68

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

To: PJ Strifas who wrote (38)	12/3/1999 11:17:00 PM
From: Frank A. Coluccio	Read Replies (1) \| Respond to of 68

Some more on Alteon: [go to urls for graphs] "Alteon revs WebOS with URL-based load balancing" By Paula Musich, PC Week URL: www5.zdnet.com --------- "What's so great about URL switching?" By Pankaj Chowdhry, PC Week Labs, PC Week September 12, 1999 9:00 PM PT URL: zdnet.com Although some companies may just be catching up with IP switching, cutting-edge companies have moved on to URL switching, offered by vendors such as Alteon WebSystems Inc. and ArrowPoint Communications Inc. This new breed of content switch—such as the $13,000 Ace Director 3 that PC Week Labs tested and that Alteon plans to release this week (see related story)—will allow companies to manage Web content in much more flexible ways. For instance, the cookie in a URL could be used to direct a request to a specific server. Content switching will also enable more effective use of Web caches. By looking at the type of content requested in a URL, a content switch can direct static pages to a Web cache, while dynamic content is served directly from the Web servers. URL switching also simplifies capacity planning because "hot" content can be easily segregated and attended to. In tests of Alteon's AceDirector 3 and of ArrowPoint's $16,000 CS-100—the only other competitor—their differing architectures had a significant impact on performance. Using 300 clients and seven servers, we were able to switch 37,000 URLs per second using Alteon's AceDirector 3 vs. 7,000 connections per second with the Arrow Point CS-100. The huge difference in performance is probably due to the distributed ASIC (application-specific integrated circuit)-based architecture used in the AceDirector device. The CS-100 becomes a serious bottleneck if HTTP 1.0 is used. When we converted test clients to HTTP 1.0, the CS-100 dropped to about 1,700 requests per second, which makes it almost unusable. We saw a similar performance drop with the AceDirector 3, down to about 7,000 requests per second per port.