Fw: Response Fence Flag

Julian Satran <Julian_Satran@xxxxxxxxxx> · Sat, 6 Jan 2007 09:31:40 -0500

Mallikarjun & All,

As I pointed out in a private discussion with you I never considered in

dept the response-fence (beyond what is needed for TM).

It is a serious issue for any "transaction type" operations to
storage - 

but the last interface that had all the pieces correctly aligned was the

360 channel.

SCSI had taken (traditionally) the positions that sequencing and 

barriers are rarely needed and when needed applications should provide
them.

And that is exactly what all of the relevant applications do (all 

transaction monitors, databases etc.).

The way all the application handle cases when the start of some SCSI 

command has to follow the end of a previous set of operations is to just

wait for the end of the operations before issuing the "dependent commands".

Is this solution optimal? As you probably observed already this solution

implies that all the queues in the "stack" (at initiator, transport
and 

target) get empty before the dependent commands can be issued and that

is bad for performance.

Can fencing (bad name BTW because it is in widespread use for defect 

isolation) improve this? Yes (by keeping the pipes full!) provided it is

associated with rigorous exception handling and the later is a SCSI 

issue (exceptions will require emptying the queues). With most 

applications being distributed I doubt also that fencing for a single 

I_T nexus is interesting and coordinating fencing and exception handling

over several I_Ts is a complex exercise.

And as transport alone brings no value to the whole issue - why  should

we go through the exercise of defining a solution before SCSI has 

defined one and we are confident that it is good enough and has value?

Again I agree that we a mechanism for TM but a good enough mechanism for

TM is already in and it gets now even better even without resorting to
a 

generalized fencing/barrier support.

Regards,

Julo

Mallikarjun C. wrote:

> Trying again after bouncing (>50KB), tail is now clipped....

>

> ----- Forwarded Message ----

> From: Mallikarjun C. <cb_mallikarjun@xxxxxxxxx>

> To: ips@xxxxxxxx

> Sent: Friday, January 5, 2007 2:40:56 PM

> Subject: Re:  Response Fence Flag

>

> Hi John,

>  

> As you correctly point out, there are two distinct but related 

> topics here.

>  

> (1) proper response ordering across participating connections in a

> multi-connection session, for a handful of task/TMF responses

> (2) proper way to terminate and signal tasks when actions on one 

> session can impact multiple initiators

>  

> (1) is all about response fence, it is covered separately in section

> 3.3 of IG draft.  That's what this email thread started off with.

>  

> (2) covers cases that IG had called as as "multi-task abort"
cases 

> that typically have a shared task set across sessions, or are the

> result of a Logical Unit Reset TMF.  Section 4.1 of IG adresses
(2).

>  

> So how are (1) and (2) related?

>  

> - Some cases covered under (2) overlap with (1), but some cases in
(2) 

> are for single connection sessions.  E.g. LU Reset on a single

> connection session impacting several 3rd party sessions

>  

> - Some cases under (1) overlap with (2), but some cases in (1) have

> nothing to do with other sessions.  E.g. establishment of ACA
on a 

> non-shared task set

>  

> - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for

> (1)) whenever multi-connection sessions are involved in multi-task

> abort situations.

>  

> I hope that clarifies it.  Feel free to ask if that is not clear.
 The 

> net is that the response fence is the underpinning notion to describe

> the correct iSCSI behavior in a few cases and some of those cases
are 

> about task terminations across third-party sessions.

>  

> Mallikarjun

>  

>

>

>  

> ----- Original Message ----

> From: John Hufferd <jhufferd@xxxxxxxxxxx>

> To: Mallikarjun C. <cb_mallikarjun@xxxxxxxxx>; ips@xxxxxxxx

> Sent: Friday, January 5, 2007 1:01:06 PM

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

>

> jhufferd@xxxxxxxxxxx <mailto:jhufferd@xxxxxxxxxxx>

>

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

>

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

>

>  

>

> ------------------------------------------------------------------------

>

> *From:* Mallikarjun C. [mailto:cb_mallikarjun@xxxxxxxxx]

> *Sent:* Friday, January 05, 2007 10:08 AM

> *To:* ips@xxxxxxxx

> *Subject:* Re:  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 <Quicksall_iSCSI@xxxxxxxxxxxxx>

> To: Robert Snively <rsnively@xxxxxxxxxxx>; "Elliott, Robert
(Server 

> Storage)" <Elliott@xxxxxx>; ips@xxxxxxxx

> Sent: Friday, January 5, 2007 8:58:47 AM

> Subject: Re:  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

>

>

> __________________________________________________

> Do You Yahoo!?

> Tired of spam? Yahoo! Mail has the best spam protection around

> http://mail.yahoo.com

> ------------------------------------------------------------------------

>

> _______________________________________________

> Ips mailing list

> Ips@xxxxxxxx

> https://www1.ietf.org/mailman/listinfo/ips

>   

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips