Subject: RE: [Tsvwg] sctp error check

From: Tuexen Michael <[email-masked]>
Date: Wed, 29 Aug 2001 11:13:24 +0200

Dear all,
how many bits does the UMAC have. Currently we use 32 bits
in the SCTP common header for the checksum. As far as I
understood the discussion, this format MUST not change.
Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Julian Satran [SMTP:[email-masked]]
> Sent:	Wednesday, August 29, 2001 10:51 AM
> To:	[email-masked]
> Subject:	RE: [Tsvwg] sctp error check
> 
> Doug is doing an excellent job of "information transfer" from IPS to tsvwg.
> For iSCSI as a potential (future) user of SCTP a good CRC would be of real
> benefit.
> For modest software implementations all CRCs are equal.
> 
> For more sophisticated implementations (those are relatively new) and for
> hardware parallel implementation
> (not sure that you need one for SCTP) the number of nonzero coefficients in
> the polynomial is important (the lesser the better).
> 
> You may want also to consider UMAC - a new cryptographic digest - that is a
> easy on computing as a CRC(!) but has the added benefit of authenticating
> the source (has a key).
> 
> Julo
> 
> Julian Satran - IBM Research Laboratory in Haifa
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 29 Aug 2001 06:48:37 -0500

Michael/Julian:

Even more so, Scott called a "rough consensus" for CRC-32 in London. I
don't
think we should open a can of worms up and start examining various
other options... otherwise will spin around in circles for months more.
We need to make one decision:

We, as of now, only need to pick the poly.... for the
most part I think the only issue is

CRC-32/ITU or CRC-32c

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Andreas Jungmaier <[email-masked]>
Date: Wed, 29 Aug 2001 15:26:04 +0200

Dear all, hi Randy,

> most part I think the only issue is

Randy, would you take on another straw poll, in order to
get this (overlong) thread finally settled now ?!

For the reasons given in the draft 
http://www.ietf.org/internet-drafts/draft-sheinwald-iscsi-crc-00.txt
please count me in favor of *CRC-32-C*

Best regards,
Andreas
- -- 

- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |                         _
Computer Networking Technology Group      | ASCII ribbon campaign  ( )
University of Essen                       |  - against HTML email   X
http://www.exp-math.uni-essen.de/~ajung   |              & vcards  / \

---

From: Lyndon Ong <[email-masked]>
Date: Wed, 29 Aug 2001 21:30:42 -0700

I have no preference on the particular CRC, but I agree with
Andreas that we should try to settle this issue.

Cheers,

Lyndon

At 03:26 PM 8/29/2001 +0200, Andreas Jungmaier wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Dear all, hi Randy,
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.5 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQE7jO1sd2Uw+xBvGUIRApuAAJ4hD9iEO2nhwl4y0NCfj1au9CjWPACfYYon
>WB8bac/8d9mhUYzY2PlL/y0=
>=bgbH
>-----END PGP SIGNATURE-----
>

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 30 Aug 2001 15:47:38 -0700

Lyndon,

We can do this one issue at a time or attempt to do a few things in
parallel.

I would prefer the (1) CRC-32c, (2) all one's initialization of the CRC, and
(3) non-inverted store.

The other issue that remains open would be the (4) byte order the reflected
CRC value is stored.  To put this information into the normal order, a
routine such as flip_ntohl() would need to be added to the library and would
benefit little endian processors.

Doug

---

From: Randall Stewart <[email-masked]>
Date: Fri, 31 Aug 2001 08:00:43 -0500

Doug/All:

I will start a straw poll on the poly after the labor
day holiday.. I think to many people are away this week
to get any meaningful indication...

Other comments below..

> I would prefer the (1) CRC-32c, (2) all one's initialization of the CRC, and

Doug, I don't mind 1 or 2... thats fine... As far as 3 goes, all
things on the wire must be in Network byte order...

R

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 31 Aug 2001 09:54:45 -0700

Randall,

I do not think I was clear about the inverted store and the reflected
results.  The CRC algorithm for Ethernet does a unitary inversion of the CRC
results before storing.  With the CRC being placed in the header, it is my
understanding reasons for doing such an inversion is removed by this header
position.  That was item (3) and has nothing to do with byte order.

For item (4) the reflected table (Meaning that bit 31 is at bit 0, etc.)
used to generate the CRC creates a reversed byte order.  (The reversed bit
order is to be retained.)  This becomes difficult in that there is no
standard routine for placing this reversed byte order into network order.
If we wish to store this result in the correct order, then a new library
routine for doing so becomes required.  If we define the results stored as
"reflected" then the standard htonl() routine can be used otherwise a new
routine such as flip_htonl() needs to be created.  It would look something
like:

#ifdef (LITTLE_ENDIAN)
#define htonl(x) swab32(x)
#define ntohl(x) swab32(x)
#define flip_htonl(x) _u32(x)
#define flip_ntohl(x) _u32(x)
#else
#define htonl(x) _32(x)
#define ntohl(x) _32(x)
#define flip_htonl(x) swab(x)
#define flip_ntohl(x) swab(x)
#endif

Doug