RE: iSCSI: retries and SCSI

[Black_David@emc.com]

Please keep in mind that we're talking about
optimizations available to an implementation
that chooses not to retain state for retransmits.

> > When the operation is not idempotent
> > (doing it over has ill effects - tape reads and writes
> > are examples), then this optimization is not applicable
> > and if the target hasn't retained the stuff required
> > to respond to the retry, it has to fail/reject the retry.
> 
> Thanks for the clarification on this. This approach of
> rejecting the retry, rather than not retrying for sequential
> devices, poses a couple of problems :
> 
> a) The responsibility of dealing with the reject will lie
>     with a iSCSI-pSCSI or iSCSI-FC bridge in most of
>     the tape connectivity cases.

If one doesn't know that the optimization is safe,
one shouldn't try it.  One bit of configuration per
target addressed through the bridge is sufficient to
turn this on or off, and it could default to off.
One could do better by looking at the iSCSI command
and the embedded SCSI CDB, and may have to in any case
because SCSI-ordered commands issued to a disk device
are not always idempotent (although my understanding
is that SCSI ordering is not generally used with
disks).

> b) The target iSCSI layer now needs to share SCSI state
>      information with its ULP on the device's class and abilities.
>      (something that would normally be exchanged b/n the peer
>       SCSI ULPs on either side.)

"share SCSI state" is the wrong phrase.  This is
about configuring the iSCSI implementation's handling
of retries.  That configuration is based on the SCSI
device's abilities, but I don't see a major issue here.

> I believe the draft already intends to address the issue of retries
> on a connection failure being made optional
> [if the initiator detects ULP timeout and wishes not to retry].
> 
> I would like to suggest that the same policy be applied to digest
> errors as well. (as initiators may not wish to retry on a digest error,
> when it sees a ULP timeout.).
> This allows initiators the flexibility to not retry the I/O to
> non-idempotent target media.

That seems reasonable, however this approach still
requires targets to cope with (e.g., reject) retries
issued by an initiator that exercised the flexibility
to make the other choice.  The initiator can choose
not to retry as an optimization because it knows that
retrying would be a waste of time for this target.

Keep in mind that even non-idempotent targets may
retain enough state to be able to respond to a retry
without re-executing the command.  I may have misread
what Santosh wrote, but ULP timeout sounds to me like
a SCSI-level timeout, something that should NEVER
cause iSCSI to issue a retry - that's the responsibility
of some sort of SCSI entity like a wedge driver. 

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