RE: Implementer's Guide - Task Management Issue

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


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