Subject: RE: [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF)

From: "Pittman, Joseph" <[email-masked]>
Date: Wed, 3 Aug 2005 13:34:32 -0400

Julo,
 
Did you mean
  "SCSI requires that no packets"
 
or
  "iSCSI requires ..."
 
I see the requirement in the iSCSI spec, but I don't think the
T10 SCSI specs make any kind of multi-nexus ordering requirements
of this type.  If it just the iSCSI spec, and not the T10 specs,
then my original objections stand...
 
If the T10 SCSI specs do, in fact, impose such a requirement, can
someone point me to that?
--
Joe Pittman
[email-masked]

	-----Original Message-----
	From: Julian Satran [mailto:[email-masked]] 
	Sent: Wednesday, August 03, 2005 1:26 PM
	To: Pittman, Joseph
	Cc: [email-masked]; [email-masked]
	Subject: Re: [Ips] iSCSI: Question about
iscsi-impl-guide-00.txt, section 4 (TMF)

	SCSI requires that no packets pertained to the aborted tasks be
received after the response to the TMF (even if they are multi-NEXI). 
	However for the case of different NEXI you may have a point in
that different NEXI may not even all be iSCSI (SAM does not required
this type of homogeneity). 
	For other NEXI the requirement can be weakened with a statement
of "if this function is available in the transport of the other NEXI". 

	Julo 

"Pittman, Joseph" <[email-masked]> 
Sent by: [email-masked] 

03-08-05 18:31 

To
<[email-masked]> 
cc
Subject
[Ips]         iSCSI: Question about iscsi-impl-guide-00.txt, section 4
(TMF)

	This is a question about section 4 of the iSCSI implementer's
	guide, draft-ietf-ips-iscsi-impl-guide-00.txt. 
	  
	In particular, steps e) and f) in the target's sequence of
actions
	states the following: 
	  
	  The Target: 
	  
	     e) Takes note of last-sent StatSN on each of the
connections
	      in the iSCSI session(s) (one or more) sharing the affected
	      tasks, and waits for acknowledgement of each StatSN (may
	      solicit for acknowledgement by way of a NOP-In). 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). 
	  
	     f) Sends the task set management response to the issuing
	       initiator. 

	That is:
	- The target must wait until it has positive acknowledgement
that all
	 responses sent for all POTENTIALLY AFFECTED commands were
received by
	 their respective initiators
	- THEN the target may send the TMF response. 

	For the purposes of this mail message, I would like to separate
the 
	requirement imposed by steps e) and f), into two separate 
	sub-requirements: 
	  
	Sub-requirement 1, pertaining to:
	 Status/Responses for iSCSI requests (including SCSI tasks)
being
	 conducted on the SAME iSCSI session as the TMF itself. 
	  
	Sub-requirement 2, pertaining to:
	 Status/Responses for SCSI tasks being conducted on OTHER SCSI
	 I_T_L nexuses 

	I understand Sub-requirement 1 above.  Section 4.1.3 of the
implementer's
	guide, and especially bullet item 2 ('single ordered response
flow')
	clearly explains why the target steps e) and f) are necessary.
	The iSCSI multi-connection session feature introduces the
possibility
	of out of order arrival of responses at the initiator; it is the
	responsibility of the iSCSI initiator to reconstruct the
in-order
	response stream, to satisfy the expectations of the SCSI layer. 

	But I cannot understand why the iSCSI specification imposes
	Sub-requirement 2. 
	  
	- The SCSI-2 and SCSI-3 specifications do not impose ordering
	 constraints between two separate SCSI nexuses 
	  
	- iSCSI is merely a transport protocol for SCSI, so it seems
	 out of place for the iSCSI spec to be imposing additional
	 requirements on SCSI or other transports 
	  
	- It may not be possible to satisfy this sub-requirement with
	 certain other transports 
	  
	- There are many examples of configurations with multi-pathed
access
	 from a single host system to SCSI targets using non-iSCSI
transports,
	 without the "benefit" of sub-requirement 2. 

	And the current version of the implementer's guide does not
appear
	to shed light on the matter. 
	  
	Can anyone think of a justification for the inclusion of
	Sub-requirement 2 in the iSCSI specification?  If so, should
this
	topic be discussed in the implementer's guide? 
	  
	Thanks!
	--
	Joe Pittman
	[email-masked] <mailto:[email-masked]>
_______________________________________________
	Ips mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/ips

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