RE: iSCSI:flow control, acknowledgement, and a deterministic recovery

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

Santosh,

You deleted my point :(

With multiple connections, if you are not going to use a valid CmdSN, or in
your case a null CmdSN for all commands, then there would be a need to
include a timestamp to meet a timely delivery requirement in the same manner
as used in FC encapsulation.  IP can deliver over any time period.  A
command could arrive at any time with respect to other connections.  With
all of your feedback now from just the SCSI layer, the SCSI layer is likely
to have timed out and restarted and now stray commands finally make an
appearance (the technician re-inserted the cable).  What did that do?  Yes,
if this were on a single connection, then TCP could provide some assurances,
(ignoring digests errors) but you must not make that assumption nor can you
assume all disruptions are symmetric.

If I was making an iSCSI device and expected to have an ability to control
resources, then your all null CmdSN implementation has made my equipment
dysfunctional.  My suggestion did not prevent your approach if the Casual
flag were adopted and it also kept the documented scheme for flow control
functional.  It also assures stray commands over multiple connections would
be rejected!  If you think ordered delivery is not needed as most disk
vendors do, then you should object to the requirements document just posted.
Sequential SCSI layer delivery as a mandate provides the most information
concerning the state of the SAN.

Doug

> Douglas Otis wrote:
> >
> > Santosh said all commands could use a null CmdSN in his first
> > statement.  Perhaps iSCSI should explicitly exclude this use.  This does
> > imply there is no acknowledgements, no flow control, and no sequential
> > delivery within iSCSI.
>
> Doug,
>
> What you state above is no different than a traditional SCSI transport
> implementation. The acknowledgements, flow control and sequential
> delivery properties are dervied from TCP. iSCSI behaves as an
> encapsulation only. Most host O.S. stacks and data applications have no
> expectations of strict ordering from the scsi transport. The QUEUE FULL
> has served as a flow control mechanism in the past.
>
> IOW, simple implementations may choose to derive benefits from existing
> mature TCP and SCSI algorithms rather than re-invent & re-implement all
> of the transport capabilities within iSCSI.
>
> There is no need to preclude implementations from sending all commands
> with a 0 CmdSN.
>
> As for your second conern regarding I/O timeouts, there is no need for
> any timestamp. An I/O timeout is dealt with by an Abort Task. The abort
> task response guarantees that the abort reached the target and pushed
> all intermediate stale frames. Failure to complete Abort Task leads to
> higher level error recovery (ex : Logout, or some higher form of task
> mgmt).
>
> - Santosh