🚀 go-pugleaf

This turned out LONG, I summarize:
- The acceptable rate of undetected network errors is application dependent.
- Class A and B networks should have LOW rates of corrupted packets
  that are delivered to the user (instead of causing a reset).
- Class B networks (for a given application) disconnect/reset more often
  than Class A networks. That is the ONLY difference.
- The RTS service does not guard against data corruption.

Now for the longwinded answer:

In article <42726@cos.com>, howard@cos.com (Howard C. Berkowitz) writes:


|> I'm afraid I disagree.  It is not a basic OSI assumption that the
|> network service will be error-free.
|> 
|> There are two kinds of errors which go into the definition of a 
|> Class A, B, or C network.  The first kind is indeed data corruption,
|> while the second is undetected disconnection.   Class A protects against
|> both types, Class B protects against disconnections only, and 
|> Class C against neither.
|> 
When in doubt, quote.
ISO standard 8073-1986(E), page 7, section 5.4.3, "Choice of network
connection"

a) Type A: Network connection with acceptable residual error rate (for
example not signalled by disconnect or reset) and acceptable rate of
signalled errors.

b) Type B: Network connections with acceptable residual error rate (for
example not signalled by disconnect or reset) but unacceptable rate of
signalled errors

c) Type C: Network connections with unacceptable residual error rate."

Same page, section 5.4.1, "General":
"NOTES:
..
2  Classes 0 to 3 do not specify mechanisms to detect unsignalled
network transmission failures"

The terms "error" and "transmission failure" are not defined in the
standard as far as I can see, but should include packet loss, packet
modification and packet duplication.

You are right that there is no assumption of the channels being
error-free here, or that they never disconnect or reset.
The difference between Type A and Type B is that Type B signals reset or
disconnect "too often".
The user should know the residual error rate of the connection, and
accept the *fact* that the ISO protocols of the layers above do not
provide any guard against the errors.
You are right that a channel with no error correction still may provide
Type A service if the demands of the service user are low enough.

However, I doubt that any *practical* user service (except broadcasting)
could live with undetected data corruption above the 10^-7 level at all.
(s/7/your favourite integer/)
I would start distrusting my mail service if I got "strange" spelling
errors every 1000 letters, and ASN.1 decoding errors every 1000 letters
for a heavily loaded mail node would be a total disaster.

|> may provide error correction.  For example, MHS(1984) contains the
|> Reliable Transfer Service, which allows it to correct some errors
|> not caught by Transport Class 0 or X.25 (e.g., duplication or loss
|> of packets caused by an X.25 Reset).

Yes, the Reliable Transfer Service is able to recover somewhat from loss
of packets, by using syncpoints, so that you do not have to start over
from the beginning. Class 0 takes care of possible duplication by simply
dropping the connection on reset. Class 1 to 3 guard against duplication.
However, the RTS does *nothing* to guard against packet corruption, so
that if this is considered a "network failure", then the "acceptable residual
error rate" for the network is VERY low indeed, leading to the
conclusion that error correction inside the network layer is absolutely
required for MHS(1984) use of Transport class 0.



                   Harald Tveit Alvestrand
Harald.Alvestrand@elab-runit.sintef.no
C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald
+47 7 59 70 94