Re: [Tsvwg] [SCTP checksum problems]

[Randall Stewart <rrs@cisco.com>]

Q:

Good thoughts except for one minor detail... see below...

Qiaobing Xie wrote:

> Hi, all,
>
> Please correct me if I am under the wrong impression, but what I've been
> hearing so far from the discussion in this thread seems to be:
>
>  1) There is uncertainty on what error model should be used for
>     evaluating transport error check mechanisms;
>
>  2) iSCSI level integrity/authentication seems inevitable not matter how
>     strong the transport error check is;
>
>  3) Some uncertainty about the implementation cost (hw and sw) on some
>     of the proposed CRC-based schemes, but almost certainly any
>     CRC-based scheme will be more expensive than checksum schemes;
>
>  4) Discussion of requirements has been so far very much limited to
>     iSCSI data transport, and it seems that a CRC-based scheme is
>     strongly desirable for iSCSI case _if_ the transport error check
>     alone is all we will get to meet the iSCSi requirements.
>
> Now my question to the group is: if a weaker but much cheaper SCTP error
> checking mechanism can be found to be sufficient to the majority of the
> applications (remember SCTP is a general purpose transport), and the
> ultra-low error rate applications such as iSCSI will eventually rely on
> their own integrity check, should we adopt a selection approach which
> put more emphasis on the ease-of-implementation side?
>
> (Maybe after all the Adler-32 in the current RFC2960 is good enough :-)
> )
>

The major weakness of Adler-32 (if I understand Jonathan and Craig
correctly) is that in
short messages (very common in signalling) the upper two bytes of the
checksum are not
being incremented very often. This is due to the 8bit adds happening at the
input of
data. I am not sure of the strenght of this sum but it is on the order of
weaker than
TCP (if I have heard right). A SIMPLE fix to this is to change the adds to
16 bit
increments.. so input to the c-sum is an array of 16 bit int's instead of 8
bit ints. This
1/2s the work you must do to produce the checksum and causes the upper bits
to
be incremented better... So, I think no matter what we do CRC or checksum a
change is needed. I think to take the minimalist approach changing the
suming to
16 bits is the way to go... Other options such as 32 bit TCP type scares me
a bit
since it will require a few mor operations in any machine that does not have

a 64 bit accumulator... (which is many many many small devices). ...

I see the real issue here is we can either choose a
CRC-32 variant or
one
modified alder..

R




>
> regards,
> -Qiaobing