links on the blink (fwd)

Jeremy Porter jerry at fc.net
Tue Nov 7 06:27:09 UTC 1995


>In message <199511062018.PAA08597 at home.merit.edu>, "Steven J. Richardson" write
>s:
>>  
>>   Uh...  Michael, when we were running the NSFNET, as Hans-Werner and
>>   many readers of this list are well aware, we did _not_ accept 10% packet
>>   loss on any link or across the network.  These problems stayed with 
>>   the NSFNET NOC until resolution by the provider, MCI.  We only considered 
>>   -0%- loss to be acceptable.
>Steve,
>
>Enough of your wild stories of -0%- loss.  :-)  The correct figure was
>10^-5 for acceptance with 10^-4 being the maximum threshold we would
>accept on a running circuit before contacting MCI to take the circuit
>in a maintenance window for diagnostics.  That doesn't mean we
>wouldn't bug MCI to get the circuits back perfectly clean.  ;-)
>
>We still have the same criteria.  I think MCInet is also as vigilant.
>
>Curtis

This still does not address the orginal question/problem.  Its
not network providers internal links that are the problem.  The
physical T-1s and T-3s, etc tend to work very well or not at all.
The problem is related to router load and interconnect design.
If people are reporting packet loss through MAE-East shared FDDI,
then who do you yell at?  Obivously the person connected to the
shared FDDI.  Unforunately it is not clear to the expirenced user
or operator how someone is connected to the mae, just based on
traceroute data.  This seems particarly silly since the price difference
between the shared FDDI and the switched FDDI is such a small percentage.

The real question is what percent loss is acceptable in your peering
sessions with other providers?  Apparently on the Internet as a whole
this too often seems to be 100%. 

-- 
----------------------------------------------------------------------------
|  Jeremy Porter (512)-339-6094 Freeside Communications, Inc. info at fc.net  |
|  jerry at fc.net  (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753    |
---------------------------------------------------------------------------- 



More information about the NANOG mailing list