Re: Metcalf and Other Net.Fogies

["Perry E. Metzger" <perry@piermont.com>]

Jim McCoy writes:
> 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.

I'm "involved with the problems" too, you know. Don't teach granpaw to
suck eggs. OF COURSE there are problems. None of them, however, are
signs of "collapse".

As a certified Network Old Fogie, I can tell you about the time the
Arpanet decided to die because of a bug in the IMPs... and then there
was the day that the backhoe took out *the* line between the east and
west coasts... and then there was the time in the 80s before Van J's
algorithm where congestion was nuking everything in sight... and then
there was...

Look, there will *always* be trouble. The question is whether or not
"collapse" is something imminent. The answer is "no". Stuff will get
better, it will get worse, but the overall trend is better, and
collapse just isn't in the cards.

Metcalfe talks about stupidity like how there aren't enough "suits"
running the net -- as though people in suits do better engineering
than the folks we've got. Metcalfe talks as though no one is trying to
fix the trouble. There already *are* people working hard trying to fix
the trouble, and they know a lot more than he does.

> > > 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.

That doesn't tell you squat about bandwidth. At best, you can find a
really bad link that way, but there is no way to quantify the problem,
and no way to detect things like how much traffic is hitting that link.

The only way -- the ONLY way -- to determine link utilization from the
outside is with a management protocol like SNMP.

Perry