links on the blink (fwd)

Wed Nov 8 05:36:25 UTC 1995

On Tue, 7 Nov 1995, Steven J. Richardson wrote:

>   Of course you are correct; if you observe the links over a
> long enough time, you will see loss.   I hope that the orders
> of magnitude between 10% loss and 1E-4/1E-5 make an impression
> on persons saying that the first number is acceptable.

You are misinterpreting my statements and I think this is because you are 
forgetting the time element. Even 100% packet loss is acceptable and was 
frequently occurring on the old NSFnet. If you measure over the time 
interval that a 1500 byte packet takes to traverse a gateway then loss of 
a single packet will register as 100% loss.

So in order to state what percentage of loss is acceptable and be 
unambiguously understood, you need to specify the time element. Of 
course, I am also guilty of not explicitly stating this time element.

Then there is the difference between what loss is acceptable and what 
loss is desired. It is likely that most core NSP's would consider a 
DESIRABLE packet loss rate over an hour of time to be .001% but it is 
also possible to simultaneously consider 10% packet loss over the same 
time period to be ACCEPTABLE as long as it does not occur during more 
than one hour out of 24. Note the similarities between my statement re 
10% and the familiar refrain from polling companies, "accurate to within 
2 percentage points 19 times out of 20".

To get a REASONABLE standard of packet loss you have to qualify your 
numbers by saying that a loss rate of .001% 23 hours out of 24 is 
desirable but a loss rate of 10% 1 hour out of 24 is acceptable. This 
recognizes the reality of today's global Internet which is not anywhere 
near fully meshed and which is experiencing sustained surges of growth. 
Just like in a race condition, sometimes the NSP's will fall behind due 
to line failures and equipment failures and new equipment shipping 
failures and so on.

We don't get anywhere by slamming NSP's for aberrations even if those 
aberrations recur on a daily basis for short periods of time because the 
Model T Ford level of network technology that we are using just doesn't 
allow them to do much better.

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