Subject: Re: iSCSI: items discussed at WG meeting

From: "Julian Satran" <[email-masked]>
Date: Thu, 21 Mar 2002 17:59:19 +0200

Santosh,

my comments in text - Julo

Santosh Rao <[email-masked]>
Sent by: [email-masked]
21-03-02 02:19
Please respond to Santosh Rao

        To:     Dave Peterson <[email-masked]>
        cc:     "Ips@Ece. Cmu. Edu" <[email-masked]>
        Subject:        Re: iSCSI: items discussed at WG meeting

Dave,

Some queries inline.

Regards,
Santosh

Dave Peterson wrote:

> 4. Clause 6.7 SCSI Timeouts: explicitly state that a command retry 
shouldn't
> be performed after a SCSI level timeout.
> 
> "An iSCSI initiator MAY attempt to plug a command sequence gap on the 
target
> end (in the absence of an acknowledgement of the command by way of 
ExpCmdSN)
> before the ULP timeout by retrying the unacknowledged command, as 
described
> in Section 6.1 Retry and Reassign in Recovery."

Why would a scsi transport protocol be required to specify this ? Since
a ULP timeout is O.S. specific and is not an externally observable
value, either on the wire, or communicated to the target, why should
iscsi specify this ?

Different O.S. drivers may apply different timeout policies, with some
drivers allowing for some grace time to attempt to complete the I/O
after a timeout. 
 
IMO, the iscsi spec can be silent on what an O.S. specific driver does
when its O.S. specific ULP timeout expires. This is O.S. dependent.

> 6. Text stating that a TMF=Abort Task must be issued for each 
outstanding
> command. (Clause 6.7)

What does this mean (?). Could you elaborate further on this. 6.7
defines what action should be taken by an initiator on a SCSI timeout,
which occurs on a per-command basis and is dealt with individually for
each command.

Where do the remaining outstanding commands come into the picture,
unless, you're proposing that something like the FC second level error
recovery be performed, on failure of the abort (?).

+++ Santosh - Dave asked for some advisory statements and we can make some 
about the ISCSI part. We can add some statements to the implementor notes 
I will make the available to the list soon. +++
> 
> 7. Targets MUST support the command retry functionality. Don't think 
this
> functionality provides much benefit in its current state.
> Consider this case:
> a. tape locate command is issued with a 10 second ULP timer
> b. command is dropped at the target due to a digest error
> c. having seen no status for 8 seconds (for example) the iSCSI initiator
> decides to retry the command.
> 
> What happens with the timer on the first command? If it is not canceled, 
and
> if status is not received within 2 seconds, an abort for the command 
will be
> issued by the ULP.

Agreed. This is an issue in some cases, since not enough I/O time would
be available for the retry. However, the selection of the initial
command retry timeout value (when the initiator determines that the
cmdsn has not been acknowledged for a long enough period and decides to
retry the command) and the decision on whether to retry should be taken
by the initiator driver, based on how much ULP time remains for that
I/O.

(Again, this logic is mostly O.S. driver specific.)

> 
> dap: a mechanism to initiate error detection/recovery would be 
beneficial.

Could you expand on this some more ?

> 
> 8. CRN Processing and behavior: spec currently references SAM-2 for CRN.
> 
> Per SAM-2:
> Command Reference Number (CRN):
> When this argument is used, all sequential commands of an I_T_L nexus 
shall
> include a CRN argument that is incremented by one. The initial, wrap, 
and
> reset CRN values shall be one. The CRN value zero shall be reserved for 
use
> as defined by the SCSI protocol. It is not an error for the application
> client to provide this argument when CRN is not supported by the SCSI
> protocol or logical unit.
> 
> More text specifying the behavior of CRN in the iSCSI realm is needed. 
In
> addition, a method to determine if CRN is being used (or not) is 
missing.
+++ we made clear that CRN is a SCSI issue. The only think that we might 
do is the clearing but even there I am not sure that we should not call a 
"generic SCSI function" and let T10 define what the function will do for 
different devices - certainly after defining it+++
We went through this discussion several months ago in another ips
thread. CRN really belongs to the SCSI ULP and any mechanism to check if
the device server supports CRN should be in a SCSI ULP mode page (like
the Control Mode Page).

As far as iscsi is concerned, both the iscsi initiator and target
implementations MUST support CRN, since it is defined in iscsi command
pdu. 

Why is such a method required at the SCSI LLP layer ?

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: "Elliott, Robert" <[email-masked]>
Date: Mon, 25 Mar 2002 18:46:37 -0600

> -----Original Message-----
> From: Santosh Rao [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 6:20 PM
> > When this argument is used, all sequential commands of an 
> > I_T_L nexus shall include a CRN argument that is incremented 
> > by one. The initial, wrap, and reset CRN values shall be one. 
> > The CRN value zero shall be reserved for use
> > as defined by the SCSI protocol. It is not an error for the 
> > application client to provide this argument when CRN is not 
> > supported by the SCSI protocol or logical unit.
> > 
> > More text specifying the behavior of CRN in the iSCSI realm 
> > is needed. In addition, a method to determine if CRN is being 
> > used (or not) is missing.
> 
> thread. CRN really belongs to the SCSI ULP and any mechanism 
> to check if the device server supports CRN should be in a SCSI ULP 
> mode page (like the Control Mode Page).

I agree this bit fits better there, but to date there is no such 
bit in the Control mode page and no proposals on the T10 CAP 
agenda to add one.

In the only protocol supporting this feature (FCP-2), the bit is
in the Protocol-Specific Logical Unit Control mode page.  If a 
bit is added to the Control mode page for iSCSI and future
protocols, it makes FCP-2 targets non-compliant. I'm not sure 
that there are any implementations of CRN yet that would care. 

> implementations MUST support CRN, since it is defined in iscsi
> command pdu. 
>

iSCSI defers too much to SAM-2:
"9.3.2 CRN
 SCSI command reference number - if present in the SCSI 
 execute command arguments (according to [SAM2])."

To depend on the CRN in its Execute Command() remote
procedure call, an application needs to know:
a) the initiator port supports sending CRN;
b) if there are any protocol bridges/gateways in the service 
delivery subsystem, all the protocols between the initiator
port and target port support CRN;
c) the target port supports CRN; and
d) the logical unit supports and honors CRN.

Presumably the initiator's API will reject the RPC
if a) is not honored.  

Applications currently detect and set c) and d) with 
the Protocol-Specific Logical Unit Control mode page.
Moving to the Control mode page would be a change
but is certainly possible.  iSCSI needs to provide
this information/control somehow.

For b), bridges need to be able to report that CRN is not 
available over iSCSI because they're bridging to a protocol
that doesn't support it.

A text key would work pretty well, but this capability 
is logical unit based, not target-based.  This leaves 
intercepting mode page accesses and modifying the mode 
page data.

---
Rob Elliott, Compaq Server Storage
[email-masked]