links on the blink (fwd)
Michael Dillon
michael at memra.com
Wed Nov 8 23:09:10 UTC 1995
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 at memra.com
More information about the NANOG
mailing list