RE: iSCSI error recovery

["Y P Cheng" <ycheng@advansys.com>]

> Meanwhile, a few comments on ongoing issues:
> - Given some of the CRC discussion, I think the conclusion
> 	in Orlando to have separate header and data CRCs is
> 	NOT the rough consensus of the WG.  We need to go
> 	back to a requirements discussion on this rather than
> 	debating exactly where to put the CRCs.  Would those
> 	envisioning middleboxes/gateways/etc. that would
> 	benefit from this sort of CRC separation please post
> 	short use cases/descriptions indicating the basic
> 	functionality of the box and which fields it needs
> 	to change (let's do this with reference to the header
> 	layout in -03 rather than subsequent changes)?  As
> 	part of the use case/description, please explain
> 	how/why Fibre Channel's single CRC covering both
> 	the frame header and data causes problems/difficulties.

With a single CRC covering both the frame header and payload, when a bad
frame is thrown away which is the only one in a sequence, the only way for
detecting the missing frame is timeout.  With separate CRCs for header and
payload, if the header CRC is still good, one can quickly inform the sender
about the error.  However, for iSCSI, the need for separate CRCs is not so
obvious in this context.  This is because the TCP header is still valid.
Hence, without relying on timeout, one can use on the TCP header to identify
the sender.  Needless to say, any attempt to use the contents covered by the
bad CRC is a cardinal sin for folks in storage industry.

Y.P. Cheng, CTO, ConnectCom Solutions Corp.