brian@wb6rqn.UUCP (Brian Lloyd) (04/03/88)
The most important feature is to permit the link driver to discard
damaged packets. For this reason a SLIP link checksum is a good idea.
On the other hand this attitude of, "...but link error correction is
braindamaged," makes me uncomfortable. There MAY be an occasion where
doing link error correction could result in an improvement in
performance. I am not advocating that all SLIP links should offer link
error correction but rather am pushing for it as an option. Perhaps it
could be negotiated at link establishment and could be placed in the
"you don't really have to implement this option" catagory for those of
you who find the thought of link error correction repugnant.
As a user of TCP/IP over packet radio I can assure you that link error
correction does indeed have a place, especially when you have several
lossy links concatenated in given IP route. The throughput increase can
be dramatic. It may not be useful in all situation but it is HIGHLY
desireable in some.
Brian Lloyd, President
Sirius Systems, Inc.
(301) 540-2066
{bellcore, syscad, cp1, irs3, n3dmc}!wb6rqn!brian
Share and enjoy!johnl@n3dmc.UUCP (John Limpert) (04/05/88)
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.
hrp@windsor.CRAY.COM (Hal Peterson) (04/06/88)
There was a paper in IEEE Transactions on Communications some time in 1980 (plus or minus a year) about an error detection scheme that was almost as easy to calculate as a checksum, but at the same time was almost as effective as CRC-16 at detecting link errors. Sorry about the vague citation, but the Cray library wasn't subscribing to ToC back then, so I can't look it up. -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.CRAY.COM@umn-rei-uc.ARPA ihnp4!cray!hrp (612) 681-3145