Re: iSCSI: plugging CmdSN gaps

["Julian Satran" <Julian_Satran@il.ibm.com>]

You jumped to wrong conclusion. The
retransmission can be done on the same connection. The target can silently
ignore it if it has it already or accept it if it is a hole.
An initiator can retransmit after a
timeout (as it may think that the command has not been received by the
target due to digest failure).

Julo

"Buck Landry" <blandry@crossroads.com>
Sent by: owner-ips@ece.cmu.edu

12/02/03 06:18

To	<ips@ece.cmu.edu>
cc
Subject	iSCSI: plugging CmdSN gaps

Draft20 section 3.2.2.1 states:
   On any connection, the iSCSI initiator MUST send the commands in
   increasing order of CmdSN, except for commands that are
   retransmitted due to digest error recovery and connection recovery.

I would like to be sure I understand the scope of this.  I apologize
for the following example/"thought exercise".

I -> Text Request (CmdSN = 0x1, I = 0)

/* ExpCmdSN chosen in accordance w/section 6.3 "CmdSN .. MUST NOT
be considered received", and with the mailing list thread at http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05550.html
*/
T -> Reject (Long Operation Reject, ExpCmdSN = 0x1, MaxCmdSN = 0x10)

I assume nothing prohibits the initiator from doing:
I -> Scsi Command (CmdSN = 0x2, I = 0)

.. on this connection, even if it's the only connection in the session.
 This effectively skips CmdSN 0x1.

Since no digest error recovery or connection recovery is in effect, by
section 3.2.2.1 it appears the initiator can't issue another command w/CmdSN
0x1 on this connection.  Therefore if it wants to plug the gap, it
needs to do so on another connection (possibly opening a new one if no
others exist), *or* it needs to abort the Text Request as described in
section 6.3.

Did I jump to any wrong conclusions here?
Thanks, --buck