Subject: Fw: [Ips] Implementer's Guide - Task Management Issue

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 14 Dec 2006 03:31:55 -0800 (PST)

Trying again after clipping the tail, my first note bounced (size > 50KB)....

----- Forwarded Message ----
From: Mallikarjun C. <[email-masked]>
To: [email-masked]
Sent: Wednesday, December 13, 2006 12:21:18 PM
Subject: Re: [Ips] Implementer's Guide - Task Management Issue

I am still traveling and in different time zones, so apologies for being slow to respond.
 
IMHO, RFC 3720 had a good reason to require TTT completions on all initiators (issuing and third-party).  We took a more conservative approach "data transfers for terminated tasks cannot be active" at that time.  We also had concerns about ordering issues in multi-connection sessions.
 
By the IG time, we took a more relaxed approach "let data transfers for terminated tasks be in progress".  So the immediate question was:  So what happens to those Data-Outs with stale TTTs?  Roughly, there are two possible answers to that: a) let the target silently discard them, b) let the target maintain the buffer resources for "a bit longer" so the outstanding transfers can complete.
 
The current IG approach is not to recommend either (a) or (b), but leave enough room to implement either (a) or (b) per your implementation considerations.  iSCSI/iSER implementations have a particular problem with (a) because an invalid STag is fatal for the connection.   So I don't think we want to recommend (a) outright.
 
If a target wants to do (b), it needs a signal to deterministically free up resources - that's true for both issuing and third-party initiators (what is "a bit longer"?).  And that is the proposed Nop-Out.  So I do not see a qualitative difference between issuing and third-party initiators wrt the requirement on key negotiation to enable fast abort...... so I am so far not convinced that changing the current text is the right thing to do (I'll need to sync up with Julian to understand what I'm missing, and that is proving challenging due to both of us traveling).
 
I believe we're covered on the ordering issues with the new IG text - with the response fence notion.  So I wouldn't have any concerns on that front with what David is proposing.
 
Mallikarjun

----- Original Message ----
From: Julian Satran <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Wednesday, December 13, 2006 7:19:40 AM
Subject: RE: [Ips] Implementer's Guide - Task Management Issue

David, 

I agree - and I think there was general agreement on the mailing list that the language in 3270 (whatever it is) is confusing. 

Thanks, 
Julo 

[email-masked] 
12/12/06 22:35 ToJulian Satran/Haifa/IBM@IBMIL 
[email-masked] 
SubjectRE: [Ips] Implementer's Guide - Task Management Issue

Julian, 
  
I agree that the target should be able to do this (not delay TMF response 
waiting for an initiator that did not issue the the TMF), but the language 
I quoted from RFC 3720 explicitly requires the wait (and has been read 
to require the wait by more than one implementer). 
  
Can we agree that the implementers guide needs to clarify RFC 3720 
along the lines of what you wrote, and specifically say that completion 
of a TMF never has to wait for a response from an initiator other than 
the one that issued the TMF? 
  
Thanks, 
--David 

From: Julian Satran [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2006 3:12 PM
To: Black, David
Cc: [email-masked]
Subject: RE: [Ips] Implementer's Guide - Task Management Issue

David, 

The issue you are describing falls in the same category. 
Target can answer to B as soon as it has "purged" the tasks regardless of what A does. 
For safety the implementation should keep the pairs ITT-TTT and make sure it does not reuse 
the TTTs with the same ITT for a while or force closing offending sessions. 
There is no need to really delay the TM response - just act as if all outsanding activity died out and ignore data reaching the target. 

Julo 

[email-masked] 
12/12/06 20:26 
ToJulian Satran/Haifa/IBM@IBMIL 
cc<[email-masked]> 
SubjectRE: [Ips] Implementer's Guide - Task Management Issue

Julian, 
 
> As for the issue raised by Bill Studemund I am not sure that the target needs help in 
> recovering buffers (and I am not sure that I am not repeating what I said already in he past). 
 
The motivating concern is not buffer recovery - it's the ability of an uncooperative initiator 
to delay completion of a TMF issued by a different initiator.  Here's an example: 
 
- Initiator A has one or more data transfers in progress to the target. 
- Initiator A dies in some inconvenient fashion.  The target thinks the iSCSI
  session with Initiator A is still alive, but Initiator A is non-responsive. 
- Initiator B issues a TMF that has the effect of aborting Initiator A's tasks 
   (e.g., CLEAR TASK SET). 
 
The issue is: When can the target issue the TMF response to Initiator B? 
 
Current RFC 3720 language requires completion of Initiator A's data transfers or timing 
out and dropping Initiator A's session - Section 10.5.1: "The target on its part MUST 
wait for responses on all affected target transfer tags before acting on either of these 
two task management requests".  In this example, the data transfers will not 
complete, requiring timing out and dropping the session before the TMF response 
can be issued. 
 
The request is that it be permissible for the target to redirect Initiator A's data transfers 
to bit-buckets (just in case Initiator A is not actually completely dead) and issue the TMF 
response once that redirection (as well as everything that RFC 3720 requires with 
respect to Initiator B) is done so that the TMF response doesn't have to wait for the 
target to time out and tear down the session with Initiator A. 
 
Thanks, 
--David

____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

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

---

From: [email-masked]
Date: Wed, 20 Dec 2006 17:22:40 -0500

Mallikarjun,

> IMHO, RFC 3720 had a good reason to require TTT completions on all
initiators
> (issuing and third-party).  We took a more conservative approach "data
transfers
> for terminated tasks cannot be active" at that time.  We also had
concerns about
> ordering issues in multi-connection sessions.
>	 
> By the IG time, we took a more relaxed approach "let data transfers
for terminated
> tasks be in progress".  So the immediate question was:  So what
happens to those
> Data-Outs with stale TTTs?  Roughly, there are two possible answers to
that: a)
> let the target silently discard them, b) let the target maintain the
buffer
> resources for "a bit longer" so the outstanding transfers can
complete.

Just to make this more complex, I think there are two forms of b):
b1) The data yet to be transferred by the outstanding transfers will be
	processed by the task (command) that requested the transfer.
b2) The data yet to be transferred by the outstanding transfers will be
	discarded and *NOT* processed by the task (command) that
requested
	the transfer.
The difference between a) and b2) is that in a) the target maintains no
buffers or other resources for the stale transfers, aside from some
indication
of what the TTTs are that need to be discarded, whereas in b2) the
target
maintains the buffers for discard after the transfers complete.

> The current IG approach is not to recommend either (a) or (b), but
leave enough
> room to implement either (a) or (b) per your implementation
considerations.
> iSCSI/iSER implementations have a particular problem with (a) because
an invalid
> STag is fatal for the connection.   So I don't think we want to
recommend (a)
> outright.

Right, the language in the IG alerts the iSCSI/iSER implementer to the
possibility
of b2) - complete the transfers, but bit-bucket the results, in which
case the
TMF response can be returned early.
	 
> If a target wants to do (b), it needs a signal to deterministically
free up
> resources - that's true for both issuing and third-party initiators
(what is
> "a bit longer"?).  And that is the proposed Nop-Out.
> So I do not see a qualitative difference between issuing and
third-party
> initiators wrt the requirement on key negotiation to enable fast
abort......

If fast abort means that the target can safely assume that a transfer
won't
complete, we might be in agreement.  What I'm looking for is return of
the TMF
response while transfers from initiators other than the one that issued
the
TMF are outstanding.

Let's try this line of reasoning - the target issues the Nop-Out, now
when
can it free the resources?  Answer:
	- The Nop-In response comes back, OR
	- The connection times out and is torn down.
Now, what if the Nop-Out is not issued - what does the target wait for
to
free the resources?  Answer:
	- The transfers complete, OR
	- The connection times out and is torn down.
Those look similar enough at the target (the worst case is the same -
the
resources are tied up until an uncooperative initiator times out) that
I don't see the harm in allowing the early TMF return without the new
key.  The clear distinction is that the first two bullets are different;
if the new key is not negotiated, the target has to wait for the
transfers
to complete; the new key and the Nop-Out are necessary to walk away
earlier
when the initiator involved is able to continue the transfers.

> so I am so far not convinced that changing the current text is the
right
> thing to do (I'll need to sync up with Julian to understand what I'm
> missing, and that is proving challenging due to both of us traveling).

What I'm looking for is for a 3720-only target to be able to do a) or
b2)
and return the TMF response once:
	- It has completed everything (including outstanding transfers)
		with the initiator that issued the task management
operation.
	- It has arranged for outstanding transfers from all other
		initiators to be discarded.
The current language in 3720 requires the initiator to delay the TMF
response until all the discards to complete, and that's a real problem
in practice.
	 
> I believe we're covered on the ordering issues with the new IG text -
> with the response fence notion.  So I wouldn't have any concerns on
> that front with what David is proposing.

This sounds different, in that the response fence requires a new key
- I think I'm asking for an early TMF response without the new key or a
response fence.  Buffer recovery make take quite a while longer.

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: [email-masked]
Date: Wed, 20 Dec 2006 17:33:43 -0500

when
to
the
transfers
earlier
> when the initiator involved is able to continue the transfers.

That got slightly twisted - what it should have talked about was the
target
issuing the new Async Message and the Nop-Out response coming back.

Thanks,
--David

---

From: Julian Satran <[email-masked]>
Date: Thu, 21 Dec 2006 13:59:56 +0200

> TMF response can be returned early.

You might make the point that the language in iSER requires the Steering 
Tag to be valid (i.e. the packets having it must be accepted) but does not 
say what/if buffer has to stand behind it. An implemementer has enough 
room to make its its choices. Obviously an implementer that assumes that 
an STAG must have a buffer behind it will keep the buffers. Others may 
have a list marking "disconnected" STAGs and free te buffers.