Re: Fast multi-task abort model

> If the target breaks the buffer associations, does
> it really have to 
> invalidate the TTT?

We may be using different terminologies.....

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.

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

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.

>either migrate
> everyone to the new 
> Async PDU or to warn implementors and administrators
> that failover can 
> take a long time on iSCSI.
>.... so we'll be at a
> competitive disadvantage.

Yes, multi-task abort affecting multiple nexuses
(i.e., excluding Abort Task Set) may indeed take a
long time in iSCSI today.  And yes, it is a
competititve disadvantage.  That is what prompted
several on the list to point out the current problems,
and prompted me to propose the new model.  We will
have seriously improved the situation in a few months.


Mallikarjun




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

> On Dec 6, 2005, at 3:12 PM, Mallikarjun C. wrote:
> 
> >> Mark
> >> the tcb as
> >> terminated, then wait for the TTs to complete.
> When
> >> they are done,
> >> throw the whole thing out.
> >
> > Reasonable, and this is in abstract what the new
> > proposal does.
> >
> > RFC 3720 does not explicitly say "wait for TTTs to
> > complete even after TMF is completed".  The only
> > default interpretation of the 3720 text today
> would be
> > to invalidate the TTTs along with the buffer
> > associations when a task is "terminated" and the
> TMF
> > completion is generated.  An invalid TTT/STag is
> in
> > fact a problem for at least two reasons -
> 
> If the target breaks the buffer associations, does
> it really have to 
> invalidate the TTT?
> 
> We're dragging in a lot of details that feel like
> they are 
> implementation specific. Our target has no trouble
> with the idea that a 
> task is dead yet has active TTTs, the contents of
> which will never be 
> used. We just let the TTTs drain off and clean up
> the task. We do this 
> as you've done a good job of explaining to me that
> things are REALLY 
> messy if we don't. :-)
> 
> As long as data received "after" (in terms of some
> atomic state change) 
> the termination will be discarded, does the
> termination act really care 
> how how the cleanup gets done?
> 
> Put another way, 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. As long as cleanup transfers aren't
> actually placed to the 
> SCSI device, I don't see why a target can't do this.
> 
> I understand that the STags won't be able to go
> away. But as long as 
> the target device doesn't use the buffers the STag
> goes into, is there 
> a problem? Thus if a target breaks buffer
> associations, we should be 
> fine, shouldn't we?
> 
> > a) All Data-Out PDU (with the now invalid TTTs)
> are
> > protocol errors that should be Reject'ed.
> > b) Any DDP tagged data segment to an invalid STag
> > immediately takes the connection down (for
> > iSCSI/iSER).
> >
> > What I am suggesting in the new proposal is that
> there
> > be an explicit event to conclude the "waiting for
> TTTs
> > to complete" for a target at the iSCSI control
> > protocol level (not at the Datamover level).  That
> new
> > event is the reception of the Nop-Out ack'ing the
> new
> > Async PDU.  And that brings us to the new
> proposal.
> 
> I understand that. But that's orthogonal to what I'm
> very concerned 
> about. I'm not concerned that session A waits for
> its TTTs, nor that 
> session B waits for its TTTs, nor that session C
> waits for its TTTs, 
> but that session D has to wait for all of them to
> complete a TMF.
> 
> I think that session A waiting for TTTs or using the
> new Async PDU is 
> fine. As for session B and session C.
> 
> > I think the 3720 text is self-consistent (although
> it
> > isn't the most efficient).  Simply scratching the
> TTT
> > cross-nexus requirement off the current text,
> IMHO, is
> > not the right thing. We need to specify the new
> > initiator and target semantics in the absence of
> that
> > requirement, and that's what the fast multi-task
> abort
> > proposal attempts.
> 
> We have a denial of service window. I don't see how
> we can get rid of 
> it w/o ripping out the cross-nexus TTT wait.
> 
> I also don't understand why it's ok to remove the
> inter-nexus wait for 
> the new technique and not for the old?
> 
> The only alternatives I see are to either migrate
> everyone to the new 
> Async PDU or to warn implementors and administrators
> that failover can 
> take a long time on iSCSI.
> 
> The latter will be a real shame. My understanding is
> that FibreChannel 
> doesn't have such delays, so we'll be at a
> competitive disadvantage.
> 
> 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