RE: Re: Last Call Response Fence resolution

Bob,

> Implicit in 3.3.2 is knowledge of the timing of delivery
> to the iSCSI layer, not necessarily to the "application
> client".  I do not believe there is any defined time marker
> or pollable status available to a target that indicates when 
> delivery to the "application client" actually occurs that
> could be used to satisfy 3.3.1.  This is the
> generic ordering question at the root of my continued
> concern about this approach.

For 3.3.2, I don't think that's not correct, at least not to
the degree you've stretched it.  What's going on is an assumption
that any local delivery event of interest will have occurred
well before the round trip from initiator to target (acknowledge
status) and back (target does something as a consequence of that
acknowledgement).  Based on that assumption, the target's record
of acknowledged status is being used to drive the sequencing.

If one is in a situation where the assumption is false (e.g.,
app client is a low priority user process for which the OS does
not maintain an ordered event queue, allowing event reordering
over periods of time on the order of an iSCSI round trip),
then I would actually recommend that multi-connection iSCSI
sessions not be used, because the corresponding reordering
of commands is going to cause target-side holes in the CmdSN
sequence.  I also believe the example I used is indicative
of an OS shortcoming, and is not at all typical.  For typical
situations, I believe the assumption holds, the fence property
is useful, and the "pollable status" that drives everything is
the target's tracking of the acknowledged StatSN's.  iSCSI
doesn't use time markers.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Robert Snively [mailto:[email protected]] 
> Sent: Friday, January 26, 2007 5:30 PM
> To: Mallikarjun C.; [email protected]
> Subject: RE: [Ips] Re: Last Call Response Fence resolution
> 
> In the text below, there is one thing I am not sure
> I understand correctly.  The text in 3.3.1, item 1 (and
> implicitly item 2) says that "MUST be chronologically
> delivered after all the preceding responses... to the
> application client on the initiator.
> 
> Similarly in 3.3.2 item b) says "target iSCSI layer 
> takes note of last-sent and unacknowledged StatSN 
> on each of the connections in the iSCSI session, and 
> waits for acknowledgement (SHOULD solicit for 
> acknowledgement by way of a Nop-In) of each such 
> StatSN to clear the fence."
> 
> Implicit in 3.3.2 is knowledge of the timing of delivery
> to the iSCSI layer, not necessarily to the "application
> client".  I do not believe there is any defined time marker
> or pollable status available to a target that indicates when 
> delivery to the "application client" actually occurs that
> could be used to satisfy 3.3.1.  This is the
> generic ordering question at the root of my continued
> concern about this approach.
> 
> Since software constituting the application client (including
> kernel, OS, file system, application, etc.) must be designed
> to be tolerant of this ambiguity in any case, I believe we
> are spending a lot of effort creating an ordered case where
> the rare cases of misordering are already managed behavior.
> 
> Bob
> 
> -----  original text offered by Mallikarjun  -----------------
>  
> 3.3.1 Model Description
> Target SCSI protocol layer hands off the SCSI response messages to the
> target iSCSI layer by invoking the "Send Command Complete" 
> protocol data
> service ([SAM2], clause 5.4.2) and "Task Management Function Executed"
> ([SAM2], clause 6.9) service.   On receiving the SCSI 
> response message,
> iSCSI layer exhibits the Response Fence behavior for certain SCSI
> response messages (section 3.3.3 describes the specific 
> instances where
> the semantics must be realized).  Whenever the Response Fence behavior
> is required for a SCSI response message, the target iSCSI layer MUST
> ensure that the following conditions are met in delivering 
> the response
> message to the initiator iSCSI layer:
> (1) Response with Response Fence MUST chronologically be 
> delivered after
> all the "preceding" responses on the I_T_L nexus, if the preceding
> responses are delivered at all, to the application client on the
> initiator. 
> (2) Response with Response Fence MUST chronologically be 
> delivered prior
> to all the "following" responses on the I_T_L nexus. 
> The "preceding" and "following" notions refer to the order of hand-off
> of a response message from the target SCSI protocol layer to 
> the target
> iSCSI layer.
> 
> 3.3.2 iSCSI Semantics with the Interface Model
> Whenever the TaskReporting key (section 9.1) is negotiated to
> ResponseFence or FastAbort for an iSCSI session and the Response Fence
> behavior is required for a SCSI response message, the target 
> iSCSI layer
> MUST perform the actions described in this section for that session.:
> a) If it is a single-connection session, no special processing is
> required.  Standard SCSI Response PDU build and dispatch process
> happens. 
> b) If it is a multi-connection session, target iSCSI layer 
> takes note of
> last-sent and unacknowledged StatSN on each of the connections in the
> iSCSI session, and waits for acknowledgement (SHOULD solicit for
> acknowledgement by way of a Nop-In) of each such StatSN to clear the
> fence.  SCSI response with the Response Fence flag must be sent to the
> initiator only after receiving acknowledgements for each of the
> unacknowledged StatSNs.
> c) Target iSCSI layer must wait for an acknowledgement of the SCSI
> Response PDU that carried the response which the target SCSI layer
> marked with the Response Fence flag.  The fence must be considered
> cleared after receiving the acknowledgement.
> d) All further status processing for the LU is resumed only after
> clearing the fence.  If any new responses for the I_T_L nexus are
> received from the SCSI layer before the fence is cleared, 
> those Response
> PDUs must be held and queued at the iSCSI layer until the fence is
> cleared.
> 
> _______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 

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