Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!MATHOM.CISCO.COM!BILLW From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) Newsgroups: comp.protocols.misc Subject: Re: SLIP: Why are people so reluctant to use it? Message-ID: <12630877138.27.BILLW@mathom.cisco.com> Date: 18 Oct 90 23:20:22 GMT References: <1990Oct16.225610.3505@oracle.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 33 However, it seems that everyone I ask about SLIP seems to speak ill of it, and curiously mostly "heard that it's bad" not "used it and it was bad." I hear comments about it being slow, but is it SLIP, or merely the serial line? E.g., what does one expect off a 9.6k line? I did hear one concrete complaint; that SLIP does not do error correcting efficiently (or at all?)- is this true? SLIP does no error correcting. This is not a problem - IP doesn't do and error correcting either. The big problem is that it doesn't do any error detection either (whereas HDLC and Ethernet have 16 and 32 bit CRCs). Now, IP does have a HEADER checksum, and both UDP and TCP are SUPPOSED to checksum the data portion of the packets, there are cases (NFS comes to mind) where this is not necessarily true. Furthermore the IP/UCD/TCP checksum algorithm is not designed to detect the sorts of errors that can occur over async data paths. This is not just an accademic problem - real data has been corrupted over cnonections where it looks like everthing was going fine. I have used SLIP, but from a user standpoint a couple of years ago. It wasn't the fastest when running RFS over it, but it was cheaper than buying an ether- net board. So in summary, is SLIP all that bad? Are there other relatively standard methods of running TCP without sizable investments in hardware? Slip isn't that bad, especially if you use the headercompressing, CRCing CSLIP. It is not esthetically pleasing. Have you priced ethernet boards recently? I see them advertised all the time for less than $150 (for PCs). BillW -------