Re: Last Call Response Fence resolution

David,

OK.  Didn't realize you were concerned about "flag", we may be converging.  Please take a look at the new text below.....

Mallikarjun

----- Original Message ----
From: "[email protected]" <[email protected]>
To: [email protected]; [email protected]
Sent: Thursday, January 25, 2007 6:44:53 PM
Subject: RE: Last Call Response Fence resolution (Was Re: [Ips] iSCSIImplementer's Guide - WG Last Call status, 2nd try)


Mallikarjun,

> I am trying to preserve the notion of an iSCSI-defined & 
> iSCSI-scoped Response Fence in the text (you seem to be OK 
> with it).  This gives us a convenient shorthand to refer to a 
> set of semantics.  Besides, if/when T10 approves the response 
> fence concept for SAM-4, iSCSI implementers will know what to 
> map it to for iSCSI.  As you'll see, I made it very clear in 
> the new text that this is not an attempt to change SAM in 
> this draft (which was of course never the intent).

I agree in principle with the intent where "Response Fence" is
iSCSI-scoped and defined "behavior."  OTOH, calling it a "flag"
is a problem.  I would prefer that all text anticipating
addition of a "flag" to SAM-4 be removed, and in particular
the following text:

> the following 
> semantics are defined for a "Response Fence" flag if such a 
> flag were to qualify SCSI completion messages as they are 
> handed off from the SCSI protocol layer to the iSCSI layer.  
> Note however that [SAM2] does not model such a flag in its 
> protocol interface model, so the "Response Fence" flag is an 
> iSCSI-defined artifact for descriptive convenience of the 
> mandatory iSCSI response ordering semantics.

which is just asking for an IETF Last Call comment or AD question
about why this circumlocution was used when it suffices to define
the "Response Fence" behavior without ever mentioning a non-
existent flag.  Section 3.3.3 doesn't need the flag - it can
refer to the behavior and say what it MUST be applied to.

If Rob succeeds in getting T10 to put a Response Fence flag
into SAM-4, we can deal with that flag in the draft that
deals with the impacts of SAM-3 and SAM-4 on iSCSI, which
will have a number of other things to deal with.  Before anyone
gets excited about this, I will state my view that the IETF
will need to ensure that all such impacts are specified in a
fashion that is backwards compatible with RFC-3720-only
implementations.

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


3.3 Model Assumptions for Response Ordering
Whenever an iSCSI session is composed of multiple connections, the Response PDUs (task responses or TMF responses) originating in the target SCSI layer are distributed onto the multiple connections by the target iSCSI layer according to iSCSI connection allegiance rules.  This process generally may not preserve the ordering of the responses by the time they are delivered to the initiator SCSI layer.  Since ordering is not expected across SCSI responses anyway, this approach works fine in the general case.  However to address the special cases where some ordering is desired by the SCSI layer, the following "Response Fence" semantics are defined with respect to handling SCSI response messages as they are handed off from the SCSI protocol layer to the iSCSI layer. 
 
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.

3.3.3 Current List of Fenced Response Use Cases

--- No changes ----


 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121

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