Subject: Re: [Tsvwg] sctp error check, again

From: Randall Stewart at work <[email-masked]>
Date: Wed, 13 Jun 2001 16:02:27 -0500

Naveen:

As I have previously pointed out on the list. Chip Sharp and
I developed just such a draft. It is however quite in-elegant
since you must always implement BOTH algorithms. It seems
foolish to do so with almost no implemented base. Why would
we want to saddle a new protocol forever with this penalty 
of having to implement both checksum mechanisms..

At this stage we have NO reports of deployed production SCTP
and it is better, I think, to just change out to a new
sum then be saddled forever with options to negotiate a sum.

If such a thing is wanted, do a draft like Doug Otis's earlier
checksum/digest draft.. where you append a new chunk that can
be ignored... We can then discuss this seperately and then
deal with just the issue at hand.. choices 1, 2 and 3 :/

R

R

Naveen S Jain wrote:
> 
> Hi Hanns,
>         It is actually backward compatible. If the INIT does not contain
> the optional
>         parameter Checksum Type, it is assumed to be always Adler32.
> 
> Naveen
> 
> > -----Original Message-----
> > From: Schwarzbauer Hanns Juergen
> > [mailto:[email-masked]]
> > Sent: Monday, June 11, 2001 6:14 PM
> > To: Naveen S Jain
> > Cc: [email-masked]
> > Subject: RE: [Tsvwg] sctp error check, again
> >
> >
> > Hi Naveen,
> >
> > this would certainly be an option I would be happy with!
> >
> > From my point of view it's a strange argument stating that
> > the CRC calculation could be done in hardware. Certainly it
> > could, but this would prevent SCTP from providing the
> > performance as it is now on all currently available platforms
> > that do not have this piece of hardware. It seems to be an
> > argument from chip and board manufactures.
> >
> > I would like to put the additional burden, either use
> > specialized chips or suffer from performance degradation to
> > those that want to have the utmost protection against message
> > corruption and introducing the proposed negotiation would be
> > a reasonable way, albeit it is also not backwards compatible.
> >
> >
> > regards
> >
> > HannsJuergen
> > > -----Original Message-----
> > > From:       Naveen S Jain [SMTP:[email-masked]]
> > > Sent:       Monday, June 11, 2001 5:53 AM
> > > To: Randall Stewart; [email-masked]
> > > Cc: Douglas Otis; Allison Mankin; Scott Bradner; [email-masked]
> > > Subject:    RE: [Tsvwg] sctp error check, again
> > >
> > > Hi ,
> > >     I was wondering why the checksum negotiation was left out??
> > >     We can have some kind of negotiation based on a optional packet
> > > in the
> > >     INIT.
> > >
> > >     The endpoint initiating the association can
> > >     send the optional parameter to indicate the type
> > >     of checksum to be used. If there is no optional
> > >     parameter present with CRC32 as the type , then the
> > >     association can use the existing adler-32 checksum
> > >
> > >     In case this approach is  to be followed,
> > >     we will also need a additional cause value
> > >     of type "Checksum type not supported"
> > >
> > >     That way the SCTP applications which are
> > >     taking care of data sanity and requesting for
> > >     retransmit can still use the adler-32 checksum
> > >
> > >     Where CRC 32 Is Supported:
> > >     -------- (INIT with ad32 chsum requesting CRC32) ----->
> > >     <-------- ( INIT ACK with ad32 cksum acking CRC32 request) ----
> > >     --------- ( COOKIE Echo with CRC32 cksum) ------------>
> > >     <-------- ( COOKIE Ack with CRC32 cksum ) ------------>
> > >
> > >     Where CRC32 is not supported:
> > >     -------- (INIT with ad32 chsum requesting CRC32) ----->
> > >     <-------- ( INIT ACK with ad32 cksum nacking CRC32 request) ----
> > >     --------- ( COOKIE Echo with ad32 cksum) ------------>
> > >     <-------- ( COOKIE Ack with ad32 cksum ) ------------>
> > >
> > >     There can be the following rules:
> > >
> > >     1) Only the CLient (Originator of INIT mesage) can request for
> > >            Checksum type
> > >     2) The Server ( receiver of INIT Msg) should always ACK the
> > >            Checksum type provided it can support it.
> > >        or The Server should nack it it it is unsupported
> > >
> > >     3) It the Client requests "ad32" Cksum type,the Server has to
> > >             use "ad32" cksum even if it supports the CRC32 sum.
> > >
> > >     This way, the Applications will decide what they want
> > > (preformance
> > >     or reliability).
> > >
> > >     implications:
> > >     1) SCTP should support multiple Cksums for multiple
> > >             associations (ie. one association might be using
> > >             ad32 and another might be using CRC32)
> > >     2) SCTP runing as server should support both types of Cksums
> > >
> > >     3) Default will be the adler32 cksum
> > >
> > > Thanks and regards
> > > Naveen
> > >
> > > > -----Original Message-----
> > > > From: Randall Stewart [mailto:[email-masked]]
> > > > Sent: Saturday, June 09, 2001 1:14 AM
> > > > To: [email-masked]
> > > > Cc: Douglas Otis; Allison Mankin; Scott Bradner; [email-masked]
> > > > Subject: Re: [Tsvwg] sctp error check, again
> > > >
> > > >
> > > > Yes,
> > > >
> > > > Lets leave this whole digest chunk issue out of
> > > > play here... it just confuses the issue. We then
> > > > our down to two options....
> > > >
> > > > #1 leave things as they are - 5 in favor
> > > >
> > > > #2 change to CRC-32 - 18 in favor..
> > > >
> > > > Anything to do with digest chunks can be considered
> > > > seperately in say one of Dougs drafts... lets do
> > > > seperate threads to discuss please ... and instead
> > > > focus on getting consensus on this single issue
> > > > i.e. what (if any) to change the SCTP checksum to...>
> > > >
> > > > Scott/Allison: Is this a enough of a consensus for
> > > > CRC-32.. if so I will make the appropriate changes
> > > > the draft chip and I have ready and get it submitted??
> > > >
> > > > R
> > > >
> > > > Lyndon Ong wrote:
> > > > >
> > > > > Well, we can pretty much eliminate (2).  A digest
> > > > > should be considered as a separate issue, I think.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Lyndon
> > > > > --
> > > > >
> > > > > On Fri, 08 Jun 2001 12:13:50   Randall Stewart wrote:
> > > > > >Douglas:
> > > > > >
> > > > > >If you would like me to open another catagory i.e.
> > > > > >
> > > > > >Wants CRC-32 OR a Digest:
> > > > > >
> > > > > >I suppose I can.. but at this point, considering the
> > > > > >comments on the list.. i.e. have all faded.. I
> > > > > >think we are going to need to ask the chairs to
> > > > > >look at these results and determine if we have a
> > > > > >rough consensus...or not...
> > > > > >
> > > > > >I don't see that any more comments
> > > > > >are arriving...  your postion change would make things:
> > > > > >
> > > > > >Total 1) 5
> > > > > >Total 2) 1
> > > > > >Total 3) 18
> > > > > >
> > > > > >Total Double ballots) 4
> > > > > >Total unspecified) 2
> > > > > >
> > > > > >I think that double ballot people should be dis-qualified...
> > > > > >since we need a consensus for one of the choices.. not
> > multiple..
> > > > > >
> > > > > >We can always proceed in parrallel with a CRC/Digest chunk
> > > > > >and gage that seperate from changing the base sum...
> > > > > >
> > > > > >Has it stands now, it seems to me that we MAY have
> > consensus for
> > > > > >CRC-32... but I must leave that to the chairs....
> > > > > >
> > > > > >Scott/Allision? Do you think that we will get any more
> > > > > >results?
> > > > > >
> > > > > >Chip and I have the draft for just the checksum change
> > > > > >ready... all we need is for you to tell us what consensus is..
> > > > > >or that we don't have it yet :>
> > > > > >
> > > > > >R
> > > > > >
> > > > > >Douglas Otis wrote:
> > > > > >>
> > > > > >> Randall,
> > > > > >>
> > > > > >> You can put me into the CRC-32 camp but I would like
> > to also keep
> > > > > >> consideration of placement and digest open.  If this
> > > > process is to be
> > > > > >> offloaded either in software or hardware, the number of
> > > > passes through
> > > > > >> memory is important for performance.  Doing both a
> > > > digest and packet check
> > > > > >> within the header will ensure two passes are always
> > > > required.  I even
> > > > > >> suspect that with respect to encription, a very good crc
> > > > is not helpful at
> > > > > >> that point.  Although it is not a problem that we are
> > > > facing today, I wonder
> > > > > >> how this is to be done at 10GE.  Considerations as how
> > > > often memory must be
> > > > > >> touched in the process may be a concern.  Also if there
> > > > is a congestion
> > > > > >> problem causing a need for a path switch, this process
> > > > now has a double duty
> > > > > >> of rebuilding these packets without a packet level
> > > > digest which does seem
> > > > > >> possible.  If no header is used to allow check options,
> > > > then placing the
> > > > > >> check at the end of the frame has advantages in that a
> > > > word size pipe can
> > > > > >> handle two algorithms at once.
> > > > > >>
> > > > > >> Doug
> > > > > >>
> > > > > >> > Good Morning tsvwg :-)
> > > > > >> >
> > > > > >> > Coffee firmly in hand I now report once again
> > > > > >> > the current "straw-poll" standings on this thread :-0
> > > > > >> >
> > > > > >> > ****************************************************
> > > > > >> > PLEASE SOUND OFF IF YOU ARE IN THE WRONG
> > > > > >> > CATAGORY!!!! OR I HAVE MIS-READ YOU..
> > > > > >> > ***************************************************
> > > > > >> > Option 1 or 2:
> > > > > >> > --------------
> > > > > >> > Qiaobing Xie (wants the same or Modifed-Alder )
> > > > > >> >
> > > > > >> > Option 1 or 3:
> > > > > >> > --------------
> > > > > >> > Klaus Gradischnig (wants keep the same or CRC-32)
> > > > > >> >
> > > > > >> > Wants Others to decide/No-comment :>
> > > > > >> > ------------------------------------
> > > > > >> > Chip Sharp
> > > > > >> >
> > > > > >> >
> > > > > >> > No preference but wants only 1:
> > > > > >> > -------------------------------
> > > > > >> > Kacheong Poon ( wants only one sum, no options)>
> > > > > >> >
> > > > > >> > Still Unsure how to classify:
> > > > > >> > ---------------------------------------------------
> > > > > >> > Ran Atkinson (wants justification for any switch)
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > Option 1 - leave Adler-32:
> > > > > >> > --------------------------
> > > > > >> > Ian Rytina
> > > > > >> > Michael Tuxen
> > > > > >> > Shymall Prasad
> > > > > >> > Hanns J Schwarzbauer
> > > > > >> > Alf Heidermark (Since he agrees with Hanns??)
> > > > > >> >
> > > > > >> > Option 2 - Modifed Adler-32 or Fletcher-16:
> > > > > >> > -------------------------------------------
> > > > > >> > Gareth Kiely
> > > > > >> >
> > > > > >> >
> > > > > >> > Option 3 - CRC-32:
> > > > > >> > ------------------
> > > > > >> > Me
> > > > > >> > Michael Ramalho
> > > > > >> > Lloyd Wood
> > > > > >> > Jonathan Wood
> > > > > >> > Jim Williams
> > > > > >> > Stephen Bailey
> > > > > >> > La Monte Yarroll
> > > > > >> > Ivan Arias Rodriguez
> > > > > >> > Andreas Jungmaier
> > > > > >> > David Black
> > > > > >> > David Reed ** with preference for a MD5 Digest?
> > > > > >> > Douglas Otis ** with preference for a MD5 Digest?
> > > > > >> > David Lehmann
> > > > > >> > Brian Bidulock
> > > > > >> > Richard A. Adams
> > > > > >> > Robert Fairlie-Cuninghame
> > > > > >> > Wolfgang Schruefer
> > > > > >> > John Loughney
> > > > > >> > Laurent Glade
> > > > > >> >
> > > > > >> > ---------------------------------------------------
> > > > > >> >
> > > > > >> > Total 1) 5
> > > > > >> >
> > > > > >> > Total 2) 1
> > > > > >> >
> > > > > >> > Total 3) 19
> > > > > >> >
> > > > > >> > Total Double ballots) 3
> > > > > >> > Total unspecified) 2
> > > > > >> >
> > > > > >> > ---------------------------------------------------
> > > > > >> > Total folks commenting on: 30
> > > > > >> > ---------------------------------------------------
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Randall R. Stewart
> > > > > >> > [email-masked] 815-342-5222 (cell phone)
> > > > > >> >
> > > > > >> > _______________________________________________
> > > > > >> > tsvwg mailing list
> > > > > >> > [email-masked]
> > > > > >> > http://www1.ietf.org/mailman/listinfo/tsvwg
> > > > > >> >
> > > > > >
> > > > > >--
> > > > > >Randall R. Stewart
> > > > > >[email-masked] 815-342-5222 (cell phone)
> > > > > >
> > > > > >_______________________________________________
> > > > > >tsvwg mailing list
> > > > > >[email-masked]
> > > > > >http://www1.ietf.org/mailman/listinfo/tsvwg
> > > > > >
> > > > >
> > > > > Join 18 million Eudora users by signing up for a free
> > > > Eudora Web-Mail account at http://www.eudoramail.com
> > > >
> > > > --
> > > > Randall R. Stewart
> > > > [email-masked] 815-342-5222 (cell phone)
> > > >
> > > > _______________________________________________
> > > > tsvwg mailing list
> > > > [email-masked]
> > > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > > >
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
> >
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

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

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

---

From: Ian Rytina <[email-masked]>
Date: Tue, 19 Jun 2001 16:09:00 +0200

Hi Randy,

Would it be possible to release this draft to the general population ?
I'd certainly like to have a glance at it, and I suspect some others
would as well. Either as an I-D or directly to the list would be fine by
me.

/Ian.

---

From: Randall Stewart <[email-masked]>
Date: Tue, 19 Jun 2001 06:02:51 -0500

Ian:

I don't think that Chip or I have had any intention of putting
the draft forward. I will ask Chip what he thinks, but I don't
think either of us are in favor of it so why publish it. We
do have a draft to change the check in SCTP to 'CRC-X' ... but
of course it is incomplete until we reach a consensus :0

I think we have reached an impass in this debate. I will
repost the current stat's later today.. after which I think
we will need to ask the chairs for a call on things...

R