RE: Implementer's Guide - Task Management Issue

[email protected] wrote on 21/12/2006 00:22:40:

> 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.
> 

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. 

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

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