content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: iSCSI: plugging CmdSN gaps
Date: Tue, 11 Feb 2003 22:18:44 -0600
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52EDD68D3@hqmailnode1.commstor.crossroads.com>
Thread-Topic: iSCSI: plugging CmdSN gaps
Thread-Index: AcLSTdIeUaBRR+MUQwOkFa/7yQXe9w==
From: "Buck Landry" <blandry@crossroads.com>
To: <ips@ece.cmu.edu>
Content-Transfer-Encoding: 8bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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