Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt

From: [email-masked]
Date: Tue, 26 Mar 2002 07:22:40 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title		: SCTP Checksum Change
	Author(s)	: R. Stewart, J. Stone, D. Otis
	Filename	: draft-ietf-tsvwg-sctpcsum-04.txt
	Pages		: 14
	Date		: 25-Mar-02
	
SCTP [RFC2960] currently uses an Adler-32 checksum.  For small packets 
Adler-32 provides weak detection of errors.  This document changes that 
checksum and updates SCTP to use a 32 bit CRC checksum.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpcsum-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tsvwg-sctpcsum-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tsvwg-sctpcsum-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 27 Mar 2002 17:35:17 -0600

The corrections and comments presented at WG Last Call for -03
of this draft have not been addressed in version -04.  The
issues and errors identified for -03, therefore, also apply
to version -04.  Please make the following corrections, duly
identified at WG Last Call, for version -05:

> Date: Fri, 8 Mar 2002 10:47:27 -0600
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: [email-masked]
> Subject: Re: [Tsvwg] WG last call on draft-ietf-tsvwg-sctpcsum-03.txt
> 
> Scott,
> 
> On Page 4, this draft says:
> 
> 	   - The CRC polynomial is mapped back into SCTP transport-level
> 	     bytes.   Coefficient of x^31 gives the value of bit 0 of
> 	     SCTP byte 0, the coefficient of x^24 gives the value of 
> 	     bit 7 of byte 0.  the coefficient of x^7 gives bit 0 of 
> 	     bit 0 and the coefficient of x^0 0 gives bit 7 of byte 3. 
> 	     The resulting four-byte transport-level sequence is the 
> 	     32-bit SCTP checksum value.
> 
> There is an error in here:  "bit 0 of bit 0", however, the entire
> paragraph is pointless and should be removed.  Please remove or at least
> correct this paragraph.
> 
> 
> Page 4-5.  The same problematic MUST's for calculation of the checksum
> from the beginning of section 2.1 (top of Page 3) is repeated (word for
> word it appears) across the bottom of Page 4 and the top of Page 5.
> Please remove this duplication.
> 
> --brian
> 
> On Fri, 08 Mar 2002, Scott Bradner wrote:
> 
> > 
> > This starts a working group last call on draft-ietf-tsvwg-sctpcsum-03.txt.
> > 
> > The last call will end on March 24th (after the IETF meeting) 
> > 
> > please send any comments to the tsvwg list 
> > 
> > thanks
> > 
> > Scott & Allison
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

> Date: Fri, 8 Mar 2002 10:33:36 -0600
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: Scott Bradner <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> Scott,
> 
> Section 2.1:
> 
> The draft uses the words MUST in telling the implementor where and
> when bits are to be replaced in the message.  It is not appropriate
> for the draft to do this.  CRC-32c can be calcualted without using
> the procedures dictated by section 2.1.  In particular SCTP checksums
> can be calculated without replacing the CRC with zero but can be
> verified with the CRC in place.  The implementatino is clearly
> responsible for calculating the CRC-32c checksum and verifying it
> in whatever fashion it may choose and the "MUST" is inappropriate
> as applied to the procedure in section 2.1.
> 
> --brian
> 
> 
> On Fri, 08 Mar 2002, Scott Bradner wrote:
> 
> > 
> > This starts a working group last call on draft-ietf-tsvwg-sctpcsum-03.txt.
> > 
> > The last call will end on March 24th (after the IETF meeting) 
> > 
> > please send any comments to the tsvwg list 
> > 
> > thanks
> > 
> > Scott & Allison
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

> Date: Fri, 8 Mar 2002 10:24:42 -0600
> From: "Brian F. G. Bidulock" <[email-masked]>
> To: Scott Bradner <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: [Tsvwg] WG last call on draft-ietf-tsvwg-sctpcsum-03.txt
> 
> Scott,
> 
> Please rewrite the Introduction to adopt a professional,
> formal and non-condescending tone.  The informal tone
> used in the introduction may be appropriate in e-mails
> between pen-pals, but sticks out as inappropriate for
> an RFC.
> 
> --brian
> 
> On Fri, 08 Mar 2002, Scott Bradner wrote:
> 
> > 
> > This starts a working group last call on draft-ietf-tsvwg-sctpcsum-03.txt.
> > 
> > The last call will end on March 24th (after the IETF meeting) 
> > 
> > please send any comments to the tsvwg list 
> > 
> > thanks
> > 
> > Scott & Allison
> > 
> > _______________________________________________
> > tsvwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

> Date: Fri, 8 Mar 2002 08:34:15 -0500 (EST)
> From: Scott  Bradner <[email-masked]>
> Message-Id: <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Tsvwg] WG last call on draft-ietf-tsvwg-sctpcsum-03.txt
> 
> 
> This starts a working group last call on draft-ietf-tsvwg-sctpcsum-03.txt.
> 
> The last call will end on March 24th (after the IETF meeting) 
> 
> please send any comments to the tsvwg list 
> 
> thanks
> 
> Scott & Allison
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

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

---

From: David Lehmann <[email-masked]>
Date: Wed, 27 Mar 2002 15:35:42 -0500

Hello,

	Concerning the tweaked checksum introduced in the previous
	draft, what is the purpose of taking the one's complement
	and then reordering of the bytes at the end of the
	generate_crc32c?  I don't see how this adds to the ability
	to detect errors.  Is it a hardware issue?

-- 

David Lehmann
Ulticom, Inc.
AOL IM: davidULCM
856-787-2729

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 28 Mar 2002 13:25:05 -0800

Randall,

I think that Brian is correct in that there is a simple typo in this
paragraph.

It should read:

    - The CRC polynomial is mapped back into SCTP transport-level
      bytes.   Coefficient of x^31 gives the value of bit 0 of
      SCTP byte 0, the coefficient of x^24 gives the value of
      bit 7 of byte 0.  The coefficient of x^7 gives bit 0 of
      byte 3 and the coefficient of x^0 0 gives bit 7 of byte 3.
      The resulting four-byte transport-level sequence is the
      32-bit SCTP checksum value.

Doug

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Mar 2002 15:34:52 -0600

Randall,

What in particular do you disagree with?

--brian

On Thu, 28 Mar 2002, Randall Stewart wrote:

> You of course make the assumption that all of the working group agrees
> with your comments..
> 
> I know I don't.
> 
> R
> 
> "Brian F. G. Bidulock" wrote:
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Mar 2002 17:47:40 -0600

Douglas,

What about this repeated text?  (See below.)  Is there some
point to saying this twice?  The second version is better (the
first says that the VTag MUST be added after the SCTP Common
Header has already been built and DATA chunks attached which
is ridiculous).

Also, it is not necessary to replace the checksum field with
0.  Even in the Adler32 we used algorithms which skipped the
checksum field when calculating.  Not replacing these bits is
particularly important for implementations with shared
received buffers that must be treated as read-only.  This MUST
is inappropriate when applied to "replace".  All that is
necessary is that the calculation be performed correctly, not
what bits are replaced where or when.

For example it is possible to precalculate the intermediate
checksum result over the SCTP common header for a given
association an only start with with result immediately
following the common header (because the intermediate result
to this point is just the port pair and VTag which are fixed
for all packets corresponding to an existing association).  So
why does the draft presume to tell me how to do this?

Also, do you actually agree with the informal tone of the
Introduction?

--brian

> Page [3]:
>    124	    2.1 Checksum Calculation 
>    125	     
>    126	    When sending an SCTP packet, the endpoint MUST include in the checksum 
>    127	    field the CRC-32c value calculated on the packet, as described below. 
>    128	     
>    129	    After the packet is constructed (containing the SCTP common header and 
>    130	    one or more control or DATA chunks), the transmitter MUST do the 
>    131	    following: 
>    132	     
>    133	    1) Fill in the proper Verification Tag in the SCTP common header and 
>    134	       initialize the Checksum field to 0's. 
>    135	     
>    136	    2) Calculate the CRC-32c of the whole packet, including the SCTP common 
>    137	       header and all the chunks. 
>    138	     
>    139	    3) Put the resultant value into the Checksum field in the common header, 
>    140	       and leave the rest of the bits unchanged. 
>    141	     
>    142	    When an SCTP packet is received, the receiver MUST first perform the 
>    143	    following: 
>    144	     
>    145	    1) Store the received CRC-32c value, 
>    146	     
>    147	    2) Replace the 32 bits of the Checksum field in the received SCTP packet 
>    148	       with all '0's and calculate a CRC-32c value of the whole received 
>    149	       packet.  And, 
>    150	     
>    151	    3) Verify that the calculated CRC-32c value is the same as the received 
>    152	       CRC-32c value.  If not, the receiver MUST treat the packet as an 
>    153	       invalid SCTP packet. 
>    154	     
>    155	    The default procedure for handling invalid SCTP packets is to silently 
>    156	    discard them. 
>    157	

> Page [4]:
>    242	    When an SCTP packet is transmitted, the sender MUST perform this
>    243	    checksum procedure, using the preceding CRC computation:
>    244	
>    245	    1) Fill in the proper Verification Tag in the SCTP common header and 
>    246	       initialize the Checksum field to 0's. 
>    247	     
>    248	    2) Calculate the CRC-32c of the whole packet, including the SCTP common 
>    249	       header and all the chunks. 
>    250	     
>    251	    3) Put the resultant 32-bit SCTP checksum value into the Checksum field
>    252	       in the common header, and leave the rest of the bits unchanged. 
>    253	     
>    254	    When an SCTP packet is received, the receiver MUST first perform the 
>    255	    following: 
>    256	     
>    257	    1) Store the received CRC-32c value, 
>    258	     
>    259	    2) Replace the 32 bits of the Checksum field in the received SCTP packet 
>    260	       with all '0's and calculate the SCTP CRC-32c checksum value of
>    261	       the whole received packet.  And, 
>    262	     
>    263	    3) Verify that the calculated CRC-32c value is the same as the received 
>    264	       CRC-32c value.  If not, the receiver MUST treat the packet as an 
>    265	       invalid SCTP packet. 
>    266

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 29 Mar 2002 13:23:11 -0600

Randall,

Please see comments below...

On Fri, 29 Mar 2002, Randall Stewart wrote:

> Comments below
> I agree with this point...
> 
> This point will be corrected by including Doug's proposed fix text for the -05
> version.

Thank you.

> Here I see that on Page 4-5 there is some duplicated text that I think you are
> referring
> to. This is a typo/cut-paste error that caused the same text to be put in twice.. this
> is a
> good point and we can cut out the duplicates for sure :>
> 

Thank you.

> Here is my primary dis-agreement. I think the MUST's here are just fine however
> I do agree that the text need not appear twice in the document. Only once is
> sufficient. But the MUST's need to stay or no one will include a checksum unless
> they feel like it :>

It is not whether the checksum is calculated, nor the mathmatical formula for
calculating the checksum that I disagree with.  What I disagree with is that
a "MUST" has been applied to how the implementation will perform the
calcualtion.  Please see section 6 of RFC 2119: "... they must not be used to
try to impose a particular method on implementors where the method si not
required for interoperability."

Replacing bits is not required for interoperability.  Any method of performing
the calculation which yields the same mathematical result is valid.  This
needs to be clearly identified.  If my algorithm does not physically replace
the checksum bits with zeros but yields the same mathematical result, I must
be permitted to do so.  Also, regardless of the order in which I attach the
ccmmon header, my algorithm can be made to yield the same mathematical result.
The MUST constrains me to one method directly against Sectin 6 of RFC 2119.

> Here again I dis-agree. The IETF is NOT the ITU. The informal tone actually
> is refreshing and warm. Chip Sharp did a good job when he wrote this ...
> (Note to Chip:I still think you should have remained a co-author  :> but I understand
> that you
> did not have time to devote and wanted to be moved to the acknowledgements.)
> It gives a informal tone to a very very dry subject which is later covered in detail
> in
> the description in section 2.1.

Unfortunately the introduction has flawed logic with regards to the Central
Limit Theorem as well, which is not applicable.  I think Lyndon has taken the
time to rewrite the introduction, and I fully support him in doin so.

--brian

---

From: Randall Stewart <[email-masked]>
Date: Fri, 29 Mar 2002 10:23:18 -0600

No problem Jonathan.. when I get back home I will start a new
version with Doug's proposed text.

R

Jonathan Stone wrote:

> Agreed.   Brian, thanks for catching the typo.
>
> [...]

---

From: Jonathan Stone <[email-masked]>
Date: Wed, 27 Mar 2002 15:35:42 -0500

[replying by  cut-and-paste from a Web archive, I hope the refereances
 survived]..

>        to detect errors.  Is it a hardware issue?

It's not a checksum, it's a CRC.  The bit-order `tweaks'' are designed
to preserve (as closely as possible) the properties of divisibility
which are essential to the traditionally-cited strength of CRCs.

If words something like this:

  ``therefore the Vandermode matrix [over the message error/syndrome,
    treated as a system of simultaneous equations] are of full rank''

doesn't make it clear, there's no real remedy other than plowing
through textbooks, by Peterson, or Blahut, or MacWilliams.  (NB: for
the mathematical details, Ross Williams' tutorial is not to be
trusted).  If it helps, the analysis by Castagnoli et aliis
assumes the CRC is computed in this fashion, also.

The reason for complementing the first 32 bits (or complementing the
initial remainder value, with the caveats in the text) comes from
link-level practice. Link-level errors may insert spurious trailing or
leading zeros.  1950s-style CRC computation does not catch those
errors.  Hence the well-known, now-standard trick of complementing the
first and last 32 bits of the message; [McKee75] was the earliest
citation I found for it.  SCTP has explicit length fields, so I
suppose you could argue that the trick is not necessary here.  But
it's an inextricable part of current practice with CRCs in the
coding-theory world, in textbooks, and in other sources; so why add
gratuitous differences?

--Jonathan

---

From: Randall Stewart <[email-masked]>
Date: Thu, 28 Mar 2002 15:11:48 -0600

I know I don't.

R

---

From: Jonathan Stone <[email-masked]>
Date: Thu, 28 Mar 2002 13:26:30 -0800

[...]

---

From: David Lehmann <[email-masked]>
Date: Fri, 29 Mar 2002 08:56:00 -0500

Jonathan Stone wrote

> coding-theory world, in textbooks, and in other sources; so why add

The reason is that it provides unnecessary overhead.  There is going
to be a tremendous amount of packets sent via SCTP, each of which has
to be processed (twice) by this algorithm.  Since "the trick is not
necessary here" (i.e. provides no added value), why place an additional
burden on an already computational heavy algorithm?  IMHO, theoretical
purity is not a compelling reason to add these additional operations.

-David

---

From: Randall Stewart <[email-masked]>
Date: Fri, 29 Mar 2002 11:01:30 -0600

Comments below

R

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 30 Mar 2002 00:38:18 +0000 (GMT)

> between pen-pals, but sticks out as inappropriate for

Oh, indeed; why, it's the weighty formal tone of the Avian Carriers
and other April 1 RFCs that add credence to body of RFCs as a whole.
To recall a previous example, I believe RFC1812 wasn't felt to be
formal or weighty enough, so some old bad (and fortunately
out-of-copyright) poetry got put in at the last minute to redress this
and add necessary length and suitable tone to the text... being
ponderous and having gravitas is important, dammit. (Beards help,
apparently.) The longer and weightier, the better!

On the other, hand, every RFC describing Internet checksums is flawed;
every RFC clarifying previous RFCs describing Internet checksums is
flawed. (In fact, after a reread and staring at some code, I'm amazed
anyone ever achieved interoperable bigendian/littleendian checksum
implementations. As someone famous once said, Math is Hard. I think it
might have been Barbie.) I fail to see why a draft on checksums for an
internet protocol should be anything other than flawed.

You want a better introduction? Provide one.

L.

just being unreasonable doesn't mean you're making progress here.

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

---

From: "Phillip T. Conrad" <[email-masked]>
Date: Fri, 29 Mar 2002 20:15:29 -0500

Gentle folk of the working group:  may I suggest the following simple
change to make this issue go away:

In place of the text:

         When an SCTP packet is received, the receiver MUST first perform 
the following:

We insert the text:

         When an SCTP packet is received, the receiver MUST validate the 
checksum
         field by the following  procedure, or one that is mathematically 
equivalent:

Now, the checksum is clearly REQUIRED, and the implementer is free to 
perform the
calculation by hand on an abacus if he sees fit.

Cheers,
Phill

>The MUST constrains me to one method directly against Sectin 6 of RFC 2119.
...

---

From: Jonathan Stone <[email-masked]>
Date: Fri, 29 Mar 2002 17:42:35 -0800

>calculation by hand on an abacus if he sees fit.

Hi Phill,

There is a subtle issue here: the unstated claim that all
mathematically-equivalent procedures are all just as good
as each other.

That claim no longer holds, once we start considering bugs in an
implementation --- for example, an implementation where responsibility
for checksum computation is split between hardware and software.  One
example is transient errors in a bit in a DMA pointer register,
perhaps due to alpha-particles from nearby solder.  Examination of
real-world network data suggests that errors like this are fairly
common.  A protocol like SCTP, which is expected to scale to very
high-end throughput, should take the likelihood of such
errors into account.

The ordering of operations in the current text had some thought on
this aspect.  Frankly, I think a spec which does NOT allow complete
freedom to the implementor, is a better spec than one which DOES allow
complete freedom.  

So I prefer wording which says the computation MUST be done AS IF
<<current text>>; and moreover, for robustness against transient
errors rrors in either hardware or software, an implementation SHOULD
NOT do it in a different way, unless there is some very good reason.

Can we all live with that?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 29 Mar 2002 21:18:00 -0600

Lloyd,

> You want a better introduction? Provide one.

I believe that Lyndon has undertaken to do so.

(It's not April 1st yet.)

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 29 Mar 2002 21:15:53 -0600

Phillip,

I agree and support your proposal.  The text you propose would
certainly resolve the issues that I have with the section.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 30 Mar 2002 08:19:26 -0600

Jonathan,

What compelling reason is there for the draft to dictate the
software and hardware organization of all implementations?

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 30 Mar 2002 19:31:59 +0100

Dear all,

I like the text suggested by Phil very much. From the -04 ID:

  When an SCTP packet is received, the receiver MUST first perform the
  following:

  1) Store the received CRC-32c value,

  2) Replace the 32 bits of the Checksum field in the received SCTP packet
     with all '0's and calculate the SCTP CRC-32c checksum value of
     the whole received packet.  And,

So the following code (taken from ethereal/packet-sctp.c) is NOT in tune 
with the ID

static unsigned int
sctp_crc32c(const unsigned char* buf, unsigned int len)
{
   unsigned int i;
   unsigned long crc32 = ~0L;
   unsigned long result;
   unsigned char byte0,byte1,byte2,byte3;

   for (i = 0; i < SOURCE_PORT_LENGTH + DESTINATION_PORT_LENGTH + 
VERIFICATION_TAG_LENGTH; i++)
   {
     CRC32C(crc32, buf[i]);
   }
   CRC32C(crc32, 0);
   CRC32C(crc32, 0);
   CRC32C(crc32, 0);
   CRC32C(crc32, 0);
   for (i = COMMON_HEADER_LENGTH; i < len; i++)
   {
     CRC32C(crc32, buf[i]);
   }
   result = ~crc32;

   byte0 = result & 0xff;
   byte1 = (result>>8) & 0xff;
   byte2 = (result>>16) & 0xff;
   byte3 = (result>>24) & 0xff;
   crc32 = ((byte0 << 24) | (byte1 << 16) | (byte2 << 8) | byte3);
   return ( crc32 );
}

because I'm not replacing the the checksum bytes with zero? I can't do 
that
due to data structure limitations. So I could only implement a compliant 
version
by completely copying the packet which does not make sense. Of course, 
only people
looking at the source code can detect that the code is not compliant, 
because
it works.

So i would prefer the text of Phil which would allow the code shown 
above.

Best regards
Michael

> Can we all live with that?
[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 30 Mar 2002 13:51:41 -0600

David,

I agree: the complement is worthless overhead.  As you know, when
the CRC-32 is placed as a trailer, the checksum can be recalculated
over the packet and result in all zeros in the checksum position
as a validation.  SCTP cannot take advantage of this because it is
not using a trailer and the checksum bits at the beginning of the
packet is the wrong place for the residue.  Using one approach you
wind up with an all one's residue to verify a received checksum,
using the other you wind up with an all zero's residue to verify
the checksum.
 
This begs another question, however: normally 32 zero bits are added
to the end of the packet to accept the residue so that when the
polynomical is calculated over the entire packet (including the 32
zero bits at the end), the residue winds up in place at the end of
the packet.  In the SCTP draft, it has not been explained that the
polynomial must include 32 bits appended to the packet to provide
adequate coverage (to include in the residue in the same fashion as
the other bytes of the packet) for the last 4 bytes of the packet.

This error in the expaination lies in describing the packet as consisting
of N bytes.  In the draft this is described as a polynomical of order
8N-1, but it is never stated that the division must be perform until
there is a remainder of order -32.  It is better described as a polynomial
of order 8N+3 where the least significant 32 bits are zero and yielding
a remainder of order 0.

As the document stands it is unclear just where the division stops.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 30 Mar 2002 22:52:00 +0100

David, Brian,

see my comments in-line.

Best regards
Michael

> using the other you wind up with an all zero's residue to verify
We are talking about an operation done once for each packet. Since
the algorithm does something per byte the 'overhead' is small between
1% and 0.1% (100 byte packets or 1000 byte packets). So i think it is 
better
to have a well defined mathematical operation than a minor faster one
that almost no one knows.
> the other bytes of the packet) for the last 4 bytes of the packet.
There are not 32 bits appended at the end. They are part of the common
header and are covered in the same way as you want. I think that is why
they are replacing the checksum with all zero bits.

> of order 8N+3 where the least significant 32 bits are zero and yielding

A general remark: The most important part of the document is the C 
example.
I do not think that a SCTP implementor starts thinking about polynomial
remainders and all that stuff. He takes the table, writes a routine doing
the calculation by looking at the C Code and tests. And that description
seems to be OK.

---

From: "Douglas Otis" <[email-masked]>
Date: Sat, 30 Mar 2002 14:05:33 -0800

Brian,

I do not wish to speak for Jonathan, but the description seems correct.

I agree that the complement of the digest is not required except to keep the
algorithm identical to that of the ITU.  A single instruction is negligible
overhead if to avoid concerns about the algorithm being different. : )

With respect to the MUST within the algorithm,

Perhaps this can be added after the procedures as a means to rectify some
implementation conflicts:

  The packet may not be in contagious memory.  Substitution of
  the common header Checksum field with a region set to all '0's
  alleviates storing the Checksum value and the subsequent
  setting, as example.  Remapping packet regions may be
  done, provided the results are equivalent to the methods
  described above.

Doug

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Saturday, March 30, 2002 11:52 AM
To: David Lehmann
Cc: [email-masked]
Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-sctpcsum-04.txt

David,

--brian

---

From: Phillip Conrad <[email-masked]>
Date: Sat, 30 Mar 2002 01:48:34 -0500

...
>Can we all live with that?

Jonathan,
   Your proposed alternate wording is fine with me.    (Brian will have to
speak for himself.)   But for that matter, the original wording was fine
with me also.   I suggested a change only for expediency to get an "issue"
off the table.

You are correct that I was operating under the premise implied by Brian that
all mathematically-equivalent procedures are just as good as any other.

I must confess that I don't entirely follow your reasoning in terms of how
pinning down the order of operations is helpful in preventing errors due to
alpha particles from stray solder.    But I not sure I need to follow that
line of thinking to be comfortable with the current text.   The bottom line
for me is that unlike Brian, I don't see any undue burden on the implementor
imposed by the current text,  and hence no egregious violation of "Section 6
of RFC 2119".

Towards that end:

(1) Am I correct in understanding that the clearing of the bits is necessary
to the correct computation of the checksum according to the algorithm...
that is to say,  if you calculate CRC-32c over the entire packet with the
bits NOT cleared, won't you likely end up with a "bad" checksum value even
on a "good" packet?

(2) Even if someone came up with a "clever algorithm" that made the decision
"pass/fail" without copying the checksum and clearing the bits but "AS IF"
that HAD been done, isn't it true that at most, you might save perhaps two
instructions per packet, versus the recommended implementation?

Maybe I'm mistaken about (1) and (2) above... and if so, I will welcome the
opportunity to learn more about how the CRC-32c works.  But if I'm right in
these two statements, then I see no reason to change the current wording.

Cheers,
Phill

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 30 Mar 2002 20:49:59 -0600

Phillip,

I don't have a problem with replacing "mathematically-equivalent"
with "AS IF".  Actually, I don't see how "AS IF" is tighter than
"mathematically equivalent," but "AS IF" will suit my implementation
and Michael Tuxen's as well, I believe.

Can we agree to change "MUST" to "MUST be done AS IF"?

I believe that will free implementors from constraining their
optimizing compilers from not making the unnecessary replacement,
(unless they feel that their implementation is subjected to a
disproprotionate amount of alpha rays).

--brian

---

From: Jonathan Stone <[email-masked]>
Date: Sat, 30 Mar 2002 19:16:38 -0800

Here's an excerpt, slightly edited from an off-list email.
Apologies to those who (like Brian) have seen it twice.

My concern here is that for high-end SCTP implementations
(gigabit, 10gigabit, and upward), outboard accelerators will be
commonplace. Outboard accelerators make the check less end-to-end.
The available data suggests that errors -- e.g., bits flipped in
address registers in DMA engines, due to transient hardware errors --
is a signficant source of errors.  They really *do* happen in the
field, and at worrisome rates: on the order of 1 in 10,000 overall,
and *much* higher for specific broken hosts.

Specification of the CRC computation should consider the issue of
failure in outboard hardware acceleration of what is supposed to be an
end-to-end error check.[*]  My take is that such consideration falls
squarely under the "potential for causing harm" clause of RFC2119,
section 6, not under the interoperability clause.

I think that explicitly granting complete and utter freedom is a very
poor engineering choice. I much prefer the current wording.  The most
``weaking'' of that tight specification I'd live with is two clauses:

        1. a MUST compute "AS IF" (i.e., must be mathematically
           equivalent to) the current text

        2. a SHOULD NOT compute in some other mathematically-equivalent
           way, since the mathematically-equivalent alternatives raised
           in discussion are weaker when (for example) faced with errors
           in outboard accelerators.

The argument I've seen presented against the MUST in the current
draft, seems implicitly assumes that all computation is being done
inside the end-host -- that is, using the end-host CPU and end-host
buffers. That may be a valid assumption from the perspective of a
pure-software implementation and implementor. But making that
assumption misses the point behind the words, which is aimed at
implementations where the ``end-to-end'' check is being done outboard.
(If you like, consider Michael Tuexen's source code again, with the
assumption that the address-manipulation is being done in outboard
hardware, where the address arithmetic may  occasionally mess up.)

I don't find applications like pretty-printing packet traces a
convincing case. The pretty-printer can easily save the relevant 32
bits before the CRC-check, and then restore them afterward.  It's not
like packet pretty-printing is an actual protocol implementation :).

---

From: Randall Stewart at work <[email-masked]>
Date: Sun, 31 Mar 2002 12:35:41 -0600

Michael:

Having been traveling and seeing a PILE of email to sort through I
picked
yours first to read .. I will go back and re-read the whole chain in a
bit ... but here is my thoughts..

>      the whole received packet.  And,

We DO need to require:

a) That the checksum be run on the whole packet
b) That the place that held the checksum be caculated as 0.

So somehow (without reading other arguments yet... which may
change my mind :>) we need to get 2) in lines that allows your code :>

maybe something like..

2) Calculate the SCTP CRC-32c checksum value of the whole received
   SCTP packet replacing the 32 bit checksum in the SCTP packet with 
   all '0's in the calculation.

This then would NOT require you to replace anything in the packet yet
require that the checksum be done properly....

Don't know.. now after speaking out of turn I will go back and re-read
all this slew of email and think on it :>

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 31 Mar 2002 22:16:59 +0200

Randy,
see my comments in-line.
Best regards
Michael

> change my mind :>) we need to get 2) in lines that allows your code :>
Randy,

it is not important for me that my code is allowed, it is more that my 
understanding
is that 1) and 2) you mentioned above is the only important thing. Then 
my code is
also correct. But Jonathan seems to think that SETTING the 4 bytes to 
zero is important.
This is something I do not understand and i do not want to miss a point 
he thinks is very
important. I posted the code only as an example how one could implement 
the checksum also,
but he disagrees, which I do not understand. So I must be missing an 
important point. When
it is clear we may can include some arguments also in the ID, but that 
is a minor point.
> require that the checksum be done properly....
If this text is OK, I'm happy. But I do think Jonathan is not accepting 
this.
> all this slew of email and think on it :>

OK, I'm hoping to understand Jonathans point...