Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h1CBBqr14252
	for ips-outgoing; Wed, 12 Feb 2003 06:11:52 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h1CBBiW14247;
	Wed, 12 Feb 2003 06:11:44 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1CBBRlo070162;
	Wed, 12 Feb 2003 12:11:28 +0100
Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1CBBQpY139574;
	Wed, 12 Feb 2003 12:11:27 +0100
In-Reply-To: <CFD808D1D39ACB47ABFF586D484CC52EDD68D3@hqmailnode1.commstor.crossroads.com>
To: "Buck Landry" <blandry@crossroads.com>
Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu
Subject: Re: iSCSI: plugging CmdSN gaps
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
From: "Julian Satran" <Julian_Satran@il.ibm.com>
Message-ID: <OF49A8463D.82A987ED-ONC2256CCB.0039D3F3-C2256CCB.003D7869@telaviv.ibm.com>
Date: Wed, 12 Feb 2003 13:11:24 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 12/02/2003 13:11:26,
	Serialize complete at 12/02/2003 13:11:26
Content-Type: multipart/alternative; boundary="=_alternative 003A5097C2256CCB_="
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multipart message in MIME format.
--=_alternative 003A5097C2256CCB_=
Content-Type: text/plain; charset="US-ASCII"

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



--=_alternative 003A5097C2256CCB_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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).</font>
<br>
<br><font size=2 face="sans-serif">Julo</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;Buck Landry&quot;
&lt;blandry@crossroads.com&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: owner-ips@ece.cmu.edu</font>
<p><font size=1 face="sans-serif">12/02/03 06:18</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">&lt;ips@ece.cmu.edu&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">iSCSI: plugging CmdSN gaps</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Draft20 section 3.2.2.1 states:<br>
 &nbsp; On any connection, the iSCSI initiator MUST send the commands in<br>
 &nbsp; increasing order of CmdSN, except for commands that are<br>
 &nbsp; retransmitted due to digest error recovery and connection recovery.<br>
<br>
I would like to be sure I understand the scope of this. &nbsp;I apologize
for the following example/&quot;thought exercise&quot;.<br>
<br>
I -&gt; Text Request (CmdSN = 0x1, I = 0)<br>
<br>
/* ExpCmdSN chosen in accordance w/section 6.3 &quot;CmdSN .. MUST NOT
be considered received&quot;, and with the mailing list thread at http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05550.html
*/<br>
T -&gt; Reject (Long Operation Reject, ExpCmdSN = 0x1, MaxCmdSN = 0x10)
<br>
<br>
I assume nothing prohibits the initiator from doing:<br>
I -&gt; Scsi Command (CmdSN = 0x2, I = 0)<br>
<br>
.. on this connection, even if it's the only connection in the session.
&nbsp;This effectively skips CmdSN 0x1.<br>
<br>
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. &nbsp;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.<br>
<br>
Did I jump to any wrong conclusions here?<br>
Thanks, --buck<br>
<br>
</tt></font>
<br>
--=_alternative 003A5097C2256CCB_=--