milazzo@RICE.EDU (Paul Milazzo) (04/01/88)
The lack of link-level checking in SLIP has caused us no end of
trouble. Higher-level checksums help, but NOT enough.
The connection in question is a link to a site located a few blocks off
campus. Engineered for the lowest possible cost, the link consists of
two leased cable pairs, each 4 to 5 miles long, driven by limited-
distance "modems"; it connects two SUN 3/1xx machines speaking SLIP at
9600 baud through console serial ports. The MTU is 576 bytes.
The link performs poorly: late at night, perhaps 2% of 50-byte
datagrams and 30% of 500-byte datagrams delivered contain errors; the
daytime error rate is usually higher. Fortunately, the link, while
important, is lightly used.
UDP sans checksums was predictably a disaster; the off-campus domain
server contained the strangest cached information imaginable.
Activating UDP checksumming on all our name server hosts protects local
domain traffic; it does NOT protect the off-campus site from errors in
non-checksummed domain packets originating elsewhere in the Internet.
TCP traffic is of course immune to link-level vagaries, right? Wrong.
I have rcp'ed and FTPed many large files over this link; more often
than not they arrive damaged in some subtle way. Let me repeat: files
transmitted via image (TYPE I) FTP between identical hosts separated by
a single SLIP link often fail to survive the trip.
I have not analysed in detail the damage to the data, but the effect is
real, if difficult to explain. I can only imagine that at the error
rates we experience, damage transparent to the IP checksum algorithm
sometimes occurs. I believe a link-level CRC would pass fewer errors.
If not, it would at least pass DIFFERENT errors, substantially
improving the error detection when used together with the IP checksum
algorithm.
The morals of our story:
1) Make sure your domain server host checksums UDP packets.
2) Sometimes TCP checksums are not enough.
Paul G. Milazzo <milazzo@rice.EDU>
Dept. of Computer Science
Rice University, Houston, TXlarry@pdn.UUCP (Larry Swift) (04/07/88)
Are you talking about checksums or CRC's (cyclic redundancy checks)?
They're not the same.
Larry Swift UUCP: {codas,usfvax2}!pdn!larry
Paradyne Corp., LF-207 Phone: (813) 530-8605
P. O. Box 2826
Largo, FL, 34649-9981 She's old and she's creaky, but she holds!milazzo@RICE.EDU (Paul Milazzo) (04/08/88)
Larry Swift asks:
"Are you talking about checksums or CRC's? They're not the same."
I'm not sure to which mention you refer, but I'll try to clear up any
ambiguities. My original message discussed four distinct data
integrity tests, in the following order:
1) I used the phrase "link-level checking" to mean any data integrity
test applied at the Data Link layer.
2) I used the phrase "UDP checksumming" to mean the IP header checksum
algorithm as applied to UDP datagrams, with 0 meaning "no checksum".
3) I used the phrase "IP checksum algorithm" to mean the checksum
algorithm described on p. 14 of RFC 791, applied to IP headers and
TCP segments.
4) Finally, I used the phrase "link-level CRC" to mean any of the class
of polynomial error-detecting codes known as Cyclic Redundancy
Codes, applied at the Data Link layer.
Previous messages dismissed the need for Data Link layer integrity
tests with the argument that the existing TCP and UDP checksums provide
an end-to-end integrity test, and that with such a test, hop-by-hop
tests are unnecessary. The point of my message was to question
RFC 791's description of the effectiveness of the IP header checksum
algorithm: "experimental evidence indicates it is adequate". MY
experimental evidence indicates otherwise.
I hope these clarifications answer your question.
Paul G. Milazzo <milazzo@rice.EDU>
Dept. of Computer Science
Rice University, Houston, TX