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]



    Julian:
    
    Your input would be invaluable.. please send us any comments
    or input when you are ready.. I think we need to be
    looking seriously at this in the early May time frame... so
    any input you could give would be most welcome. We are limited
    to a 32 bit checksum (the size of the common header CRC area).
    
    But within that restriction any input you may have as to the
    best for data integrety would be wonderful! 
    
    Regards
    
    R
    
    
    "WENDT,JIM (HP-Roseville,ex1)" wrote:
    > 
    > 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
    > 
    > >
    
    -- 
    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