links on the blink (fwd)

Mon Nov 6 00:39:05 UTC 1995

>worked so hard on achieving. My hope was that you guys would do better
>than we did, and provide a ubiquitous high quality network (we did high
>quality, but not ubiquitous). Are you going to get to work and fix it,
>or continue to screw it up and whine around about the heat in the
>kitchen? Your choice.

It may just be culture shock going from the role of Internet insider,
to Internet outsider.  But from the point of view of someone who has
always been an outsider, things don't really seem that different than
they have in the past.  The net goes through cycles of good bandwidth
headroom years, and lean bandwidth headroom years.  The engineers have
always been too busy trying to hold the whole mess together to explain
to the Internet populace what was going on.  End-to-end network usability
has been a persistent problem for the decade+ I've been using the net.

The Internet insiders may have been working very hard on management
issues.  But from the outsider's point of view, the historical net
cycle goes something like this.  The net's usability slowly declined
over the years until reaching a level even network engineers couldn't
hand over, then it would suddenly take a leap to a new bandwidth
plateau.  Yes, network engineers have a long history of finger-pointing
and handwaving.  But in the past there wasn't anyone who could give a
second-opinion.  The few end-users who try to measure their perception
of the network usability have historically been shouted down.  It doesn't
seem to matter if there is a high correlation between ping loss rate,
and user perception of network performance.  All the network engineers
know this is a "flawed" testing methodology.  This isn't unique to the
Internet community.  End-users who have the audacity to test their own
electrical, telephone, or water service are usually greeted with equal
scepticism in by those industries' engineers.

Ok, maybe "Internet Management" is an oxymoron.  But the lack of centralized
management isn't always a bad thing, as long as we can find some invisible
hand to guide us.

NOC trouble ticket practices, accounting, measurements, and so forth have
been on and off the IETF agenda for years.  If they were easy problems,
I suppsoe they would be solved by now.

How about a few positive suggestions which could be implemented in
the short-term.

The NSFNET Newsletter, Network Status Report list, monthly statistics,
and the asnnn at merit.edu and techs contact lists were helpful in generating
a consensual reality.  

Perhaps IDG would be interested in publishing a NANOGWorld, free to
"qualified" subscribers chock full with exciting cisco advertisements :-).
In the meantime, Sprint's outage list, and UUNET's uunet.status newsgroup,
and PSI's and UUNET's World Wide Web pages keep folks informed their
network status.  I wish more network providers had these services.  I
wish my own network providers provided these services.

Statistics seems to be the toughest issue.  But also an important one
for communicating the state the net with Internet outsiders.  AT&T always
tells the world how many phone calls were made through its network on
Mother's day, or after an earthquake.  There are two reasons for this.
One is to say how important AT&T is.  The second, more important reason,
is to help generate a state of mind in their customers why the network
may have flaked out on those days.

Yes, statistics can lie.  But even hard lies are better than hand-waving.

And finally, a plea for a common method of notifying a network provider's
NOC of a potential problem.  If you never hear about the problem, how
can you fix it.  I understand everyone gives their own customer calls
priority.  But sometimes even my provider's provider's provider can't
figure out how to contact different noc's.  noc at somewhere, trouble at whatever,
engineer at wherever, action at whoever, etc, etc, etc.  My rolodex is crumbling
under the weight of keeping track of who works where this week.  If
folks want to write a Best Common Practice, this is one area that could
really use it.
--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation