Subject: Re: Re the link draft...

From: Joe Touch <[email-masked]>
Date: Wed, 3 Nov 1999 17:10:56 -0800 (PST)

> From [email-masked]  Wed Nov  3 16:12:43 1999
> Delivery-Date: Wed, 03 Nov 1999 16:12:43 -0800
> Return-Path: [email-masked]
> From: "John Border" <[email-masked]>
> Date: Wed, 3 Nov 1999 18:15:02 -0500
> To: "'Phil Karn'" <[email-masked]>,
>         Marie-Jose Montpetit <[email-masked]>
> Subject: Re: Re the link draft...
> Cc: [email-masked]
> 
> 
> Marie-Jose,
> 
>     I think this is an issue of detection as opposed to correction (which is
> why I say it is related to the FEC issue but not quite the same as the FEC
> issue).  With some methods of FEC, I know that the FEC can detect errors beyond
> what it can correct and, thus, the FEC mechanism can provide a CRC function.
>  But, I don't know enough about FEC to know if all FEC mechanisms have this
> property.  And, even if they do, there is always the question of how much
> detection is provided beyond the correction.
> 
>     Your point is a good one, though.  There is some bandwidth cost associated
> with providing error detection and it might be an addition to whatever is
> provided for error correction.  This definately has to be taken into account...
> 
> 
> 								John

I would add:

	- fast, capable of being implemented in hardware

	- trailer-based if possible (to avoid an additional
		packet's worth of delay on send; the delay
		on receive is inevitible)

Joe