RE: iSCSI: CmdSN and Retry

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

Santosh,

1. iSCSI is based on TCP, a protocol that mandates sequential delivery.
2. TCP provides insignificant bandwidth if there is a high error rate.
3. Digest errors will happen at the 16-bit checksum undetected error rate.
4. Higher latency of networks makes such command-by-command constraints less
effective than a transport that assures sequencing.
5. There are many cases (not most) where order is significant. You could
make a better case for ensuring sequencing at the transport level than
negligible benefits derived from non-sequential processing of commands
following a digest error.

> Doug,
>
> The non-sequential event may be rare. However, the handshake should occur
> on EVERY I/O to safeguard against that rare event. [if 100% ordering is
> attempted.].

The only potential delay would be with respect to any skew between
connections.  If the PDUs are delivered in order, as they would be normally,
then there would be zero delay in the processing of the information.  The
pending handshake would only require the sender to retain a structure that
relates the sequence value to the PDU sent.  This handshake is trivial,
already within the structures, and only requires the return of an additional
packet before this structure can be removed.  Yes every I/O would be
examined to ensure its sequence but the same check is made to acknowledge
now.  Normally this results in no extra operation or delay.

> Strict ordering of 2 commands, say,  A followed by B, imply that :
>
> A target cannot execute B until the initiator acknowledges Status
> PDU for A. (This implies sequential operation on I/Os on the task set
> similar to untagged targets, only greater, because this behaviour is per
> session and not even per LUN.)

As status should enjoy the same independent assurance of delivery, SCSI
would not be impacted by a transport error as you imply nor would there be a
need to execute command-status-command-status. If you could not assure
reliable sequential delivery, then should such become important, then indeed
you would be required to execute command-status-command-status.  The benefit
from using the handshake would be to prevent this requirement.  Digest
errors will happen at the 16-bit checksum undetected error rate.  We are
taking about a flea of a flea with respect to any loss of performance.

> Since iSCSI applies strict ordering to all commands (well, all non-0 CmdSN
> commands), the above behaviour will be required on all I/Os within a
> session.

This is the claim but a claim that can not be assured due to the lack of
integrity in the current handshake.

Doug

> Regards,
> Santosh
>
>
> --
> #################################
> Santosh Rao
> Software Design Engineer,
> HP, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> #################################
>