Subject: Re: [Tsvwg] RFC2960bis ... (SCTP in a dentist office)

From: "Lyndon Ong" <[email-masked]>
Date: Thu, 10 May 2001 17:40:58 -0700

Folks,

The expansion of the bis draft is partly my fault (BTW, "bis" is French for "again", I think - the first time I saw "bis" being used was at ITU).  

We need to reissue SCTP because of the checksum issue, and we should aim at getting the reissue out quickly.  Beyond that, since it will be a new RFC, we can also get some of the clarifications in to it that were identified in testing, where these clarifications are generally agreed.

The checksum issue has not been settled, in fact we need to get back to this.

Cheers,

L. Ong
 
--

On Thu, 10 May 2001 19:11:10   Qiaobing Xie wrote:
>Kacheong Poon wrote:
>> 
>> I strongly recommend that we hold on putting this in the bis document.
>> (Off topic, what does bis stand for and what does it mean?)  It is not
>> clear to me that there is any consensus on how it works, even for v4.
>> To put special rules which we don't have any real world experiment in
>> a protocol specification is not a good idea.
>
>I second Kacheong's opinion... 
>
>And to my understanding, the only reason for issuing a bis on SCTP at
>this point is to address the Adler-32 checksum problem. That is urgent
>because it has huge deployment impact. But now it seems that we are
>losing our focus.
>
>(Have we reached a consensus on the checksum yet?)
>
>regards,
>-Qiaobing
>
>
>---
>You are currently subscribed to sigtran as: [email-masked]
>To unsubscribe send a blank email to [email-masked]
>

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: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 11 May 2001 10:01:07 -0500

> The checksum issue has not been settled, in fact we need to get back

I thought we were waiting on data from some of our checksum experts.

Randy has provided some data that allow us to compare the COSTS of the
various options and has promised more data along those lines.

Would someone be so kind as to explain the BENEFITS of the various
options?  Issues that have been touched on but never compared across
the board are:

Accuracy of error detection (how many errors will it catch)
Kinds of errors detected (single bit, burst bit, worse)
How well studied
Interactions with lower layer checks

Right now, it looks like the CRC's take a couple orders of magnitude
more CPU than Adlers on small systems.  Their benefits need to be
really outstanding.
-- 
La Monte H.P. Yarroll      Home:                [email-masked]
   If you remember nothing else:  [email-masked]         NIC Handle: LY
   GPL - "Just give source a chance."