Subject: [Ips] iSCSI: Task Management Functions and iSCSI Cross-Nexus requirement

From: "Pittman, Joseph" <[email-masked]>
Date: Thu, 10 Nov 2005 10:33:32 -0500

Recently, there has been some discussion on this mailing list about
the need for task management functions to be completed in a timely
fashion.
 
This discussion has reminded me of my objection to the following
iSCSI requirement regarding task management functions:
 
  The target must
  - Wait until it is certain that all affected initiators, even on
    other SCSI nexuses, have RECEIVED responses for all affected
    commands
  - Then it may send the task management response.
 
This requirement is originally stated in section 10.6.2 of RFC3720, and
is elaborated upon in section 4.1 of
draft-ietf-ips-iscsi-impl-guide-01.txt.

Consider the case where a target is processing a task management
function
(e.g. RESET_LUN) which has scope larger than the originating I_T_Nexus.
The target would like to complete this operation in a timely fashion.
But the 'wait-until-responses-RECEIVED' requirement forces the target to
be dependent upon the good behavior of all affected initiators.  If one
of the initiators is misbehaving or slow to report its receipt of these
responses, the target cannot complete the RESET_LUN.

Furthermore, I still do not understand the point of, or justification
for,
this requirement.
 
1) This kind of cross-nexus interdependency is clearly unnecessary for
   correct SCSI operation, since FCP-SCSI SANs have been successfully
   operating for years without such a requirement.
 
2) iSCSI is a transport protocol for SCSI.   Its responsibilities are to
     - satisfy the SCSI requirements for a transport protocol
     - map SCSI concepts onto the available mechanisms
     - effectively transport requests and responses between a SCSI
       initiator port and SCSI target port
 
   The SCSI protocol imposes no requirements regarding the relative
   ordering of delivery and receipt of responses across multiple
   I_T_Nexuses.  In my opinion, the iSCSI protocol has no business
   imposing such cross-I_T_Nexus requirements of its own.
 
3) Both the iSCSI spec and the iSCSI Implementer's Guide state the
   following:
 
     If some tasks originate from non-iSCSI I_T_L nexuses then the
     means by which the target insures that all affected tasks have
     returned their status to the initiator are defined by the
     specific non-iSCSI transport protocol(s).
 
   By my reading, the text is clearly requiring that the target
   make certain that the initiator has RECEIVED the responses,
   REGARDLESS of the transport protocol.  Thus the iSCSI spec is
   imposing additional requirements on other transport protocols,
   requirements beyond those imposed by the SCSI protocols themselves.
   It is clearly beyond the scope of one transport protocol to impose
   requirements on other transports.

In summary, I feel that the iSCSI specification is overstepping its
bounds by stating this unnecessary requirement.  For reasons both
practical and architectural, I request that the iSCSI Implementer's
Guide 'clarify' section 10.6.2 of RFC3720, by eliminating this
requirement.

--
Joe Pittman
[email-masked] <mailto:[email-masked]> 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips