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@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@somewhere, trouble@whatever, engineer@wherever, action@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
I believe that the central issue remains the lack of an accepted, and maybe codified in the form of binding text, agreement between a service provider and a customer. The current debate about what percentage packet loss is acceptable is meaningless without including some notion of what the *cost* of that packet loss is to the person or application suffering that loss. We need to address a central simple question, viz. "What is the service provider selling ?" or, "What is the customer buying ?" [hopefully the answers match :)-] The phone company does not make any promise of global reachability. They would be stupid to do so, as everyone knows that PacBell has no control over Bell Atlantic or France Telecom, for example. What they *do* do is assure, and, more importantly, reassure us when we try to reach France and cannot, that they are tracking the problem. This facet is, for the most part, missing in today's Internet. Perhaps the BMWG can work on a template for an agreement between a customer and a provider that .. a. sets realistic customer expectations. b. binds the service provider to providing some insight into performance of its own network, in the form of easily obtainable figures of merit. c. sets guidelines for problem tracking and resolution times. Sort of a connectivity MTTR. Customers can then choose amongst competing service providers on more than a price basis. Service providers can then compete on the basis of fulfilling these customer expectations. Another aspect is fate-sharing. No, not in the EID sense ;)- AT&T is quite dependant on MCI having their act together on the technical end of things to sustain its own voice business. Yes, they compete ferociously on Madison Ave., but they do co-operate in the trenches. They have to. They have a common fate. [It remains to be seen how this will work when baby bells are allowed to compete for IXC business.] How important is it for Sprintlink that InternetMCI remain stable ? I know that some of the more established NSPs talk frequently, and use this list also. What about the newer guys ? Do they have a sense of fate sharing ? Any johnny-come-lately with a Linux box, gated and a few thousand dollars can become a service provider. While I like the fact that the monetary barrier-to-entry is low, I don't like that they don't all recognize the fate-sharing inherent in the Internet service business. Unless we address some of these tough issues, the Internet may not take that next step into becoming a serious infrastructural resource comparable to the highway system, the phone system or even the U.S Mail system (where a lost "packet" can have a quantifiable cost, and disgruntled "routers" have been known to shoot their frustrations away :)- ) Thanks, -- Bilal
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.
....
......... Bilal Chinoy is rumored to have said: ] ] I believe that the central issue remains the lack ] of an accepted, and maybe codified in the form of ] binding text, agreement between a service provider ] and a customer. I agree, however is that an issue re: nanog? Certainly it pertains the operations of our NA nets, however I'm not certain that it really concerns the interconnections of us as net ops. ] The current debate about what percentage packet loss ] is acceptable is meaningless without including some notion of ] what the *cost* of that packet loss is to the person or ] application suffering that loss. Erm, perhaps, however I think before we start analyzing what these folks ought to do, we ought realize that this is not tarrif-land. This is capitalistic enterprise (erm, hi there, NSF! ;). The relationship between us and our customers may or may not specify certain levels of service. If they don't spec. a certain quality, then in my humble nonlegal opinion, the poor customer ought be happy to get what they get. Along the lines of getting what you pay for. (that's not to say I don't want perfect connectivity for my customers that's why I'm online at 4am, but if it's not in the contract, it's just that -> a want, not a right) That's not to say it isn't poor and terribly inconvenient, however the gripe is not with the president of the Internet (that's a joke son) the gripe is with their upstream provider. You need someone accountable. I am accountable to my customers. Sprint and MCI are accountable to me. The NAPs and psuedo-NAPs ought be accountable to those latched up. * More Accountability -> Less Blame * Idealistic ravings, but if they were inked on paper at the lower levels the folks complaining about their 8% packet loss might have a legitimate grief. When I hear someone in the states complaining about packet loss in another country and expect we as internet crossing guards to be responsible, it's rather frustrating. If on the other hand the contract specifies a certain level of service (*cough* COREN) then the smaller fish have a legitimate grieve. ] We need to address a central simple question, viz. ] "What is the service provider selling ?" ] or, ] "What is the customer buying ?" ] ] [hopefully the answers match :)-] But if that's not put to paper, then how are we supposd to arrive at the answers until the next set of contracts are drawn? -alan
participants (3)
-
Alan Hannan
-
bac@serendip.sdsc.edu
-
Sean Donelan