Path: utzoo!utgpu!watserv1!watmath!att!emory!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!isolde!hta From: hta@isolde.Berkeley.EDU (Harald Tveit Alvestrand) Newsgroups: comp.protocols.iso Subject: Re: question about transport layer protocol Summary: The theory is (almost) right, but the practice? Keywords: X.21 without HDLC is Class B Message-ID: <1991Jan24.102405.15664@ugle.unit.no> Date: 24 Jan 91 10:24:05 GMT References: <1991Jan18.220611.14357@bronze.ucs.indiana.edu> <42617@cos.com> <1991Jan22.214654.5942@ugle.unit.no> <42726@cos.com> Sender: news@ugle.unit.no Reply-To: harald.alvestrand@elab-runit.sintef.no Organization: ELAB-RUNIT, SINTEF, Norway Lines: 84 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