kell@eric.mpr.ca (Dave Kell) (06/11/90)
Does SLIP have the same level of error detection and correction that ethernet-based IP has? Dave Kell MPR Teltech Ltd.
romkey@asylum.sf.ca.us (John Romkey) (06/13/90)
Dave Kell asks: Does SLIP have the same level of error detection and correction that ethernet-based IP has? IP and its transport protocols (TCP or UDP or whatever) running over SLIP will use the same error detection algorithms (IP header checksum, TCP or UDP data checksum) that they will over ethernet. SLIP doesn't include any error checking; it just frames the packet over an asynchronous link. Ethernet does a CRC check of each packet, so there is a difference at this level. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com "There is no loyalty except loyalty to the party. There is no love except love of Big Brother. All competing pleasures we will destroy." - 1984 (film)
jbvb@VAX.FTP.COM (James B. Van Bokkelen) (06/13/90)
Does SLIP have the same level of error detection and correction that ethernet-based IP has? IP has header checksums, and they're the same wherever IP is run. Likewise, the TCP checksum is mandatory. UDP can optionally use the same algorithm, but some vendors believe this costs too much speed, so they omit them, regardless of the network media. IP and UDP have no "correction" in and of themselves, but TCP will do retransmits if the checksum catches damage, or packets are lost altogether. What Ethernet has that SLIP doesn't is a link-layer CRC-16, which can do a pretty good job of detecting damage while on the cable. SLIP has no error detection at all at the link layer. Of course, the Ethernet CRC-16 may not detect packets damaged in the interface, or in the host before transmission or after reception. This sort of undetected lower-layer damage happens much more often than the optimistic crowd would like to believe, and is at the root of the widely held belief that "end-to-end checksums are a Good Thing". James B. VanBokkelen FTP Software Inc. jbvb@ftp.com 617-246-0900
goldstein@carafe.enet.dec.com (Fred R. Goldstein) (06/13/90)
In article <9006130114.AA05996@vax.ftp.com>, jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes... >What Ethernet has that SLIP doesn't is a link-layer CRC-16, which can >do a pretty good job of detecting damage while on the cable. SLIP >has no error detection at all at the link layer. Of course, the >Ethernet CRC-16 may not detect packets damaged in the interface, or >in the host before transmission or after reception. Slight correction. Ethernet, like 802.{3,4,5}, has a 32-bit CRC, not a 16-bit CRC. (BTW, "CRC-16" is the name of the bisync/DDCMP 16-bit checksum; "CRC-CCITT" is the 16-bit HDLC checksum. CRC-32 is the LAN checksum, also optional in HDLC, and historically developed for Autodin-II.) The 32-bit Ethernet checksum maintains a Hamming distance of 4 up to the maximum Ethernet packet, or for that matter up to about 12K bytes. Thus ANY 3 bit errors will be caught, or any one error of under 32 bits. A 16-bit CRC maintains a Hamming distance of 3 up to 4K bytes. Exceed that error limit and you're subject to a "crap shoot" of 2**n for n bits of CRC. With 32 bits, that's a very low probability of undetected error no matter how you slice it. The TCP and IP checksums are straight arithmetic. Frog two 16-bit words and you've got an undetected error. The right two-bit error combo will be undetected. It's a whole lot better than nothing, but not as good as the Fletcher checksum and that's not as good as the more computationally intensive CRC (which is usually done in hardware). SLIP, with no checking whatsoever, is a bad joke. PPP uses CRC-CCITT, which is pretty good (for reasonable MTUs). Ethernet is close to bulletproof, with regard to line noise induced error. (Host error is, as the man said, another story. TCP's checksum is mainly there to detect it.) --- Fred R. Goldstein goldstein@carafe.enet.dec.com or goldstein@delni.enet.dec.com voice: +1 508 486 7388 opinions are mine along; sharing requires permission
jdg0@GTE.COM (Jose Diaz-Gonzalez) (06/14/90)
In article <12435@shlump.nac.dec.com> goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes: > >SLIP, with no checking whatsoever, is a bad joke. PPP uses CRC-CCITT, >which is pretty good (for reasonable MTUs). Ethernet is close to Could some one explain what PPP is, or where can I find more info about it? Thanks. -- Jose +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + + Jose Pedro Diaz-Gonzalez + + + SrMTS + + + GTE Laboratories, Inc. + Tel: (617) 466-2584 + + MS-46 + email: jdiaz@gte.com + + 40 Sylvan Rd. + + + Waltham, MA 02254 + + + + + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
jbvb@VAX.FTP.COM (James B. Van Bokkelen) (06/14/90)
Normally I know better than to say CRC-16, but... Sorry. 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. James B. VanBokkelen FTP Software Inc. jbvb@ftp.com 617-246-0900
sl@van-bc.UUCP (06/18/90)
In article <30819@cup.portal.com> thinman@cup.portal.com (Lance C Norskog) writes: > 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. There are other issues. When you turn MNP on you increase (the already bad) latency of packets traversing the link. We run SLIP over a V.32 modem (T2500). We could turn on the reliable mode, but find we get better performance if we don't. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice)
thinman@cup.portal.COM (06/18/90)
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
jc@minya.UUCP (John Chambers) (07/06/90)
In article <30819@cup.portal.com>, thinman@cup.portal.com (Lance C Norskog) writes: > 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. Be careful here. Where I work, we've been running SLIP over some modems that do MNP, and we use raw mode. The reason is that the MNP comes with software flow control, which means that any packet with a ^S causes the link to die. It usually doesn't take too long for such a packet to come along. I spent of bunch of time on the phone with Customer Support people at the manufacturer (Codex), trying to figure out how to correctly configure the modems, and all I got from them was "Of course you want flow control; you'll lose data without it." They couldn't conceive of an application that didn't care about lost data. If there's a way to do MNP that lets *all* 8-bit values pass, they wouldn't or couldn't tell me how to do it. If anyone out there knows how to do it, I wouldn't mind getting some email on the subject... -- Typos and silly ideas Copyright (C) 1990 by: Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers) Home: 1-617-484-6393 Work: 1-508-952-3274