Subject: RE: [Tsvwg] sctp error check

From: [email-masked]
Date: Sat, 23 Jun 2001 20:50:05 +0300

Hi all!

> > Another idea:
> >
> > Sacrifice the high bit of the Verification Tag.
> > If it's 0, then Checksum is Adler32
> > If it's 1, then Checksum is CRC32
> >
> > Simple. No extra chunk. No negotiation.
> > 31 bits should be enough for the Verification Tag.

	I remember that Randall already proposed something like this at the
early stage of this discussion. I'm in the "use CRC" side, but I like this
approach Jacob is pushing again to the arena...

	We don't even have to sacrifice the high bit of the checksum.
Another idea comes to my mind, which is for example placing that "checksum
selection bit" in the Verification Tag... Let's say that the sender tells to
the receiver if it is using Adler-32 (or maybe better modified Adler-32, or
any other "soft" checksum) using a Verification tag with its first (or last)
bit set to 0 for example, and it announces the use of CRC setting it to 1...

	The Verification Tag would continue being 32 bits long, and it would
make the same work it is doing now, the only difference is that it carries
extra information... The selection of the Verification Tag would be as easy
as doing it exactly as before, and then set the lowest bit to 0 or 1... One
more line of code that is executed only once in the (hopefully long) life of
the association... :-)

	Moreover, we could move the checksum to the end of the datagram... I
think this is a good idea, not only for the reasons that have been already
stated, but also because you don't even have to save the value of the
checksum, set it to 0 and then calculate it and compare... just calculate
the checksum and compare it with the last word of the received datagram...
but this is another issue.

	These changes would imply one more line of code to be executed and
few extra code to be added to be able to calculate both Adler and CRC. You
just check the, let's say bit number 64 of the incoming chunk, and depending
on its value, go to one or other branch of your code and calculate one or
the other... The main problem I see with this is that maybe someone could
see it as "inelegant"... :-/ Special offer: no negotiation, no extra
checksum chunk, almost no extra processing, multiple checksum possibility...
now for sale! ;-)

	We could even use more than one bit, so more checksums can be
chosen, for example two bits and so we could include Adler-32, modified
Adler-32, TCP-32 and CRC-32... Hopefully this will make happy to people like
me wanting to use CRC, and people who wish no change or using modified
Adler-32, TCP checksum or whatever... But I don't want to divide votes even
more, this is being a long discussion and I have a Master Thesis to do! ;-)

	BR Iván Arias Rodríguez

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

---

From: Jacob Heitz <[email-masked]>
Date: Sat, 23 Jun 2001 11:02:39 -0700

> bit set to 0 for example, and it announces the use of CRC setting it to 1...

I did say to use high bit of VT, not high bit of checksum,
didn't I ?

> chosen, for example two bits and so we could include Adler-32, modified

I was hoping nobody would say that. Bugger.

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 10:02:55 -0500

> approach Jacob is pushing again to the arena...

I think if you look back you will see my proposal was to 
sacrifise a bit from the CRC itself... not the V-TAG. I object
to messing with the V-TAG!

> bit set to 0 for example, and it announces the use of CRC setting it to 1...

NO you have now lowered the bar on the V-T tag guessing game and
thus weakend the whole protocol. I could NEVER support this it
would be a BAD mistake. Lets instead weaken the checksum itself
NOT the V-T!!! (if one wants to go this route .. not I).

> more line of code that is executed only once in the (hopefully long) life of

No what you now have is a 31-bit verification tag and a flag. Thus
a weaker V-Tag. I DONT like this idea. We depend on the strength
of the V-Tag in Add-ip ... you are just expanding the scope of
the problem... This is a BAD thing!!

> but this is another issue.

The whole idea here was to NOT change the format much. If you take
this approach why not make the current checksum field into flag
bits! Then attach your trailing c-sum and the bits up front can
tell you all you want to send... I DONT LIKE THIS either but it
is FAR better then your weaker 31-bit VT..

> more, this is being a long discussion and I have a Master Thesis to do! ;-)

I am begining to  move into Ian's camp I am afraid... I have not
much more stomach for these changes everyone seems to be proposing.

I will have to think on this... maybe I should move to Missouri as
well!!

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 25 Jun 2001 12:56:47 -0500

....
> more, this is being a long discussion and I have a Master Thesis to do! ;-)

I think I have to say this once again :)

**The problem is NOT HOW TO support multiple checksums** 

If this were the focus of discussion, we would have finished this whole
thread a long time ago.

I think we already have had a clear consensus against multiple checksums
and have been focusing on the issue of picking which one for a while
(see Lyndon's email on 6/6).

-Qiaobing