RE: Response Fence Flag

Mallikarjun,

I must admit, that I have been a bit confused with the direction of the
conversation here.

 

Therefore, I went back and reviewed the charts from Dallas.  And as I
remembered, the initial focus was to address the issue of Multiple
Connections per Session (MC/S) (as stated on chart 4 - "Non-issue for
single-connection iSCSI sessions").  So I think I have missed the step
where we have morphed the discussion into one dealing with multiple
sessions.  (I am not sure how that happened, or if I miss-read the
charts from Dallas, or have not followed the discussion adequately.)

 

If we are attempting to define two different issues, one with MC/S and
one with Multiple Session from different Initiators, I think it would be
useful to break down the conversation into Topic A - MC/S and Topic B
Multiple Sessions.  It is possible that one solution will addresses
both, but I for one think I am hearing arguments that might be
appropriate for Topic B, while I am thinking about its applicability to
Topic A.

 

Perhaps, you could address the issue as either being all about MC/S or
explicitly state that it is intended to affect Multiple Sessions also,
and then address the issues and solution for each separately.  For
example, I believe Robert was addressing the issue from a view of
Multiple Sessions and if we only intended to address MC/S then I expect
the response might be somewhat different.

 

Anyway, if you could clear-up some of this, I think it would be useful
(at least to me).

 

.

.

.

John L Hufferd

Sr. Executive Director of Technology

Brocade Communications Systems, Inc

[email protected]

Office Phone: (408) 333-5244; eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

 

________________________________

From: Mallikarjun C. [mailto:[email protected]] 
Sent: Friday, January 05, 2007 10:08 AM
To: [email protected]
Subject: Re: [Ips] Response Fence Flag

 

Not really.  Current draft text is intentionally written to not have any
dependencies on T10 dynamics.  The point is that iSCSI needs such a
notion for succinctly describing the proper iSCSI protocol actions in a
few places - ACA, TMF, Persistent reserve/Abort to name a few.  We
certainly hope it will be approved by T10 and be a part of SAM-4 soon,
but that isn't required per se for describing what iSCSI needs for its
correct behavior.

 

IPS WG has adopted what it needs in the past - staying ahead of T10
review/approval cycle if necessary.  I_T nexus loss notification, iSCSI
target/port naming, clearing effects are a few I recall.

 

Mallikarjun



 

----- Original Message ----
From: Eddy Quicksall <[email protected]>
To: Robert Snively <[email protected]>; "Elliott, Robert (Server
Storage)" <[email protected]>; [email protected]
Sent: Friday, January 5, 2007 8:58:47 AM
Subject: Re: [Ips] Response Fence Flag

>From an earlier email I think that Response Fence is only a proposal in
T10 (http://www.t10.org:80/doc06.htm <http://www.t10.org/doc06.htm> ).
If so shouldn't iSCSI wait a bit until this has been ratified?

 

Eddy

	----- Original Message ----- 

	From: Robert Snively <mailto:[email protected]>  

	To: Elliott, Robert (Server Storage) <mailto:[email protected]>  ;
[email protected] 

	Sent: Thursday, January 04, 2007 1:01 PM

	Subject: RE: [Ips] Response Fence Flag

	 

	The problem is that the definition of "previous" in this context
is most likely flawed.

	 

	The "Response Fence" is merely an internal and untestable state
machine input that

	attempts to order the transmission of responses in the target
port's queue.

	It  does nothing to improve the overall ordering of the
responses at the application

	client.

	 

	Drivers for generic SCSI transports must always be aware that
requested operations

	report completion with a more or less arbitrary time
relationship to each other and must be

	designed to tolerate that.  

	 

	Using LOGICAL UNIT RESET as an example, the operation does not
act only on

	the device server.  As it passes down through the initiator
stack, it may clean out

	previously offered commands that have not yet been transported.
Then as it

	passes up through the target stack, it may clean out previously
offered commands

	that have not yet been operated on.  As it passes through the
device server

	execution path, it may clean out previously offered commands
that have begun

	execution and some that have completed execution without yet
responding.  As its 

	response passes back down the target stack, it may clean up
commands

	that have completed for which the response has not yet been
transmitted, and as

	it passes back up the initiator stack, it may clean up commands
for which the

	response has been transmitted, but not yet been made available
to the driver or

	application.  SAM-4 attempts to define the passage through the
target port,

	through the device server, and back to the target port.
However, beyond the

	initiator port is outside the SAM-4 scope, and even where it is
defined,

	the "shall ensure"s are unlikely to be testable and in some
cases not implementable. 

	 

	Will I sometimes get command complete indications for commands
after

	a LOGICAL UNIT RESET response is received?  You bet.  Response
Fence doesn't

	change that.

	 

	Will I sometimes get command aborted indications for commands
after a 

	LOGICAL UNIT RESET is response is received?  You bet.  Response
Fence

	doesn't change that.

	 

	Is this a problem?  It never has been in the past, why is it
now?

	 

	Can you test the corner conditions for a fence operation?  I
doubt it.  The

	existence of the "Response Fence" argument is internal to the
target

	implementation and invisible to testing.

	 

	Bob

	 

	 

	
________________________________


	From: Elliott, Robert (Server Storage) [mailto:[email protected]] 
	Sent: Wednesday, January 03, 2007 3:35 PM
	To: [email protected]
	Subject: RE: [Ips] Response Fence Flag

	SAM-3 and SAM-4 require all transport protocols to tag the TMF
responses with the requests:

	"Each SCSI transport protocol shall allow a Received Task
Management Function Executed confirming completion of the requested task
to be associated with the corresponding Send Task Management Request."

	Although iSCSI was based on SAM-2, it complies with that rule.
The Fence concept is asking for more than that - it wants the target to
be able to ensure that all previous commands/TMFs are complete before
delivering a particular TMF response (e.g., for a LOGICAL UNIT RESET).
Since iSCSI doesn't have ACKs, the target must wait for the next PDU
from the initiator with an updated ExpStatSN.

	06-341r0 discussed an alternative - add a Delivery Result output
to the Send Command Complete and Task Management Function Executed
confirmations (as previously proposed in 04-072r0 for a different
purpose). This would let the device server/task manager wait for all the
previous commands/TMF responses to complete (be ACKed) before proceeding
to make additional calls (e.g., Task Management Function Executed for a
LOGICAL UNIT RESET).

	However, iSCSI allows the target port to send a NOP-IN to force
delivery of a NOP-OUT with ExpStatSN, rather than passively wait for a
PDU to show up.  The device server/task manager must instruct the target
port when to do this, and the Request Fence argument serves that
purpose.  Target ports using protocols without such a force mechanism
are still OK - they will just wait for protocol-specific delivery
confirmations (e.g. ACKs).

	-- 
	Rob Elliott, [email protected] 
	Hewlett-Packard Industry Standard Server Storage Advanced
Technology 
	https://ecardfile.com/id/RobElliott 

	
	 

		
________________________________


		From: Robert Snively [mailto:[email protected]] 
		Sent: Wednesday, January 03, 2007 4:46 PM
		To: Elliott, Robert (Server Storage); [email protected]
		Subject: RE: [Ips] Response Fence Flag

		I need a little tutorial here.  Note that this is an
architectural hack that

		is very "un-SCSI" and is not required if the response is
qualified with identification

		information associated with the original request.  I
know that such qualification

		exists for commands, but does it exist for task
management requests in

		iSCSI?  

		 

		I know that it does exist for parallel SCSI (which is
strictly interlocked)

		and for SAS and Fibre Channel SCSI, making such "fences"
unrequired by

		those technologies.

		 

		Note that Rob's previous revision of 06-341 is available
on www.t10.org <http://www.t10.org/> .

		 

		I would hate to see such a hack creep into the SCSI
architecture.

		 

		Bob

		 

		 

		
________________________________


		From: Elliott, Robert (Server Storage)
[mailto:[email protected]] 
		Sent: Wednesday, January 03, 2007 1:56 PM
		To: [email protected]
		Subject: RE: [Ips] Response Fence Flag

		If T10 agrees, T10 proposal 06-341 will add it to SAM-4.

		 

		-- 
		Rob Elliott, [email protected] 
		Hewlett-Packard Industry Standard Server Storage
Advanced Technology 
		https://ecardfile.com/id/RobElliott 

		 

			 

			
________________________________


			From: Eddy Quicksall
[mailto:[email protected]] 
			Sent: Wednesday, January 03, 2007 2:00 PM
			To: [email protected]
			Subject: [Ips] Response Fence Flag

			Section 3.3.1 talks about a Response Fence Flag:

			 

			SCSI protocol layer instructs the SCSI transport
layer of a 
			"Response Fence" associated with the response in
question when 
			the "Send Command Complete" protocol data
service (SAM-2, clause 
			5.4.2) ...

			 

			But I don't see any reference to that in SAM-2.

			 

			Is this strictly an iSCSI flag? Where is the
flag specified?

			 

			Eddy

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

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

 


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

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