Subject: RE: [Tsvwg] SCTP Checksum Change to the IESG

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 2 May 2002 12:26:17 -0600

Scott,

The existing text does not reflect the way most hardware performs CRC
checks. The normal approach does not modify the packet passing through the
CRC checker at all. It does not zero out the CRC field. The most commonly
implemented hardware CRC generator/checker uses the simultaneous multiply
and divide (SMD) method which does an operation which is equivalent to
multiplying by x^32 (for a 32 bit CRC polynomial) and dividing by the CRC.
When this done in the checker by running the covered data and the received
CRC through the checker, the final value in the CRC checker will be a
constant.

This method is normally used because it uses the same circuit for the
checker as for the generator, it doesn't require handling any part of the
received message specially. You just run the checker until the data runs out
and look at the result.

(Because this method multiplies the checked packet by x^32, a polynomial
with a correct CRC produces a result equal to the remainder of x^32 divided
by the CRC polynomial.)

The common hardware implementation would be:
Compute the CRC with SMD over the covered data including the received CRC.
Compare the result to the magic number.

This type of implementation can either strip the original CRC or leave it on
when passing the data to memory. It normally does not retain the CRC it
computed.

It makes reasonable sense to pass up the received CRC, but recommending
passing up a computed new CRC would be an unreasonable constraint on CRC
implementations. Because following the recommendation would require a
different checker than the kind that is normally implemented, it could
increase the likelyhood of bad implementations.

Regards,
Pat Thaler

-----Original Message-----
From: Scott Bradner [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 4:23 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Tsvwg] SCTP Checksum Change to the IESG

I disagree

if others think that Doug has a point that is important enough to
delay this document even longer please speak up - if there is not
support it is time to move on - if there is support (and more than 
one or two people) then we will delay yet again

Scott

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Scott Bradner <[email-masked]>
Date: Thu, 2 May 2002 14:29:23 -0400 (EDT)

> implementations. 

I don't quite get this objection

the text in question makes a recommendation it does not mandate
and it does not claim that its the only way

Scott

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 2 May 2002 19:47:09 +0100 (BST)

> and it does not claim that its the only way

Anything the draft mentions in a non-negative sense is implicitly
recommended. Why would the draft mention a way that isn't the way to
do it? The word 'recommended' is redundant.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>