links on the blink (fwd)

Michael Dillon michael at
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                             E-mail: michael at

More information about the NANOG mailing list