Path: utzoo!utgpu!watserv1!watmath!att!bellcore!rutgers!uwm.edu!zaphod.mps.ohio-state.edu!usc!apple!portal!cup.portal.com!thinman
From: thinman@cup.portal.com (Lance C Norskog)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SLIP reliability
Message-ID: <30819@cup.portal.com>
Date: 16 Jun 90 02:28:54 GMT
References: <9006141305.AA22966@vax.ftp.com>
Organization: The Portal System (TM)
Lines: 28

jvbv@ftp.com says:

> In my personal experience (which includes supporting a lot of TCP/IP
> nodes), I have only had one report of undetected data corruption in
> TCP (a transposition caused by a device driver bug while transferring
> a very repetitive raster file).  The combination of TCP and IP on
> SLIP seems fairly robust in practice: For two years our Internet link
> was leased-line SLIP, and I am using dial-up SLIP to send this, and
> I've never seen an error that got past the checksum.  This may be
> because there is a good match between the errors asynch lines tend to
> generate and those the checksum is likely to detect.

2 points: 
	1) If your NFS uses WD cards or any other card based on the National
chip set and does not use UDP checksums, you will get file data corruption
big-time.  The National 8390 Ethernet chip likes to randomly add and drop
bytes when copying twixt RAM and Ethernet; this is, of course, outside the 
enforcement range of the Ethernet checksum.

	2) If your SL/IP tosses packets when the hardware gives framing
or lost-byte errors, SL/IP should be very reliable.  If you run SL/IP over
modems, be sure to use MNP or some other error-corrected protocol.  These 
modems are so cheap that it's pointless running on a raw one.

Lance Norskog
Sales Engineer
Streamlined Networks
408-727-9909