Subject: Re: [Tsvwg] SCTP and checksums

From: "Lyndon Ong" <[email-masked]>
Date: Tue, 08 May 2001 13:41:58 -0700

There has been some offline discussion about adding a second error check via an optional chunk, which is distinct from a negotiation from multiple options of error check type.  This might still be worth pursuing assuming that we go with a checksum rather than CRC for the main error check.

Lyndon 
--

On Tue, 08 May 2001 14:49:34   Randall Stewart wrote:
>Jim:
>
>It was Chip Sharp and I who talked about this.. we even have a
>draft buried somewhere that we put together... However after
>writting it we realized that it was the wrong thing to do... 
>
>You get the situation where you MUST have a hardware implementation
>that does both checksums... el.yucko... thus we agreed the
>right way to go is a flash cut to a better check-sum...
>
>Now I also believe that Douglas Otis was talking about writting
>a CRC-negotiation draft for SCTP. Maybe you and He could get
>together and come up with something if you wish to propose this.
>I would be happy to look over whatever you came up with and
>mull on it... 
>
>R
>
>"WENDT,JIM (HP-Roseville,ex1)" wrote:
>> 
>> It's not so much that IPS will do its own CRC, but that IPS also has to do
>> retransmissions, acknowledgements, timeouts, and, in general, recreate a lot
>> of transport-like functionality that wouldn't be required if the underlying
>> transport protocol provided the required level of data integrity.
>> Understandably, crc-32 in software is too expensive for many small systems.
>> 
>> Perhaps the best solution would be to put checksum algorithm negotiation
>> into SCTP, with a reasonable checksum as default and optional checksum or
>> CRC algorithms for hardware-accelerated (or bigger) systems. I think there
>> was an email about a month ago that described a couple of mechanisms for
>> doing this in SCTP (I'll try to find it).
>> 
>> Jim
>> 
>> Jim Wendt
>> Networked Storage Architecture / NSSO
>> Hewlett-Packard Company
>> [email-masked] 916-785-5198
>> 
>> -----Original Message-----
>> From: Randall Stewart [mailto:[email-masked]]
>> Sent: Saturday, May 05, 2001 6:16 AM
>> To: Michael Krause
>> Cc: [email-masked]; Lyndon Ong
>> Subject: Re: [Tsvwg] SCTP and checksums
>> 
>> Michael:
>> 
>> just a couple of comments...
>> 
>> 1) I will be glad to forward you more details on the test environment.
>> 2) The widest differences appear to be in the crc32 measurements..
>> believe
>>    it or not. It is well known that caching of tables (or not) will
>> cause
>>    such wide discrepancies.
>> 3) I think it is clear from my study that:
>>    a) crc-32 is more expensive if you do it in software, but can be
>>       not much more overhead than the others IF (and thats a big
>>       if) you have a hardware environment that is more friendly to
>>       it (i.e. big cpu cache and enough memory to keep a fairly
>>       large CRC table... aka 1k 32 bit words or so).
>>     b) Since we want SCTP to run in all types of devices crc-32
>>        will be more expensive for small devices and may make it
>>        harder to put SCTP in those devices.
>> 
>> I don't see the value in moving to crc-32 due to its increased overhead
>> in small devices... I think it is quite clear that IPS will do there
>> own CRC no matter what SCTP does and besides... SCTP is a general
>> purpose protocol and thus needs to fit in the "all device catagory" even
>> though IPS would most likely run on more CRC-32 friendly environments...
>> 
>> I will send you a seperate email with more details on my results... I
>> did
>> not want to plague the list with excess information.. anyone else that
>> would
>> like more details please send me an email and I would be glad to share
>> the
>> info with you..
>> 
>> R
>> 
>> Michael Krause wrote:
>> >
>> > At 09:10 AM 5/4/2001 -0500, Randall Stewart wrote:
>> > >Dear All:
>> > >
>> > >I have just completed my study of the performance of various
>> > >sums and such. I had some interesting results, to say the least :)
>> > >
>> > >Here is a summary of my findings, I can provide details for any
>> > >who would like (in the form of a starOffice spreadsheet or a
>> > >email with the results a bit less raw).
>> >
>> > Without a description of the tests, the execution environment, etc. it is
>> > unclear how to evaluate these results.  Clearly the wide variance of the
>> > results needs to be explained before any conclusions can be drawn.
>> >
>> > Mike
>> >
>> > >Summary:
>> > >-----------------------------------------------------------------
>> > >CRC-32 - Varies widly based on caching and type of algorithm and
>> > >          size of arrays. Generaly I saw anywhere from 3us - 128us
>> > >          per call on a PI running the receive side of my tests.
>> > >
>> > >Adler-32 - Tended to take between 2-91 us on my PI. Not sure why the
>> > >            wide variance. Most of the results were around 60-70us
>> > >            per call.
>> > >
>> > >ModAdler - Tended to be slightly faster than Adler-32 (as expected)
>> > >            ranging in the 40-60us per call range.
>> > >
>> > >Fletcher - Was faster than either adler32 variant (using only 16 bit
>> > >            fletcher) ranged anywhere from 15us - 50us per call during
>> > >            my various test runs... but for the most part consistently
>> > >            lower time frames than either adler.
>> > >
>> > >TCP32 - This was put forward in some early discussion by Craig Partridge
>> > >so
>> > >         I whipped up something along the lines of the IP sum only adding
>> > >         32 bits at a time. 1's compliment at the end and of course all
>> > >         of the wraps carried back in. I did this assuming a 32 bit
>> > >         adder so that each addition needed to check for wrap and
>> > >maintain
>> > >         a wrap counter which was folded in at the end. This tended to
>> > >         always be slightly fast than Fletcher somewhere between 3-15us
>> > >         in all cases with no inconsistent results.
>> > >
>> > >Now after looking at these results I have reached the following
>> > >conclusion:
>> > >
>> > >A) CRC-32 is to variable and will I think result in to much work for
>> > >    small devices. If one assumes a device with a small cache you are
>> > >looking
>> > >    most likely in the higher end of my results and in the worse case it
>> > >can
>> > >    get pretty bad.
>> > >
>> > >B) Fletcher seems to do much better than Modifed adler in terms of
>> > >performance
>> > >    due to the smaller number of instructions needed to execute it.
>> > >
>> > >C) TCP32 did best of all but is completely new. I am hesitant to go down
>> > >    a path of a unknown-unexplored checksum that has not been studied
>> > >very
>> > >    well. Been there, done that, did not like the results :)
>> > >
>> > >So I think the bottom line is we should shift SCTP into a 16 bit
>> > >Fletcher algorithm
>> > >which will:
>> > >
>> > >1) Improve performance
>> > >2) Provide better checksum protection
>> > >3) Has been studied enough and is actually an alternative that
>> > >    TCP can use (but it seems does not).
>> > >
>> > >
>> > >I will begin working on the RFC2960Bis document today. I will try to
>> > >have it
>> > >out next week... I am thinking on  (urged by Lyndon) incorperating all
>> > >of the findings of the
>> > >bakeoff draft in this (except the last bakeoff... I need to write a
>> > >seperate
>> > >ID on this one so that I can get some help from the IPv6 community on
>> > >the
>> > >only issue found... address scoping in V6 :>)
>> > >
>> > >Anyway please comment to me ... throw things etc... it is helpful if you
>> > >make
>> > >sure I am copied .. since I still have the northpoint flu and my normal
>> > >IETF email is delayed quite a bit being batched once or so every day...
>> > >
>> > >Comments and opinions would be most helpful...
>> > >
>> > >PS: Lyndon can you please forward this to the sigtran wg since it won't
>> > >take
>> > >     my posts from my non-subscribed cisco account... thanks
>> > >
>> > >Thanks
>> > >
>> > >R
>> > >--
>> > >Randall R. Stewart
>> > >Systems & Solutions Engineering
>> > >Cisco Systems Inc.
>> > >[email-masked] 815-342-5222 or 815-477-2127
>> > >
>> > >_______________________________________________
>> > >tsvwg mailing list
>> > >[email-masked]
>> > >http://www1.ietf.org/mailman/listinfo/tsvwg
>> 
>> --
>> Randall R. Stewart
>> Systems & Solutions Engineering
>> Cisco Systems Inc.
>> [email-masked] 815-342-5222 or 815-477-2127
>> 
>> _______________________________________________
>> tsvwg mailing list
>> [email-masked]
>> http://www1.ietf.org/mailman/listinfo/tsvwg
>
>-- 
>Randall R. Stewart
>Systems & Solutions Engineering
>Cisco Systems Inc.
>[email-masked] 815-342-5222 or 815-477-2127
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/tsvwg
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

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

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 9 May 2001 12:03:35 -0700

Lyndon,

To be compatible with iSCSI while using SCTP, there is a need to include an
Integrity Check Chunk.  The concept that I had was a simple IA-Digest Chunk
for Integrity-Authentication.  It would be placed at the beginning of the
SCTP frame where the content would be the raw digest as defined per the
negotiations.  There would need to be an assignment for this chunk type.  It
could be possible to include CRC within this chunk rather than SHA-1 digest
if that was negotiated.

If you are interested, this is second cut at this proposal for a compatible
transport that can support iSCSI.
ftp://ftp.sanlight.net/pub/draft-otis-record-delivery-01.txt

This was an attempt to track the iSCSI effort.  If you think there is a
cleaner way to go about this level of negotiation, I am interested.

With respect to Fletcher, I suspect most hardware failure related errors
will have the same modulo as this algorithm making it less robust in these
failures.  I will attempt to do some error simulations to provide some
figures relating these to Adler, Modified Alder, Fletcher, CRC-C, etc.  The
types of errors that I think these should be subjected to are missing 48
byte sections,  stuck bits every 4 bytes offset by powers of 2, truncations,
and the like.  Burst errors do not seem to be the predominate source of
errors at this level.

Doug

> There has been some offline discussion about adding a second
> error check via an optional chunk, which is distinct from a
> negotiation from multiple options of error check type.  This
> might still be worth pursuing assuming that we go with a checksum
> rather than CRC for the main error check.
>
> Lyndon
> --
>
> Join 18 million Eudora users by signing up for a free Eudora
> Web-Mail account at http://www.eudoramail.com
>