RE: [RPRWG] Why Data CRC Stomping is a BAD Idea?
Nirmal,
Would be nice to receive feedback on items earlier,
such as the comment phase. From what I understand,
some companies are interested in finishing this
standard(:>), so prompt review would be helpful!
All stations have an inherent delay for pass-through
traffic, as necessary to discard frames with bad
CRCs. Thus, it would seem like there are a few
cycles between sensing a bad CRC and stomping
the CRC. With that time, I don't seen how this
is so hard to do. In fact, it seems quite a bit
simpler than the adjusted CRC that is needed on
the header, after TTL adjustments...
DVJ
P.S. Further comments interleaved...
David V. James, PhD
Chief Architect
Network Processing Solutions
Data Communications Division
Cypress Semiconductor, Bldg #3
3901 North First Street
San Jose, CA 95134-1599
Work: +1.408.545.7560
Cell: +1.650.954.6906
Fax: +1.408.456.1962
Work: djz@xxxxxxxxxxx
Base: dvj@xxxxxxxxxxxx
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Nirmal Saxena
> Sent: Tuesday, July 30, 2002 10:00 AM
> 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.
Correct.
> While there is some perceived value (in my view very questionable)
> in inhibiting multiple logs of the data frame errors with this
> "stomping" scheme;
It sure helps to identify faulty links. Has been supported in
previous standards as a component of RAS (reliability, availability,
and support). I don't see an other easy way of accomplishing the
same thing... do you?
> such a scheme, actually lowers the probability
> 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)
I'm not sure if missing an error log with 1/2**32 is a big deal...
> and causes unmitigated pain in attaining cycle speeds (necessary to
> attain wire-rate packet processing) for parallel CRC computation.
Actually, I think its mitigated pain and quite reasonable.
What would you propose be the alternative, when the CRC is found
to be bad?
> 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.
One can also generate a 32-bit burst that creates a zero-valued
CRC. Thus, the probability of generating the STOMP is about
equal to the probability of missing a CRC error. Both are
insignificant for the payload, although perhaps significant
for the header. However, stomped CRC does not apply to the
header.
> 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.
Error coverage is still maintained, its just that some corrupted
frames are not logged. However, the error log is much more accurate
(off by one part in 2**32) than logging errors on each link.
> Please do not allow this "stomping" to creep into the Standard.
Its already in. Removal arguments should probably be based on
implementation costs, not arguments of error-coverage losses.
> Regards,
> Nirmal
>
>
>