links on the blink (fwd)
michael at memra.com
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
More information about the NANOG