Re: Fast multi-task abort model

On Dec 9, 2005, at 7:05 PM, Mallikarjun C. wrote:

> Bill,
>
>> I still don't see how dropping the TTT wait will
>> hurt more than the
>> others. I'm really trying to, but can't.
>
> OK.  Let me attempt to be more specific.  Here are
> some spec implications if we eliminate the inter-nexus
> TTT wait from RFC 3720 text.  All these must be
> specified in addition to deleting the TTT wait.
>
> - Do not deallocate the buffers assigned to the
> currently active TTTs at the time of task termination.
>
> - Do not assign the outstanding TTT-LUN pairs to other
> tasks on the matching session-connection until a "TMF
> TTT-Buffer release event" although tasks that own the
> TTTs are terminated.

These details assume a specific implementation. I favor mentioning them 
as a suggestion, but different implementations may or may not need 
them.

For instance, an implementation that deals with mbuf chains may not 
need the buffers anymore. Just notice that the PDU is destined for a 
dying TTT and drop the mbuf chain.

> - Do not Reject any Data-Out PDUs with an invalid
> ITT-TTT combination if the combination has a buffer
> assignment.  Place the inbound data in the assigned
> buffer and ignore the data.

All we really need is for the PDUs to not be rejected. How exactly the 
target throws away the data is up to it. :-)

> - The outstanding TTTs and the assigned buffers can be
> freed only upon the corresponding "TMF TTT-Buffer
> release event".  The event can be one of:
> 	a) Last Data-Out PDU with the F-bit set for that
>            TTT-LUN combination (not an ideal fit for
> iSCSI/iSER)
> 	b) Implementation-specific timeout
> 	c) Connection/session termination

As above, this is an implementation detail. A target can just as 
reasonably close all connections after sending a "closing connection, 
you can immediately log back in" event. It's not as efficient, but it 
works. :-)

I do, however, like the idea of mentioning an implementation-specific 
timeout.

> And on the initiator side, we have to specify that an
> initiator must continue to respond to an outstanding
> TTT via Data-out PDUs even after the tasks are
> terminated - i.e. even after TMF Response with
> "success" is received.

I'm sorry, I only have been concerned about the inter-nexus delay. I 
think it's fine for the aborting/terminating session to have to be all 
cleaned up before proceeding. Thus the aborting session will not see 
the TMF response until after all its tasks have stopped.

Hmmm... Let me be firmer. I think we should leave the intra-nexus delay 
in place. Thus no session should have to sustain tasks after a 
"succesful" TMF Response.

> These are fairly invasive changes to current model.
> These *can* however be done.  Assume we have them all
> specified as RFC 3720 "errata", how far off would then
> the new multi-task abort model be?  I see only two
> additional items remaining - sending an Async PDU, and
> specifying one additional TMF TTT-Buffer Release
> event:"d) Receiving a Nop-Out ack for the Async PDU"

This is a good question.

The difference is that, at least as I envision things, the initiators 
will need no changes. Initiators designed for the old model will still 
work with this intermediate one. Also, we will not be changing the 
on-the-wire packets.

I like the new model, I just think that we need to fix the old one in 
addition to adding it.

> Given all this, I still think the best course of
> specifying this whole area is:
>
> (1) Make two specific deltas to RFC 3720 model as
> "errata"
>            (a) Delete 3rd-party CmdSN gap wait
>            (b) Delete 3rd-party StatSN ack wait
>     This would be the new default iSCSI behavior.
>
> (2) Define the new multi-task abort model separately.
> This
>     includes the above two deltas and the TTT-wait
> delta.
>     This will be the operational behavior only if
>     "FastMultiTaskAbort=Yes" is negotiated.

Well, we disagree. :-) What does everyone else think?

Take care,

Bill

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