Questions about Internet Packet Losses

Wed Jan 15 04:15:05 UTC 1997

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