North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: outages, quality monitoring, trouble tickets, etc
- From: Alan Hannan
- Date: Sat Nov 25 15:34:29 1995
......... Sean Donelan is rumored to have said:
] Customer service should be of interest to operations folks, at least
] to the extent the problems are getting reported to the right people to fix.
It certainly is here.
] I doubt I can change anyone's mind that providing explanations to
] customers and non-customers when the network has problems is good for
I agree with you that it is important.
] In the future I will simply recommend to customers to buy
] services from NSPs which do provide explanations when their networks
] fail. Since I haven't found a perfect network yet, I suspect it
] includes everyone on this list.
alan> rope to the other guy. It just doesn't work, there's nothing in
alan> the system to encourage it.
What I mean by saying this is NOT that I don't think a per-NSP
trouble reporting mechanism is a good idea. What I'm saying is
that within our Internet arrangement today, I don't see that it's
terribly capitalistically useful for NSP-A to adverise internal
problems to NSP-B. There is no doubt in my mind that it IS
terribly useful for NSP-A to advertise internal problems to
NSP-A's customers, as well as to NSP-B if they inquire on behalf
of NSP-B's customers wrt an outage internal to NSP-A. You're
right the migration of customers is a good metric, but it's hard
to quantify that migration wrt trouble reporting to management.
A friend at MFS brings up a good point, that being that the COREN
agreement stipulated for a trouble reporting list.
Perhaps we could work to develop a scalable model of such for
world wide Internet use, or adapt that to this.
Any other suggestions?
] If you aren't providing the level of service I need, I'll go to someone who
] can. If XYZ's NOC gives me better service than ABC's NOC, I'll
] recommend XYZ to my customers.
Adam Smith's rules _will_ follow us into the Internet. Agreed.
] > Sprint. I certainly see no reason why I should do this work for
] > you.
] Because it is in their self-interest? You are correct I can't make
] anyone run their network how I would like it run, not even MIDNET (GI).
] But I can point out long-term problems and code of silence is costing such
] providers money, and has already cost them customers.
It's not a code of silence. That's my point, that being that
historically when we are asked about problems we give darn good
answers. That we don't directly advertise problem attention or
resolution is not correlative to our response to requests.
Should we provide darned good answers? - YES
Should we provide automated Darned Good Answers to our customers?
- YES, it would be nice
but not a NEED,
rather a nifty
Should we provide automated Darned Good Answers to other NSPs?
- YES, it would be nice
but not a NEED,
rather a nifty
] I might call BARRNET because the University of California-Davis has
] reported problems reaching DRA to DRA's help desk, and the problem hasn't
] been resolved. No, BARNET doesn't *have* to talk to me. And I will
] report the same back to the customer. However, I suspect it is in
] BARRNET's self-interest to work with me in resolving the problem
] to ensure UC-Davis has end-to-end reliability.
I agree it is too. However, when I hear people complaining about bad
NOCs, I think it is important to point out that there is no
mechanism in place to hold those other NSPs accountable as the
person complaining is rarely the customer of the NSP. Yes it's in
our long term interest, but that doesn't mean there's something in
place to encourage it other than honest intention.
] I track network reliability by dollars (not packet loss, not latency).
] I measure network providers, good and bad, by how many of our customers
] have used their own dollars to buy private lines to St. Louis because
] they couldn't get the reliability they needed from the network provider.
] As I said before: Ideally I want a reliable network. If you can't
] provide a perfectly reliability network I want an explanation when I
] can't get through. And I want the problem fixed. The better the
] explanation, the longer I'm willing to give you to fix the problem. If
] I get no explanation, I expect the problem to already be fixed.
This is a good point, and I have been more convinced that it is
Because of this discussion I am going to work to develop an
automated WWW status page.
] The current situation is the customer gets neither the explanation nor
] action solving the problem.
I appreciate that NSP response is not always ideal. However, I
would encourage all people who get a less than exceptional
response from a NOC technician to escalate the question so as to
improve the NOC quality. No, this isn't something you should have
to do, and it's not something that makes anyone terribly proud but
it does tend to improve the service by natural tech selection.
] Since the technicians seem to be having a very difficult time fixing
] the network, I thought upper management could meet my other goal. Give
] the customer an explanation.
This is done when they ask, and due to your and others concern, I
am going to work to develop an automated web page showing down
] The Internet is a global cooperative network. If people don't cooperate,
] the global nature of the network fails.
] Can't NSPs provide their customers an explanation at least as well as
] the US Post Office?
Yes, it's possible, and due to this discussion, I am going to work
to build one as nice as FedEx's.... Anyone want to volunteer
joint development? :)