Subject: RE: iSCSI CRC: A CRC-checking example

From: "Douglas Otis" <[email-masked]>
Date: Thu, 23 Aug 2001 11:06:58 -0700

Vince,

Thanks again as you have made this issue clear.  It would be beneficial to
maintain the "Ethernet" techniques even if only to ensure an accurate length
of packet detection.

Doug

> Doug,
>
> If the transmit side CRC generator used for the frame check sequence the
> remainder of the polynomial division directly (without complementing) the
> receiver-side CRC checker would be expected to end up with zeroes after
> processing an error-free frame. Unfortunately the receiver side
> CRC checker
> would also end up with zeroes after processing a frame whose only "errors"
> are extra trailing zeroes. Thus this type of error would not be
> detected by
> the CRC checker.
>
> Note that the expected final state of the receiver-side CRC checker is
> expected to be zero if hte remainder is not complemented even though both
> transmit and receiver sides initialize their CRC register to 1s. It is the
> operation of complementing the remainder that causes the receiver
> to have a
> non-zero (but constant) ending state after processing an error-free frame.
>
> If I understand you correctly, you have described another type of
> error that
> would be undetected were the remainder not complemented. Whenever the
> receiver CRC register is in its zero state (perhaps partially through a
> packet) the receiver checker would be blind to extra zeroes
> inserted in the
> packet at that point. I agree.
>
> Again, the improved protection resulting from initializing the
> CRC to 1s and
> complementing the remainder is not important for iSCSI because the packet
> length can be checked independently but I suppose it is advantageous to do
> things the ethernet way.
>
>
> Vince

---

From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 23 Aug 2001 13:55:03 -0400

Doug,

If the transmit side CRC generator used for the frame check sequence the
remainder of the polynomial division directly (without complementing) the
receiver-side CRC checker would be expected to end up with zeroes after
processing an error-free frame. Unfortunately the receiver side CRC checker
would also end up with zeroes after processing a frame whose only "errors"
are extra trailing zeroes. Thus this type of error would not be detected by
the CRC checker.

operation of complementing the remainder that causes the receiver to have a

If I understand you correctly, you have described another type of error that
would be undetected were the remainder not complemented. Whenever the
receiver CRC register is in its zero state (perhaps partially through a
packet) the receiver checker would be blind to extra zeroes inserted in the
packet at that point. I agree.

Again, the improved protection resulting from initializing the CRC to 1s and
complementing the remainder is not important for iSCSI because the packet
length can be checked independently but I suppose it is advantageous to do
things the ethernet way.

Vince

|-----Original Message-----
|From: Douglas Otis [mailto:[email-masked]]
|Sent: Wednesday, August 22, 2001 5:48 PM
|To: CAVANNA,VICENTE V (A-Roseville,ex1); 'Julian Satran'
|Cc: 'Mark Bakke'; [email-masked]; 'Steve Blightman'; THALER,PAT
|(A-Roseville,ex1)
|Subject: RE: iSCSI CRC: A CRC-checking example
|
|
|Vince,
|
|Thanks for the explanation and here is how I understand your 
|comments.  Even
|with the CRC unlikely to find zero as a stable state with the all ones
|initialization, in a rare event where a CRC value becomes zero over a
|trailing list of zeros, then an inverted CRC store will create 
|an all ones
|as an ending value.  This is to better ensure detection of the 
|end of the
|block as there are encoding changes that help the underlying decoding
|process.  It would seem that there is still the requirement to 
|know the end
|of the frame regardless of the CRC value but there may be an 
|advantage to
|this encoding change.  Again, thanks.
|
|Doug
|
|
|> In answer to Doug's question about the reason for using the 
|COMPLEMENT of
|> the remainder of the division as the CRC ....
|>
|> One reason I recall, is that this method permits the 
|receiver to detect
|> extra trailing zeroes in the protected packet. If the 
|remainder were sent
|> directly as the CRC, in the absence of errors the remainder 
|of a similar
|> computation at the receiver would be expected to be zero. 
|This means that
|> errors consisting of extra trailing zeroes would not be 
|caught since zero
|> input bits would cause no changes in the CRC circuit once 
|the CRC register
|> is in the so called "inaccessible state" consisting of all zeroes.
|