Subject: RE: [Tsvwg] SCTP and checksums

From: "WENDT,JIM (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 8 May 2001 12:40:59 -0700

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

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 08 May 2001 14:49:34 -0500

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

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 8 May 2001 15:48:35 -0700 (PDT)

> doing this in SCTP (I'll try to find it).

As a protocol implementor, I strongly oppose this kind of negotiation.
Adding a checksum is not just doing another negotiation, it involves a
lot of other things.  For example, it means that the stack has to have
a policy of what and how to negotiate.  This also means that hardware
assisted checksum will become extremely complicated.  How can the hardware
know which checksum to apply to a particular packet?  There are a lot
of other issues involved...

I urge people thinking of adding yet aother feature to SCTP to think
thrice!  SCTP is already "too complicated!"  And it has a number of things
designed to be used for some particular usage.  If SCTP is going to be
a general transport protocol, it'd better be simple and robust.  Adding
yet another feature to SCTP at this stage of the protocol life just means
that it may never "grow up."  And the last kind of feature to add is 
mechanism used by some foo app protocol which wants to avoid having their
own code so it'd better be in the transport!

							K. Poon.
							[email-masked]