Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[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