stevens@hsi.UUCP (Richard Stevens) (09/22/88)
After going through a many SNA manuals, including the friendly FAPLs,
I've come to realize that SNA provides no reliability in terms
of a checksum at any level above the data link. Obviously you'll
have the data link reliability (16-bit CRC for SDLC, 32-bit FCS
for the token ring, etc.), but unlike TCP, UDP or Xerox's IDP,
there is no "checksum". Am I missing something ??
I'll assume the designers of SNA assumed that a DLC check was
adequate. Do TCP or UDP really need a checksum, especially when
running over an Ethernet, say ? I see that ISO only specifies the
use of a checksum for TP-4.
Richard Stevens
Health Systems International, New Haven, CT
stevens@hsi.uu.net
... { uunet | yale } ! hsi ! stevensstevens@hsi.UUCP (Richard Stevens) (09/22/88)
After going through a many SNA manuals, including the friendly FAPLs,
I've come to realize that SNA provides no reliability in terms
of a checksum at any level above the data link. Obviously you'll
have the data link reliability (16-bit CRC for SDLC, 32-bit FCS
for the token ring, etc.), but unlike TCP, UDP or Xerox's IDP,
there is no "checksum". Am I missing something ??
I'll assume the designers of SNA assumed that a DLC check was
adequate. Do TCP or UDP really need a checksum, especially when
running over an Ethernet, say ? I see that ISO only specifies the
use of a checksum for TP-4.
Richard Stevens
Health Systems International, New Haven, CT
stevens@hsi.uu.net
... { uunet | yale } ! hsi ! stevensNJG@CORNELLA.BITNET (Nick Gimbrone) (09/23/88)
It certainly is a bad idea (in my opinion) to 'count' on the reliability of the data link layer. A few years back we spent months discovering that a set of our modems had a failure mode which allowed bad data to be passed by the bisync CRC check being used in the 3705s.
hedrick@athos.rutgers.edu (Charles Hedrick) (09/24/88)
Richard Stevens asks whether it's enough to do checksums at the data link level. He says SNA only checks those, but doesn't do anything at a higher level. This issue came up a few months ago in connection with Sun's NFS. NFS turns off checksumming of UDP packets. It depends upon the Ethernet link-level checksums. That is actually fairly good as long as you are operating on a local Ethernet. The problem comes when you start doing NFS through gateways and in our case even serial lines. We got corrupted files due to a hardware problem in a gateway. I don't think we have seen any problems due to corruption by the serial line, but I wouldn't be surprised if we did at some point. A site I talked to about some DECnet problems (another protocol that depends upon link-level reliability) was having trouble due to a very noisy serial line. To be fair to DEC, the line wasn't under the control of a DEC router, and was using HDLC rather than DEC's DDCMP. On the other hand, the checksums being used by the HDLC chip were as strong as (actually I think identical to) those used by DDCMP. I think the consensus in the IP community is that if you care about your data, you do end to end checksums. Also, you probably don't want to depend upon the checksums to correct errors in high error rate situations. You want to clean up your lines, and depend upon the checksums to protect you against occasional glitches (and to tell you when a line needs fixing). You can get away depending on the link-level checksums if you go through only a few links, and you maintain them yourself (so you know when they are being flaky). But it's dangerous as a general practice. This is a major item of contention between Sun and certain customers, since at least as of SunOS 3.x there wasn't even a way to turn on checksumming for NFS. I don't know whether this is "Fixed In 4.0 (TM)".