RE: [RPRWG] Why Data CRC Stomping is a BAD Idea?
Nirmal,
I don't know if it is still true or not. At one time CHECK_STOMP
was proposed to be the inverse of the checksum. If that is the
case, then there is probability of 1/(2^^32) that an errored packet
looks stomped, and another 1/(2^^32) that an errored packet looks
good. If CHECK_STOMP is inverse of checksum it should be an easy
calculation.
thanks,
robert
> -----Original Message-----
> From: Nirmal Saxena [mailto:nirmal@xxxxxxxxxxxxxxx]
> Sent: Tuesday, July 30, 2002 1:00 PM
> To: stds-802-17
> Subject: [RPRWG] Why Data CRC Stomping is a BAD Idea?
>
>
>
> Why Data CRC Stomping is a BAD Idea?
> (Section G.3.1 in Annex G, IEEE Draft P802.17/D0.3)
>
> Abstract
>
> Data CRC stomping has been proposed in IEEE Draft P802.17/D0.3
> as a method to create invalid CRC values for transmission
> errors in data frames so that error logging is enabled only
> during the creation of "stomped" value and further logging
> of errors is inhibited as the packet with errored data
> frame passes through subsequent RPR nodes.
>
> While there is some perceived value (in my view very questionable)
> in inhibiting multiple logs of the data frame errors with this
> "stomping" scheme; such a scheme, actually lowers the probability
> of successfully logging errors (explained in the background section)
> and causes unmitigated pain in attaining cycle speeds (necessary to
> attain wire-rate packet processing) for parallel CRC computation.
>
> In summary, Data CRC stomping must be taken out of the 802.17
> Standard.
>
> Background
>
> The data CRC stomping method is explained very clearly in section
> G.3.1 (and the included Figure G.3). I will follow the notation
> in section G.3.1 to back the claims in the Abstract.
>
> One of the scenario that is not considered in the "stomping" scheme
> is the probability that the first error in the data frame (i.e.,
> the first incidence of data frame error in RPR packet) produces
> a CRC value that equals checkStomp. In this situation, with
> "stomping" scheme ON, no error will be logged.
>
> One might argue that such a scenario is very unlikely (we
> will show in
> the Notes section why this argument is not very strong, let
> us for now
> assume that it is true)
>
> The problem really is that we are trying to create a scheme
> ("stomping") with questionably small probability of not
> causing any error logs for detectable data frame errors and
> replacing the time-honored CRC checking scheme that has
> unquestionable
> certainty of logging all detectable data frame errors.
>
>
> Notes:
>
> By definition, STOMP value is limited to 32-bits (follows from
> CRC-32). Anyone familiar with coding theory can always find a
> burst error up to 32-bits that produces a CRC check that
> equals checkStomp for any chosen STOMP value. If you need
> references for "burst errors" and coding theory texts please
> send me a direct mail. I will respond promptly.
>
> The moral of the story is that we are creating an "error logging"
> scheme (for the sake of some one-time elegance of logging errors)
> that is actually less reliable than traditional CRC checking
> and in addition causes severe implementation headaches.
>
> Please do not allow this "stomping" to creep into the Standard.
>
> Regards,
> Nirmal
>
>