Path: utzoo!mnetor!uunet!husc6!think!ames!pasteur!ucbvax!SUN.COM!melohn
From: melohn@SUN.COM (Bill Melohn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SLIP working group?
Message-ID: <8804030943.AA11156@sluggo.sun.com>
Date: 3 Apr 88 09:43:23 GMT
References: <8803300501.AA14341@beno.CSS.GOV>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: melohn@Sun.COM (Bill Melohn)
Organization: Sun Microsystems, Mountain View
Lines: 24

Error detection should be implemented as close to the potential source
of the error as possible. In a IP link from my home PC to my
workstation, there might be 5 hops, 4 of which are over various LANs
and gateways all using CRCs and 1 SLIP on a lossy voice grade phone
line with no error detection. With an end-to-end checksum, all of
these links are treated equally, and as a result, packets which get
mangled on my phone line are passed in mangled form throughout my
reliable but heavily loaded internet only to be thrown away at the
destination because of a bad checksum. Worse, because this checksum
has to be calculated and compared, it uses cycles on the CPUs at both
ends. Even worse is that fact that in 4bsd this is a host wide option,
so if I have a single SLIP based client of my NFS fileserver and I
want him to get checksummed packets, I have to checksum packets for
all Ethernet only local users as well, users who are more likely to be
concerned with speed and not with data corruption on the Ethernet. It
seems to me that the sooner I can detect that a packet has been
corrupted, the sooner I should throw it away and initiate a
retransmission of the data, minimizing both the end-system CPU and the
total network bandwidth spent.  CRCs are commonly implemented in
hardware on Ethernet, in various syncronous serial chips, and on many
modems. Why not in SLIP framing as well?  End-to-End checksums
certainly have their place, but depending on them alone to catch data
errors on a variety of media in a complex internet wastes both net
bandwidth and host CPU.