Subject: Re: [Ips] Clearing the outstanding TTTs

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 03 Nov 2005 16:38:42 -0800

Bill,

 > I feel that these TMF actions are exactly the thing you want to use when
 > things are broken and the TTTs WON'T clear, yet making them wait for
 > clearing actually makes that impossible.

I wonder about this reasoning though, because I see TMF as an attempt to 
deal with target-side problems rather than initiator's.  If a TTT
does not clear, it's most likely an initiator problem.  (although one 
could construct counter-examples)

But I see the overall concern - the task termination process is much 
longer than the ideal.

As we know, two broad approaches exist for a target dealing multi-task 
abort situations:

I) Wait until all active affected TTTs become invalid and then
    act on the TMF

II) Act immediately on the TMF, terminate all affected tasks
     immediately

I see a few options under approach (I).

a) Wait indefinitely
b) Wait until a pre-negotiated timeout (a new key?)
	- considerably narrows, but does not avoid the data in
           flight problem.
c) Wait indefinitely, but feel free to use a big hammer
	- Currently the sanctioned behavior in RFC3720 &
           implementer's guide.

And I see a few options again under approach (II).

a) Deal with Data-outs in flight to invalid TTTs on an ad-hoc basis
	- messy buffer management, connection drops with iSCSI/iSER

b) Proactively drop all Third-party affected sessions, and all other
    connections in the issuing session.
	- Way too big hammer.

c) Adopt a new scheme that is more elegant, and more responsive
    to TMFs - albeit it might turn out to be more complex to implement
    in order to be SAM-compliant.

I am exploring a (II-c) scheme - I'll attempt to send it out shortly 
(unless I spot major bugs myself).

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

William Studenmund wrote:
> On Oct 31, 2005, at 3:27 PM, Mallikarjun C. wrote:
> 
>> Bill,
>>
>> I hope you are not suggesting conditioning iSCSI protocol behavior 
>> based on SCSI TAS bit setting.
> 
> 
> I am proposing a MAY. The main condition for the MAY is that there be a 
> way to know if the initiator is aware of the abort. I do not see how it 
> is onerous that TAS bit setting, which is one of the controls dictating 
> if the initiator is aware of the abort, comes into play. iSCSI has 
> spoken about things that SCSI has to support, such as autosense, so we 
> have a precedent of one layer influencing another.
> 
> Since iSCSI is, strictly speaking, following SAM-2, we could use an 
> Asynchronous Event containing a Unit Attention of COMMANDS CLEARED BY 
> ANOTHER INITIATOR. We then use acknowelgement of the Async Event as 
> indicating that all tasks on all sessions have stopped; unfortunately I 
> doubt this will work for MC/S.
> 
> We already say you MUST use autosense and you SHOULD use ACA, maybe this 
> discussion indicates LUs SHOULD initialize TAS to 1 on reset.
> 
>> Also, the process of discarding the Data-out PDUs itself transiently 
>> consumes some buffers.  And bad things happen for iSCSI/iSER if the 
>> tagged buffers are not available.  I do not want us to spec different 
>> task set behaviors for iSCSI-3720 and iSCSI/iSER.
> 
> 
> I don't think iSCSI-3720 and iSCSI/iSER will have different task set 
> behaviors with this proposal. I agree we should not lightly do that...
> 
> The idea is to give the initiator a second way to indicate that it 
> agrees the task is dead. The motivation is that it is a way that does 
> not require the Task Management Function to wait for the initiator to 
> agree the task is dead; between the TMF deciding the task is dead and 
> this acknowledgement, any received data will be discarded.
> 
> As for non-TCP transports, I think I can think of a few ways to make 
> this work. These thoughts are still very rough. They would depend on the 
> target's behavior, but since this is a MAY that the target can choose, 
> it just avoids the choice if it can't make things work.
> 
>> Finally, we have to specify an approach that works for 
>> multi-connection sessions (where a Response/Ack etc. on one connection 
>> says nothing about data in flight on others), as well as with 
>> operations affecting SCSI objects accessible via multiple sessions 
>> (clear task set, LU reset etc.).
> 
> 
> The multiple sessions case is EXACTLY why I want this.
> 
> As for MC/S, I agree that one connection says nothing about data in 
> flight on others. But a given command is supposed to be allegiant to 
> only one connection at a time, so that the target receiving StatSN 
> acknowledgement of a tasks's (aborted) status will say something about 
> all of the data for that given task. Iterate over all the tasks, and we 
> will know that no data are in flight.
> 
>> I would be willing to consider any proposal that meets these 
>> requirements.  The Implementers' guide details one such (arrived at 
>> after a lot of discussion on the list).  I am however not sure I 
>> understand your concerns per se.
> 
> 
> If initiator 2 is using TMF LU Reset to clean up after initiator 1 
> because initiator 1 caught on fire and exploded, how will initiator 1 
> ever clear its outstanding TTTs?
> 
> That's my concern - waiting for the TTTs to clear assumes that they will 
> actually clear.
> 
> I feel that these TMF actions are exactly the thing you want to use when 
> things are broken and the TTTs WON'T clear, yet making them wait for 
> clearing actually makes that impossible.
> 
> To fix this, we either depend on the target timing out the TTTs, the 
> target does something we don't talk about yet (like close all the 
> connections, thus terminating in-flight data), or the TMF LU reset waits 
> forever (or until the repair person comes out and replaces initiator 1). 
> We give no guidelines to targets or initiators about timeouts (which I 
> think is a fine thing), yet I think this is a case where sanity and 
> interoperability would really need it.
> 
> My desire is to provide a way, within the spec, to permit the TMF 
> actions to complete in a timely manner and also maintain the requirement 
> that no status for these aborted commands be generated after the TMF 
> completes. And for all of this to happen when one or more of the 
> initiators is slow or dead.
> 
> Another case where this can arise is when the iSCSI session goes over 
> the public internet. We have had a few inter-continental deployments, 
> and they give a different view on what exactly is timely behavior.
> 
> 
> If we are in a data center, with good connectivity and active hosts, I 
> agree that what you have proposed in this document is very nice. It's 
> politer than just aborting, and if TAS is 0, it can be very important. 
> My concern is what do we do if we have inactive hosts and/or bad 
> connectivity.
> 
> 
> Thank you for continuing to respond even when you don't understand why 
> I'm making a fuss. I appreciate it. Also, you are more clever about 
> these issues than I am, and a solution to this issue with your input 
> will probably be much better than any without. ;-)
> 
> Take care,
> 
> Bill

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

---

From: William Studenmund <[email-masked]>
Date: Mon, 7 Nov 2005 10:49:20 -0800

On Nov 3, 2005, at 4:38 PM, Mallikarjun C. wrote:

> I wonder about this reasoning though, because I see TMF as an attempt 
> to deal with target-side problems rather than initiator's.  If a TTT

I just realized one point I had forgotten to make clear. Our target 
uses the task set clearing code to also handle Persistent Reserve Out 
Preempt and Abort operations. So I have had bad target and bad 
initiator cases in mind all the time. :-)

> But I see the overall concern - the task termination process is much 

I'm also reviewing your proposal. Thank you for making it.

Take care,

Bill