Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!pasteur!ucbvax!TRANTOR.UMD.EDU!petry
From: petry@TRANTOR.UMD.EDU ("Michael G. Petry")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: link level crap protection
Message-ID: <8803311345.AA16247@trantor.UMD.EDU>
Date: 31 Mar 88 13:45:21 GMT
References: <8803310739.AA29768@uunet.UU.NET>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 15

Let me second Mike's statement.  I believe the link level check was only
to give a good/bad indication.  There was no desire to do any kind of
link level correction or retransmission.  The idea was that the limited
line bandwith was "THE" critical resource.  If a system consist of multiple
low speed SLIP hops, you want the toss bad packets ASAP that might clog an
under-bandwidth pipe. If the model is stub only SLIP lines, it may not be
as critical. In a low speed SLIP model CPU should be relatively cheap and
thus the cost for doing the link level check considered tolerable.

I thought the idea was features such as checksum, CRC, compression, etc. were
negotiated on a link by link basis. If you have a link level that delivers an
error rate that is acceptable (ex. trailblazers), don't negotiate for a check.
If you have low tech noisy 2400 (like me) then I'll pay the extra cost.

Mike