Re: Fast multi-task abort model

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

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

Mallikarjun


 

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

> On Dec 1, 2005, at 4:01 PM, Mallikarjun C. wrote:
> 
> >> Why does it need to be cross-nexus, other than
> the
> >> fact that RFC 3720
> >> says it should be?
> >
> > There's a good rationale behind RFC 3720 text:
> >
> > TMF cannot complete until all affected tasks are
> > terminated on the target per SAM.  Receiving stale
> > data after tasks are terminated is a problem. 
> Waiting
> > for all active TTTs of all affected tasks (same
> and/or
> > other nexus) to finish was thus the adopted
> approach
> > to avoid stale data for any affected task.
> 
> Shouldn't we leave how the target avoids/copes with
> stale data to the 
> target?
> 
> I guess I don't see how receiving "stale" data after
> a task has been 
> terminated is a problem. Specifically I don't see
> how it's a problem to 
> receive data you knew was in-flight at the moment
> the termination 
> happened. You have your tcb structure (however you
> have it laid out), 
> and you know what TTs are associated with it. Mark
> the tcb as 
> terminated, then wait for the TTs to complete. When
> they are done, 
> throw the whole thing out.
> 
> > What the new proposal does is to make receiving
> stale
> > data after task terminations a non-problem - via a
> > separate accounting scheme and new target
> semantics.
> 
> And I think this is a good thing. However I still
> think we need to 
> abandon the inter-nexus TT wait for the old scheme.
> 
> Take care,
> 
> Bill
> 
> 



		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 


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