SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: [Tsvwg] [SCTP checksum problems]



    
    
    Jim,
    
    Most of the reasosn for are in the text I sent you (an very few of the
    arguments against checksums - if you need more of those the are some
    preliminary memos on my site htpp://www.haifa.il.ibm.com/satran/ips). The
    CRC selected was from the "optimization" paper that appears in the
    references.
    
    
    Regards,
    Julo
    
    "WENDT,JIM (HP-Roseville,ex1)" <jim_wendt@hp.com> on 17/04/2001 20:43:51
    
    Please respond to "WENDT,JIM (HP-Roseville,ex1)" <jim_wendt@hp.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   ips@ece.cmu.edu, tsvwg@ietf.org, "'Craig Partridge'"
          <craig@aland.bbn.com>, Jonathan Wood <Jonathan.Wood@Sun.COM>,
          xieqb@cig.mot.com, Jonathan Stone <jonathan@dsg.stanford.edu>,
          Randall Stewart <rrs@cisco.com>, "WENDT,JIM (HP-Roseville,ex1)"
          <jim_wendt@hp.com>
    Subject:  Re: [Tsvwg] [SCTP checksum problems]
    
    
    
    
    Julian,
    The SCTP folks are right now discussing changing the SCTP checksum to be a
    CRC-32 (or other). This is a very good thing and really what needs to
    happen
    with SCTP for it to support iSCSI and other data-critical applications
    effectively (and also relieve iSCSI from having to implement data integrity
    checking and transport-like functionality over SCTP).
    
    They are looking for inputs as to which CRC-32 or checksum to use. The
    iSCSI
    WG's CRC investigation work and conclusion would be a valuable input into
    their decision. The sooner that you can provide the iSCSI recommended CRC
    and reasoning behind it to them, the better, even before the forthcoming
    I-D
    is distributed.
    
    Jim Wendt
    Networked Storage Architecture
    Hewlett-Packard Company
    jim_wendt@hp.com 916-785-5198
    
    ----------------------------------------------------------------------------
    
    -
    
    > -----Original Message-----
    > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
    > Sent: Sunday, April 15, 2001 7:58 AM
    > To: ips@ece.cmu.edu
    > Subject: CRCs
    >
    >
    >
    >
    > Dear colleagues,
    >
    > We will probably not be able to finish the CRC/checksum
    > document in time
    > for Nashua but we hope it will be out very soon after that.
    > However I
    > would like to inform you that while in Orlando and
    > Minneapolis we where
    > still talking about different CRCs we (Dafna Sheinwald, Pat
    > Thaler, Matt
    > Wakeley, Vince Cavanna and myself) have agreed on a CRC and
    > the forthcoming
    > ID will give all the reasons and why we recomend it.
    >
    > Regards,
    > Julo
    >
    
    ----------------------------------------------------------------------------
    
    -
    
    -----Original Message-----
    From: Randall Stewart [mailto:rrs@cisco.com]
    Sent: Tuesday, April 17, 2001 4:31 AM
    To: Jonathan Wood
    Cc: xieqb@cig.mot.com; tsvwg@ietf.org; Jim Wendt; Jonathan Stone; Craig
    Partridge
    Subject: Re: [Tsvwg] [SCTP checksum problems]
    
    
    Jonathan:
    
    I will make sure everyone at the bakeoff is aware of the upcoming
    "checksum" change... Now one of the big questions yet is
    what checksum should we use?
    
    I kinda lean towards crc-32 myself (but of course I have no technical
    basis for this and need to keep silent on which one to use anyway :->),
    but do we have other candidates besides fletcher-32 and possibly
    modified
    Adler-32 (i.e. 16 bit adds instead of 8)??
    
    I will take the above 3 and do a bit of performance work this
    week and post some numbers... thats about all I can do i.e.  tell
    how much time the options I know of take...
    
    If you have some other candidates let me know and I can possibly get
    some performance numbers on these as well...
    
    As far as which is the best... I encourage all of you check-sum
    experts out there to please join the thread :)
    
    Oh, I know Jonathan Stone's paper will NOT be ready until sometime
    in May.. so we may want to proceed slowly so that Craig Partridge and
    he can have some cycles to add to this dicussion :)
    
    R
    
    Jonathan Wood wrote:
    >
    > 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
    > >> tsvwg@ietf.org
    > >> http://www1.ietf.org/mailman/listinfo/tsvwg
    > >
    > >--
    > >Randall R. Stewart
    > >Systems & Solutions Engineering
    > >Cisco Systems Inc.
    > >rrs@cisco.com 815-342-5222 or 815-477-2127
    > >
    > >_______________________________________________
    > >tsvwg mailing list
    > >tsvwg@ietf.org
    > >http://www1.ietf.org/mailman/listinfo/tsvwg
    
    --
    Randall R. Stewart
    Systems & Solutions Engineering
    Cisco Systems Inc.
    rrs@cisco.com 815-342-5222 or 815-477-2127
    
    >
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:00 2001
6315 messages in chronological order