At 04:08 PM 13-01-97 -0500, Bob Metcalfe wrote:

... Is the Internet's sometimes bogging down due mainly to packet losses or busy servers or what, or does the Internet not bog down? ... If 30% loss impacts are noticeable, what should be done to eliminate the losses or reduce their impacts on Web performance and reliability?

Bob; There has been a sea change in expectation for the Internet in the last few years from "did my mail get through last night?" to "why is this telnet so damn slow?" to "why don't my web graphics download faster?" Today's Internet is pretty astounding with respect to email delivery. I don't think we are anywhere near saturating the network with email. No one is complaining about a lack of email volume or timeliness of delivery (except for server scaling problems experienced from time to time by rapidly growing ISPs). Nobody cares much about telnet today -- the Internet is synonomous with the web, which means HTTP. The recent discussions on packet size distributions substantiates that. The web is slow, almost necessarily so. The web is a completely unarchitected data delivery system with some pretty significant flaws that make the web very sensitive to path delay. The relationship between data location and subscriber location is completely unarchitected. That's fine for hobbyist use, but not for large scale information delivery. But it is pretty mind boggling to me that people think that the Internet is creaky and clanky when the web protocol and data (un)architecture is what it is. As I say, the Internet works pretty damn well for email. Anything more sophisticated needs an architecture as well as a topology. The Internet topology today is pretty well engineered for an architected web. Once HTTP 1.1 is deployed, if web caching and mirroring business deals are made between content providers and Internet access providers, the data will end up in pretty much the right place and we'll see a much better match between the data flows and the topology. The web will be fast. And multicast Internet TV and radio channels can be addressed about the same way. Architect the channels and have content providers make transport deals with access providers. And from now on let the access providers architect the data systems. :-) Or at least re-architect the wildly popular apps before they grow too large. --Kent