Fw: Implementer's Guide - Task Management Issue

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



----- Forwarded Message ----
From: Mallikarjun C. <[email protected]>
To: [email protected]
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 protected]>
To: [email protected]
Cc: [email protected]
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 protected] 
12/12/06 22:35 ToJulian Satran/Haifa/IBM@IBMIL 
[email protected] 
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 protected]] 
Sent: Tuesday, December 12, 2006 3:12 PM
To: Black, David
Cc: [email protected]
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 protected] 
12/12/06 20:26 
ToJulian Satran/Haifa/IBM@IBMIL 
cc<[email protected]> 
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 protected]
https://www1.ietf.org/mailman/listinfo/ips