Subject: RE: [Tsvwg] Re:SCTP Error Checking Algorithm

From: [email-masked]
Date: Fri, 18 May 2001 14:26:20 +0300

Hi all,

	I'm not at all a checksum guru, and maybe this is not the way
protocols use to do it, but, if the main problem is the behavior of the
checksum pattern with short and long messages, why don't we use one or other
checksum on an IP datagram length basis?

	Normally, the code necessary to calculate the checksum is really
small. So you could have two of them (or more) implemented, being one of
them better for small messages, about 100-200 bytes, and the other one with
better performance for larger datagrams... The cut length could be even
negotiated at the beginning, as the streams are... One simple parameter
including the length limit and an identifier of the checksum algorithm to
use would be enough... For example:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type = Checksum Information  |      Length = 4 * (N + 1)     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Length Limit #1        |     Checksum #1 Identifier    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    \                              ...                              \
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Length Limit #N        |     Checksum #N Identifier    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	So from 0 to Length Limit #1, Checksum #1 would be used, from Length
Limit #1 + 1 to Length Limit #2, Checksum #2 would be used and so on. Maybe
this could be in an extension draft... Another idea that comes to my mind is
a special type of DATA chunk that includes itself a stronger checksum
algorithm that covers the data carried in that specific chunk...

	In any case, we could have an extension so the use of a stronger
checksum could be negotiated and used at the establishment (and use Adler-32
or Fletcher, or any other "cheap" algorithm as the default for the INIT
chunk and in general for implementation without such extension). I know this
leads to the problem "if we specify something that is not compulsory, nobody
will even include it", but IMHO if the main problems of having a "weak"
checksum occur in situations such as using SCTP for bank transactions,
billing, DoD and so on, I guess that this kind of users will push the
protocol implementers to include that extension if they really need it and
thus that problem will disappear. We can wait to make such a "trivial"
extension until we really notice that it is needed or when we feel that we
are ready to do it...

	Also, for example in the IP specifications it is said that the
checksum may be changed in the future (I don't remember what TCP says about
this), and as far as I know, it wasn't ever changed (maybe mostly because of
the cost of doing so against not such an important improvement). IPv6
doesn't include any checksum (excluding the use of AH and so on), and SCTP
is hopefully going to be used for some years, so I think it is likely that
in the future some other kind of checksum will be studied and used, and so,
that extension about the use of different checksum types will be maybe done
sooner or later...

	Just my 2 cents.

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Jacob Heitz [mailto:[email-masked]]
> Sent: 18. May 2001 7:45
> To: [email-masked]
> Subject: Re: [Tsvwg] Re:SCTP Error Checking Algorithm
> 
> 
> We have competing requirements:
> Strong error checking vs. fast computation.
> 
> Is it possible to get a crc/checksum that is computationally
> efficient, yet strong for small frames, but weaker for
> larger frames ?
> 
> Then those that need strong error checking can set themselves
> a small maximum MTU. SCTP will segment and reassemble, so it
> should not be a problem. Small MTU gets better throughput in
> high error environments anyway.
> 
> Those without the strong error checking requirement can then
> choose a high maximum MTU and still have a computationally
> efficient checksum.
> 
> -- 
> // Jacob Heitz Tel:510-747-2917
> 
> _______________________________________________
> 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 R. Stewart" <[email-masked]>
Date: Fri, 18 May 2001 07:38:22 -0500

Ivan:

This is one time when I must strongly disagree with you.
Multiple checksums causes all sorts of problems
with hardware designers that want to add hardware
assist to SCTP's checksum. Kacheong, Chip and I
explored this type of "multiple" checksums before
we decided to do a BIS. After much debate and a
draft that was never submitted... we all were in
100% agreement that the right way to go is to
pick a better algorithm and do a flash-cut.

Now, I did do some performance studies with
my small network here in the office... and I
am still not fully sure what my results mean :0

It looks to me that in most cases the checksum/addition
algoritms are faster by just a small bit.. But this
"small bit" is not that much overall. I re-ran some
thing recently with out the -O3 in the compile and
got more sane results but I did have a interesting
out-lier.. On my Pentium I/100Mghz for a CRC32 that had
a 1K table, I got faster performance than any other. 
All of the smaller tables of course were much slower..

Now on my PII-333Mghz I did not see the above... it showed
the checksum always better than the CRC32... but the difference
between CRC32 with a 1k table and the checksum algorithms
were not that much different.

I am almost inclined to think we SHOULD go with a CRC32 algorithm
(I don't know if we should use E-net's variant or CRC32C or what
though :=0).

Now I think one of the things that Jonathan and Craig's studies show
is the MOST important thing to do is to move the checksum to the end.
La Monte has suggested this as well.. and maybe we should do this
too? I don't think it will make the code to complex it should
be an easy change.. and for hardware people, they would love it :0

Craig/Jonathan any comments??? If we did this would it still be
worth switching to CRC32 or ??

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 18 May 2001 14:08:05 -0700

Ivan,

A default of Adler-32 could be modified into CRC-32C using this technique.
The problem with this however, the transport would be required to maintain
state of each connection to know which check to apply.  Stealing a bit from
the validation code to indicate CRC in use would be another technique.  Yet
another would be to put a packet check chunk at the beginning of the packet.
Just placing the check bytes at the end of the packet is also attractive.
Unless this check is CRC, many applications will be forced to add yet
another layer of error checking if this check is not selectable.  Moore is
on the side of CRC I would suspect.  I will relent on getting any serious
consideration of a digest chunk.  I have no sage wisdom as to how this issue
will be resolved.    In the meantime, I will rewrite my proposal to
implement IPSEC.  It does seem to be challenge to get this to work over a
traditional NAT whereas the digest chuck would allow a simple translation.
I fail to see the problem with this technique as SCTP offers significant
protection at the IP level that could be taken advantage of here in this
case.

Doug