Re: Fast multi-task abort model

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.

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

- 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

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.

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"

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.


Mallikarjun




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

> On Dec 8, 2005, at 10:45 AM, Mallikarjun C. wrote:
> 
> >> If the target breaks the buffer associations,
> does
> >> it really have to
> >> invalidate the TTT?
> >
> > We may be using different terminologies.....
> 
> Probably.
> 
> > I think of:
> > "invalidating the TTT" = "breaking the buffer
> > association" = "not having a buffer behind a TTT"
> >
> > And that can be a serious problem in iSCSI-3720,
> and
> > fatal in iSCSI/iSER.
> 
> Because of that concern, I would like to suggest we
> refine our 
> terminology, and make a distinction that hasn't been
> made before.
> 
> I suggest we consider "breaking the buffer
> association" at the SCSI 
> layer to be separate from breaking it at the iSCSI
> level. All the task 
> state diagram in SAM-2 (and later SAM) care about is
> the SCSI layer.
> 
> Specifically, I think it'd be fine for an abort to
> leave the TTT's 
> buffer around and simply do nothing with it once the
> TTT is done. Thus 
> all the PDUs flying at the target still find a
> destination (either in 
> TCP iSCSI or iSER).
> 
> >> I think it's fine for a task to be
> >> terminated at the
> >> SCSI level yet still have things going on (being
> >> cleaned up) at the
> >> iSCSI level.
> >
> > Precisely.  That's the fast multi-task abort
> model.
> >
> > I don't see a disagreement wrt the preferred
> behavior.
> >  Only on the mechanics of how to phase it in.  I
> think
> > if the inter-nexus TTT wait requirement from the
> 3720
> > text is deleted, we have to add several careful
> > sentences on how it would still work well with
> both
> > iSCSI-3720 and iSCSI/iSER.  By then, we would have
> > suggested enough deltas to protocol behavior that
> it
> > would be very close to the new proposal.
> 
> Kind of. I agree we will need to add text, but I
> don't think it will be 
> that bad.
> 
> I see the inter-nexus-TTT-fixup idea as an
> intermediate step between 
> what we have now and the new multi-task abort model.
> We add the idea of 
> not waiting for inter-nexus cleanup to finish (we do
> wait for it to 
> start!) and we add the idea that data arriving after
> cleanup started to 
> not get used by the SCSI layer. The new multi-task
> abort model then 
> adds a method by which we can cleanly fix multiple
> tasks at once.
> 
> > Note that this is different from scratching the
> other
> > two waits - inter-nexus CmdSN gap wait,
> inter-nexus
> > StatSN ack wait.  They can be simply dropped
> without
> > any additional mandates.
> 
> I still don't see how dropping the TTT wait will
> hurt more than the 
> others. I'm really trying to, but can't.
> 
> I fully agree I'm proposing a notable protocol
> change. :-) The reason 
> I'm contemplating it, much less strongly suggesting
> it, is that 1) I 
> think the wait we have isn't workable. Something
> needs to be done. 2) 
> I'm not really sure how initiators will notice the
> change. Since the 
> on-the-wire PDUs won't change, I suspect many
> initiators will never 
> notice.
> 
> 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