Re: Fast multi-task abort model

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

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