Subject: iSCSI: items discussed at WG meeting

From: "Dave Peterson" <[email-masked]>
Date: Wed, 20 Mar 2002 13:34:13 -0600

Howdy All,

Here are the items I brought forward at the WG face-to-face...

iSCSI Items

1. Provide (some) guidance for a ULP timeout value that is workable for the
various error detection and recovery scenarios.

2. TPGT handling: spec currently states;

"If a SendTargets response reports an iSCSI address for a target, it SHOULD
also report all other addresses in its portal group in the same response."

This statement brought up the question, what should the initiator do when
two separate SendTargets responses contain the same TargetName with
differing paths? Should the initiator believe the information in the first
response is no longer valid? Or should the initiator simply add the new path
to the target?

dap: consensus was that the information in the first response is no longer
valid. Marjorie to add appropriate text.

3. Text discussing the allocation of TPGT's (i.e. the target "controlling
entity" thingy). It is not common knowledge that such an entity exists on a
target implementation. There is no such entity on an initiator
implementation. Maybe the Naming and discovery doc speaks of this entity?

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."

5. Text stating that any data and/or status received for an aborted command
is discarded after sending a TMF=Abort Task. (Clause 6.7)

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

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.

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

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.

9. Mode page behavior: for example, an FCP initiator sends a mode page 0x18
(Protocol Specific LUN mode page) to a bridge/gateway. Is the bridge/gateway
allowed to simply forward the mode page into the iSCSI realm? Protocol
Specific Port mode page? Disconnect-Reconnect mode page?

I would expect the answer to be yes, the target can send Check Condition
with an ILLEGAL REQUEST/INVALID FIELD IN CDB.

But, not sure what an FCP initiator will do when this is command is
rejected.

dap: a few (or more) people indicated that a bridge/gateway device should
terminate protocol specific mode pages.

---

From: Santosh Rao <[email-masked]>
Date: Wed, 20 Mar 2002 16:19:55 -0800

Dave,

Some queries inline.

Regards,
Santosh

> 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

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 (?).

> if status is not received within 2 seconds, an abort for the command will be

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 ?

> addition, a method to determine if CRN is being used (or not) is missing.

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
##################################