Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!nike!ucbcad!ucbvax!brahms!desj
From: desj@brahms.BERKELEY.EDU (David desJardins)
Newsgroups: net.sources.d
Subject: Re: \"FAST\" protocol proposal from Hayes
Message-ID: 
Date: Sat, 16-Aug-86 17:47:07 EDT
Article-I.D.: ucbvax.15308
Posted: Sat Aug 16 17:47:07 1986
Date-Received: Sun, 17-Aug-86 09:37:28 EDT
References:    
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: desj@brahms.UUCP (David desJardins)
Organization: University of California, Berkeley
Lines: 27
Keywords: errors reliability end-to-end CRC

In article  campbell@maynard.UUCP (Larry Campbell) writes:
>Note also that FAST just has one CRC for the entire file.  The longer
>the packet, the greater the probability that CRC-16 will fail to
>detect an error.

   True.

>For almost any reasonably large file, CRC-16 is nearly worthless.

   False.  If one or more errors have occurred, a 16-bit CRC will detect
them with probability at least 99.9985%, no matter how large the file.
   If the presumption is that the total error probability is low (as it
certainly should be on an error-free channel) this is more than adequate.

>In any event, why invent yet another protocol?  What's wrong with KERMIT
>with sliding windows?  KERMIT is already implemented everywhere, and the
>sliding windows give reasonable performance.  It just irks me no end to
>see people simultaneously reinventing the wheel and giving up reliability
>for performance.  It doesn't matter how fast you can do it wrong!

   This is just stupid.  If performance means nothing and reliability
everything you should transmit every message 100 times, just to make
sure.  Obviously you have to make some sort of performance-reliability
tradeoff.  Large amounts of redundant error-checking on an error-free
channel are simply wasteful.

   -- David desJardins