RE: iSCSI error recovery

["Douglas Otis" <dotis@sanlight.net>]

David,

Although further refinement of how the initiator is expected to use or not
use StatSN will not modify complexity involved in recovering from a digest
error after some undefined timeout of expected status.  The initiator is to
guess a sequence hole belongs to some pending SCSI tag?  It is to decide if
it should apply a CmdSN based on this lack of status for a retry?  Is this
complexity is to allow non-sequential processing of commands irrespective of
delivery failures?  As you can see, I remain skeptical.

With respect to CRC or Checksums, you could also include a finer subdivision
than just header and data.  To be more explicit about potential options,
there could be static and dynamic fields where to assist handshakes being
debated, a separate checksum for these handshakes would have advantages.
You could then add routing information as yet another field if this
information is to be modified by middle tier equipment.  And finally, the
tag, CDB and related data and associated vectors.  So from my perspective
here is a breakdown:

1) Dynamic fields regarding handshakes. (Hopefully obsoleting retry scheme.)
2) Routing fields (LUN).
3) Static fields (All else).
4) SCSI Cmnd (attributes), CDB, Data.

Where would you wish to see a separation between 1:2, 2:3, or 3:4 or a
single Checksum?

Doug



> There's been a lot of discussion on the list about this
> topic, including the proper use of CmdSN and StatSN
> to respond to errors including those detected by CRC.
> I hesitate to call consensus on any of this discussion
> because it's based on a version of the draft (-03) that
> is some combination of incomplete, incorrect, and/or
> difficult to comprehend in this area.  Based on this
> and the length/detail of the discussion, I suspect
> that many people on the list are not completely aware
> of the issues here, and calling consensus when a large
> segment of the WG may not understand the issues is
> unlikely to be productive.
>
> The next version of the draft (-04) SHOULD contain a
> much better section on error recovery with explanations
> and examples that make it significantly easier to
> understand.  Consensus calls on error recovery will not
> be made before it appears.
>
> Meanwhile, a few comments on ongoing issues:
> - If a CRC error occurs, trying to use any data covered
> 	by that CRC is generally not a good idea in the
> 	absence of other measures (e.g., an error-correcting
> 	code covering the field(s) of interest).
> - 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.
> - Mandating the use of IPsec or TLS solely to handle
> 	CRC-level integrity issues is overkill.
>
> 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
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>