Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!pasteur!ucbvax!n3dmc.UUCP!johnl
From: johnl@n3dmc.UUCP (John Limpert)
Newsgroups: comp.protocols.tcp-ip
Subject: SLIP link error correction
Message-ID: <8804042119.AA00280@n3dmc.UUCP>
Date: 5 Apr 88 01:19:04 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27

Link error correction may be desirable in some situations, but I don't
think it belong in SLIP.  SLIP should be a simple, easy to implement
method for transmitting/receiving packets.  The addition of a link level
CRC check doesn't bother me, it would be easy to implement, reduce the
chance of undetected data corruption and do minimal violence to the
existing SLIP 'philosophy'.  The addition of the retransmission of
damaged packets adds a great deal of complexity, assumes a bidirectional
link, and provides a completely different service.  This should be a
separate protocol.  SLIP should not be asked to do more than datagram
encapsulation.  Any changes should be upwards compatible with existing
implementations and not change the ability to implement it as a simple
simplex transformation. 

I do support the addition of an optional link level CRC check.  The
table lookup computation of 16 or 32 bit CRC's is a relatively cheap way
of adding reliability.  The existing IP checksum is adequate for
assuring end-to-end integrity, but I don't think it is appropriate for
link level error detection.  Don't tell me to buy a bunch of MNP modems,
I had a hard time acquiring the existing dumb modems.  The
telecommunications Czars (TELCO and LOCAL) are not interested in my
problems.  I have to live with noisy, voice grade lines and dumb modems. 

John Limpert	bellcore!wb6rqn!n3dmc!johnl
		johnl@n3dmc.UUCP

P.S. If someone could mail a copy of the VMTP RFC to johnl@gronk.UUCP,
it would be greatly appreciated.