Subject: RE: [Tsvwg] SCTP and checksums

From: [email-masked]
Date: Fri, 4 May 2001 20:54:53 -0400

> This sounds like a serial bit-wise implementation. But isn't this going
> to take a lot more clock cycles to operate than a 32-bit parallel adder
> that is basically what a sum-based algorithm needs?

It can be done more than one bit at a time, and
the "adder" used for CRCs is both faster and simpler
than the adder used for checksums because CRC
arithmetic is carry-free (hence no carry look-ahead
circuitry with its inherent propagation delays).
This isn't the whole story, but the general point
is that CRCs are much more hardware friendly than
checksums (every Gigabit Ethernet NIC and Fibre
Channel HBA does CRCs in hardware), but the
reverse is true for software because processors
are very good at addition (table driven CRC
implementations take more cycles and space).

While I'm at it, let me add some comments from
an IP Storage (ips) WG point of view - I'm one
of the chairs, and I believe that the following
is a reasonable approximation of the
current WG (rough) consensus.

The IP Storage WG has clear consensus on the view
that checksums are inadequate to provide the expected
level of data integrity for block storage traffic,
and hence CRCs are required for all of our protocols
- this consensus has been checked on multiple occasions.
In addition, all of the storage protocol encapsulations
being specified by the IPS WG include additional header
integrity checks - CRCs or field inversions (16 bits
of <X> followed by 16 bits of the ones-complement of <X>).
The resulting ability to detect protocol header errors
above the level of TCP causes complications.

The impact on the protocol varies.  For iSCSI,
error recovery procedures are being developed
and they're not a pretty sight, leading some
individuals to explore the idea of putting a CRC
shim between TCP and IP in order to convert CRC
failures into TCP drops, and thereby eliminate
the need for much of the error recovery procedures.
The Fibre Channel encapsulations (iFCP and FCIP)
are in somewhat better shape only because the
error recovery procedures already exist at
a higher level (e.g., FCP-2).  Not having
to use such procedures is preferable, as FCP-2
is a relatively recent specification, but
there are situations (e.g., repeated retransmission
attempts cause excessive latency) where use
of this sort of thing is unavoidable.

From an IP Storage viewpoint, SCTP has a
unique opportunity to eliminate the less than
pleasant choice between a CRC shim and messy
error recovery procedures by putting a real
CRC into SCTP.  Not doing so will make SCTP
visibly less attractive for IP Storage use.

[-- End of description of IPS WG rough consensus --]

I'm well aware that IP Storage is not the
only or even the most important use of SCTP,
but I would urge TSVWG to consider whether
this'll be the only group of people looking
for this level of data integrity from SCTP.

I would suggest that there will be others,
and passing on this unique opportunity to
do things "right" by putting in a CRC may
be a cause for serious regret in the future,
especially if the decision is driven primarily
by computational efficiency concerns.

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
---------------------------------------------------

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