Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!pasteur!ucbvax!ANDREW.CMU.EDU!ddp+ From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: Date: 30 Mar 88 04:42:48 GMT References: <8803300417.AA14103@beno.CSS.GOV> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 28 > I still maintain that in the real world, there is no need for > a checksum with packet transmission. IP and TCP do it fine. > Does anyone REALLY have proof that it is necessary to complicate the> > protocol? The unfortunate proof is in UDP. Adding a CRC (not a checksum!) is a necessary result of some vendors (read SUN) reluctance to use checksums. The UDP spec unfortunately allows this. Although most people disagree with this decision (not to checksum UDP), we decided to add the CRC to SLIP so that you have a lower chance of getting burned if you are following the spec. Calculating and sending the CRC really isn't a big deal. Depending on the implementation, the CRC calculation can be done incrementally with each character received thereby amortizing the cost over each character. Combined with table driven crc calculations, the cost is very low. It can also be argued that the time to send the crc is not a big deal if you use even crude compression schemes. I intend to document simple header compression schemes (similar to Noel's scheme) and probably some simple forms of run-length encoding for the data. > The biggest virtue of "my" SLIP is that it is so trivial to implement. > A big part of that reason is that it makes TCP/IP do the > retransmission & error detection. We are not making SLIP non-trivial. We are still counting of TCP/IP to do the retransmissions (error correction). We are only making it do error detection which is *much* simpler. It is not going to be anything like TCP or LAPB as was suggested by previous RFC's. Drew