Re: Fast multi-task abort model

What I outlined calls out the RFC3720-legal
implementation aspects that will now be illegal (if we
"fix" the 3720-model beyond simple errata).  So some
implementation-specifics do become important in this
discussion.

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

Yes, at this point, it'd be good to get feedback from
others on the spec approach.  My last email summarizes
the tactical approach I intend to take for the next
draft revision.

Thanks.

Mallikarjun



--- William Studenmund <[email protected]>
wrote:

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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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