nanog mailing list archives
Re: links on the blink (fwd)
From: Michael Dillon <michael () memra com>
Date: Wed, 8 Nov 1995 15:09:10 -0800 (PST)
On Wed, 8 Nov 1995, Curtis Villamizar wrote:
We also allow a very small number of SES. I think it is 60 or 90 SES per day with a lower threshhold on any 15 minute interval. This is reported in the DS3 MIB. One hour of loss has never been acceptable. The NSS routers are pps limited but rock solid below a certain pps ceiling. We have strived to work around this by arranging our topology to avoid exceeding the pps limits until we can replace these routers. The goal here is to keep below 10^-4 packet loss over 15 minute periods including cicuit or FDDI congestion within our core. Only tail circuits to customers are allowed to congest (as long as that is all the customer is willing to pay for for their attachment). Lately we have been having difficulty with the pps limits but nowhere near 10% even briefly. At certain hot spots we have occasionally set up temporary shell programs checking error rates on a 1 second interval, saving intervals with high error rate. We will probably have to adjust our topology again to distribute traffic differently and have ordered circuits specifically to avoid loss. The point is that not everyone accepts high loss rates as "normal".
Depends what you mean by normal. I understand that as an NSP you don't accept high loss rates as normal and ignore them. You monitor loss rates and take action to deal with them. But the fact is that in todays Internet it is a normal state of affairs for end users to experience high loss rates from time to time on some of their connections. The end user must accept this since it as a fact of life and totally beyond their control or their ISP's control. In fact, I suspect it is even beyond your control. You are not able to predict 100% of the time where congestion will occur and what will be needed to cope with it. All you can do is detect it fast, and act fast to fix the problem. During the interval between the first occurence of the problem and the fix, end users have to live with congestion. That's what I mean by "normal". Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael () memra com
Current thread:
- Re: links on the blink (fwd), (continued)
- Re: links on the blink (fwd) Alan Hannan (Nov 08)
- Re: links on the blink (fwd) Tim Salo (Nov 06)
- Re: links on the blink (fwd) Steven J. Richardson (Nov 06)
- Re: links on the blink (fwd) Curtis Villamizar (Nov 06)
- Re: links on the blink (fwd) Jeremy Porter (Nov 06)
- Re: links on the blink (fwd) Curtis Villamizar (Nov 06)
- Re: links on the blink (fwd) Vadim Antonov (Nov 06)
- Re: links on the blink (fwd) Steven J. Richardson (Nov 07)
- Re: links on the blink (fwd) Michael Dillon (Nov 07)
- Re: links on the blink (fwd) Dave Mills (Nov 08)
- Re: links on the blink (fwd) Curtis Villamizar (Nov 08)
- Re: links on the blink (fwd) Michael Dillon (Nov 08)
- Re: links on the blink (fwd) Michael Dillon (Nov 07)
- Re: links on the blink (fwd) Jeff . Ogden (Nov 08)
- Re: links on the blink (fwd) Hans-Werner Braun (Nov 08)
- Re: links on the blink (fwd) Michael Dillon (Nov 08)
- Re: links on the blink (fwd) Hans-Werner Braun (Nov 08)
- Re: links on the blink (fwd) Michael Dillon (Nov 08)
- Re: links on the blink (fwd) Dennis Ferguson (Nov 08)
- Re: links on the blink (fwd) Michael Dillon (Nov 08)
- Re: links on the blink (fwd) Dave Mills (Nov 10)
- Re: links on the blink (fwd) Michael Dillon (Nov 08)
- Re: links on the blink (fwd) Hans-Werner Braun (Nov 08)