1996-09-07 - Re: Metcalf and Other Net.Fogies

Header Data

From: mccoy@communities.com (Jim McCoy)
To: cypherpunks@toad.com
Message Hash: e10855ec5abcd579143cbb382da8a830339e01f0ac896659b30445c9c2ea2dd8
Message ID: <v02140b02ae56d0cc0dba@[205.162.51.35]>
Reply To: N/A
UTC Datetime: 1996-09-07 08:35:38 UTC
Raw Date: Sat, 7 Sep 1996 16:35:38 +0800

Raw message

From: mccoy@communities.com (Jim McCoy)
Date: Sat, 7 Sep 1996 16:35:38 +0800
To: cypherpunks@toad.com
Subject: Re: Metcalf and Other Net.Fogies
Message-ID: <v02140b02ae56d0cc0dba@[205.162.51.35]>
MIME-Version: 1.0
Content-Type: text/plain


perry@piermont.com writes:
> Alan Olsen writes:
> > Metcalfe may have a valid prediction here.
>
> Metcalfe is talking out his ass. He's reached the "old geezer who's
> impeding his own field" stage. Many of his articles seem to be written
> as though no one was trying to fix problems.

Well, having talked with people involved with the problems I can assure you
that they are real.  The net brownouts when MAE-East dumps its BGP core or
the fact that when one of the NAPs upgraded to FDDI it soon found that by
the time people had installed the upgrades to the routers the bandwidth was
already saturated should indicate that there are problems.  Most of the
problems are in the routers, even the top of the line Cisco boxes can only
handle so much.  The sky is not falling, but these sorts of problems are
cracking the
whip behind IPv6 and pushing the companies that make the routers pretty hard
(Have you ever tried to buy even a lowly Cisco 2401?  Do you know what the
wait is on delivery?  I really wish I had bought Cisco stock earlier...)

> > When I run traceroutes, the blockage is in MCI or Sprintnet land.
>
> How do you manage to determine where you are losing bandwidth using
> traceroute? That must be a mighty powerful traceroute to do that --
> most traceroutes I've seen are hard pressed just to find out what the
> connectivity path is.

Then you should probably upgrade your traceroute, preferably to one which
allows source routing of the packets and then couple the output to a nice
udp source routing script which will bounce a few packets between links
with slow response times. Most of the problems are at the exchange points
where packets go from one company's network to another.  It seems that users
have the annoying habit of wanting to talk to other people's
customers...imagine the nerve :)

> > The bandwidth to the net has been oversold.
>
> Always the case. Big deal. Bandwidth is still increasing pretty
> fast. There are, naturally, growing pains, but the outages and
> bandwidth situation are pretty good, all things considered. Compared
> to the way things were eight or nine years ago they are amazing;
> compared to four years ago they are still astoundingly better.

Bandwidth may be increasing quickly, but demand for it is increasing even
faster with every moron wanting tose the web while the routers to hook it all
together and make it work are still very expensive and not being produced
fast enough to satisfy the demand.  Compared to the way things were even a
few years ago the aggregate bandwidth that one person can expect is
decreasing, it seems that no one writing internet protocols passed an Intro
to Sociology/Poly Sci course and assumed that the tragedy of the commons did
not apply to them.  The upside of all of this is that it is creating a demand
for value-added services which offer users dedicated bandwidth and faster
response time in return for a little coin.
This will probably push micro-currency on to the net faster than any other
consumer demand...

jim







Thread