Subject: RE: [Tsvwg] Trailing Checksum

From: [email-masked]
Date: Wed, 9 May 2001 12:10:59 -0400

> Now Jonathan Stone as told me that one of the most effective CRC's
> you can have is a trailing one. This supposedly helps even more
> I am not sure why but I am no expert.

Pipelined hardware can generate and append the CRC without
buffering the outgoing payload.  ESP (RFC 2406) uses trailing
authentication data for similar reasons.

As for whether to make a CRC optional or alternate, I'd like
to avoid repeating the TCP alternate checksum experience,
where RFC 1145 is not usable and not widely implemented,
(e.g., NATs break it).  I'm inclined to agree with you that SCTP
should have one way of doing this.

Thanks,
--David

> -----Original Message-----
> From:	Randall Stewart [SMTP:[email-masked]]
> Sent:	Wednesday, May 09, 2001 9:39 AM
> To:	[email-masked]; Jonathan Stone; Craig Partridge
> Cc:	[email-masked]
> Subject:	Re: [Tsvwg] SCTP and Checksums
> 
> David:
> 
> I understand your concern... and I had another
> interesting comment (off-line) from Al Varney.
> He sent me a CRC16 code CRC-CCITT to be percise.
> This is the same code used by MT2P... which is
> optimized for small messages.. Now, yeah, I know I know
> two sums are bad but one could envision:
> 
> 1) Use only the bottom 2 bytes of the current CRC.
> 2) Make the upper 2 bytes reserved/flags
> 3) Set one of the flags as a 'CRC-32' attached at end, not included
>    in CRC-16 check.
> 4) Set one of the flags as a 'No-CRC-16' flag, i.e CC-field in
>    header is 0x0000.
> 
> Now Jonathan Stone as told me that one of the most effective CRC's
> you can have is a trailing one. This supposedly helps even more
> I am not sure why but I am no expert.
> 
> I have often wondered if we did not make a mistake by not allowing
> some flags "Reserved" for the future in the common header...
> 
> With the above 1-4 one could:
> 
> A) Set a '11' in the flags and turn off CRC-16 and do inline hardware
>    CRC for say iSCSI.
> B) Set a '00' for standard environement in software so that you hold
>    the packet, copy out the 16 bit CRC and then run your standard
>    CRC-CCITT algorithm**.
> C) Set a '10' if you were really really paranoid and wanted both a
>    CRC-16 AND a CRC-32.
> D) Set a  '01' if you were completely trusting (or had some sort of
>    application level error correction) and wanted to disable all
>    CRC protection.
> 
> Now this is a radical idea and I need another cup of coffee and some
> performance numbers as well... but I am thinking it might just
> be viable... we could even change from say CRC-CCITT to the standard
> IP checksum if folks prefered this to CRC-CCITT... I really am
> non-descript
> about it...
> 
> Jonathan, Craig could you comment on this radical idea please???
> 
> R
> 
> 
> ** Note: I will use Al's code and run performance comparison on this guy
> today.. which
>          means results will be ready early next week...
> 
> 
> 
> [email-masked] wrote:
> > 
> > Ok, here's the objection you were expecting ...
> > 
> > As Jim Wendt has pointed out, iSCSI is currently
> > specifying error recovery (retransmits,
> > timeouts, etc.) that wouldn't be necessary if
> > there was a good CRC in the transport.  We have
> > no choice for TCP (e.g., the alternate checksum
> > breaks NAT), but this approach will land SCTP
> > in the same situation as TCP - iSCSI will
> > need error recovery logic, and there may be
> > work on adding a shim with the CRC that
> > should have been in the base protocol.
> > 
> > Given SCTP's description as the
> > general purpose transport for the future,
> > and the work that's been done to realize
> > that, failing to get this CRC vs. checksum
> > issue right is a shame.  Given that the
> > results show software overheads in the
> > same ballpark for checksums and CRCs,
> > I think choosing a checksum solely
> > because it's slightly easier to
> > do in software is short-sighted.
> > 
> > In practice, while I appreciate the suggestions
> > for how this could be addressed by some sort
> > of optional chunk, if SCTP becomes a
> > ubiquitous part of operating systems, and
> > the CRC chunk is optional, it won't be there,
> > and there'll be the same resistance to tinkering
> > with SCTP implementations as we have run into
> > on tinkering with TCP implementations.
> > At best, this optional chunk approach might
> > make putting in a CRC shim easier, but it won't
> > eliminate any of the error recovery
> > mechanisms that wouldn't be necessary
> > if the transport detected its own errors.
> > 
> > In the absence of a compelling reason for
> > why things should play out in this fashion,
> > put me on the record as objecting.  The fact
> > that iSCSI will be able to cope with SCTP
> > getting this wrong shouldn't be an excuse
> > for not doing it right.
> > 
> > Thanks,
> > --David
> > 
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > [email-masked]       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > > -----Original Message-----
> > > From: Randall Stewart [SMTP:[email-masked]]
> > > Sent: Tuesday, May 08, 2001 10:05 AM
> > > To:   [email-masked]
> > > Subject:      [Tsvwg] SCTP and Checksums
> > >
> > > Dear All:
> > >
> > > I am not beginning the RFC2960bis work as Lyndon put out. The question
> > > then turns to the checksum. For a first draft of the bis I will
> > > use the Fletcher-16 (its a 32 bit sum.. aka RFC1145). Any pre
> objections
> > > please raise them ASAP since I am just now beginning the wade through
> > > of the document..
> > >
> > > R
> > > --
> > > Randall R. Stewart
> > > Systems & Solutions Engineering
> > > Cisco Systems Inc.
> > > [email-masked] 815-342-5222 or 815-477-2127
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
> 
> -- 
> Randall R. Stewart
> Systems & Solutions Engineering
> Cisco Systems Inc.
> [email-masked] 815-342-5222 or 815-477-2127
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

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