

(EDT)
id QAA28343;
	Mon, 16 Apr 2001 16:10:55 -0700 (PDT)
Message-Id: <[email-masked]>
Date: Mon, 16 Apr 2001 16:10:55 -0700 (PDT)
From: Jonathan Wood <[email-masked]>
Reply-To: Jonathan Wood <[email-masked]>
Subject: Re: [Tsvwg] [SCTP checksum problems]
To: [email-masked], [email-masked]
Cc: [email-masked]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: bW9Ff6kcpBD+KJIWRlIbNw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: [email-masked]
Errors-To: [email-masked]
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Transport Area Working Group <tsvwg.ietf.org>
X-BeenThere: [email-masked]

As an SCTP implementor and someone who will want to get the hardware folks
to 
help with checksumming, I wholeheartedly agree with Randy. Remember that
SCTP is 
just a proposed standard, and is as such not all that far along the 
standardization process. We should still be able to make changes like this
if 
necessary.

Jon

>
>Q:
>
>The only problem with an additional "CRC chunk" is that
>it makes hardware assistance to error correction much
>more difficult. It is better (I think) to just realize
>we made a mistake. Get the opinions of the experts as to
>what checksum to use... i.e.:
>
>- CRC-32
>- Modified Adler-32 (16 bit word sums)
>- Fletcher-32
>- ???
>
>And then go with this as a replacement... Admit we were wrong
>and fix the problem..
>
>This way you have ONE and only ONE checksum algorithm making
>hardware designers life much easier...
>
>R
>
>Qiaobing Xie wrote:
>> 
>> Another solution could be (I think I mentioned this to Randy and a few
>> others at last IETF):
>> 
>> - Define a CRC-32 (or other strong checksum) control chunk and when the
>> sender wishes to use a stronger checksum protection, in addition to the
>> Adler-32 in the common SCTP header it includes this CRC-32 chuck in the
>> outbound packet. When the packet arrives, the receiver will do the
>> Adler-32 first, and then if the receiver supports the CRC-32 and sees
>> the presence of the CRC-32 chunk in the packet it will further verify
>> the CRC-32.
>> 
>> We could also use a bit pattern in the chunk type of the CRC-32 chunk so
>> that if the receiver doesn't understand the CRC-32 chunk it would drop
>> it with a report back to the sender.
>> 
>> -Qiaobing
>> 
>> _______________________________________________
>> 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