mo@maximo.UUCP (Mike O'Dell) (03/31/88)
For my two cents... If the purpose of a SLIP checksum is ONLY to allow SLIP to know a packet is bad and to discard it, then it is tolerable. If it does ANYTHING beyond inspect it for damage, trash the broken packet, and increment a counter, it is wrong. I understand Rick's experience, but I have also felt that the protocols really expected to get a Good packet or No packet. The checksumming is there for the occassion when the No packet case screws up and the wire delivers junk. This may not have been spelled-out anywhere, but has been a religious believe of mine. -Mike O'Dell
petry@TRANTOR.UMD.EDU ("Michael G. Petry") (03/31/88)
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
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (04/05/88)
> *Excerpts from: 30-Mar-88 link level crap protection Mike* > *O'Dell@uunet.UU.NET (587)* > For my two cents... > If the purpose of a SLIP checksum is ONLY to allow SLIP to know > a packet is bad and to discard it, then it is tolerable. > If it does ANYTHING beyond inspect it for damage, trash > the broken packet, and increment a counter, it is wrong. This is exactly what it will do, no more, no less. Drew