RE: Re: Last Call TMF resolution

I think I see some of where I'm confused.  4.1.2 and 4.1.3 are
about what the initiator that sent the TMF does as well as the
target.  We need to explain what a 3rd-party initiator does,
which for a 3720-only initiator is unchanged.  I think your
new 4.1.4 is headed towards covering this in addition to the
Target behavior in a mixed FastAbort/non-FastAbort case.

One crucial point that needs
to be made is that a FastAbort initiator may get an AsyncEvent=5
message out of the blue if some other initiator, even a Legacy
initiator, issues a TMF that affects the FastAbort initiator's
tasks, even if the iSCSI session only contains a single TCP
connection (FastAbort initiator will never get AsyncEvent=5
messages for its own TMFs on a single connection session).

On another minor note, "Legacy" as a key value seems pejorative
to me. "RFC3720" would be neutral and in fact more descriptive
of what's actually going on.

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun C. [mailto:[email protected]] 
> Sent: Friday, January 26, 2007 2:36 PM
> To: [email protected]
> Subject: [Ips] Re: Last Call TMF resolution
> 
> David,
> 
> bullet g is saying:
> "g. MUST free up the affected TTTs (and STags, if applicable) 
> and the corresponding buffers, if any, once it receives each 
> associated Nop-Out acknowledgement that the initiator 
> generated in response to each Async Message."
> 
> It does not assume a Nop-Out always, it simply implies that a 
> Nop-Out ack is received for each Async.  Don't see any issues 
> for legacy initiators that don't send Nop-Outs (which were 
> never sent Asyncs anyway per the new clarification added in 
> bullet d).  Looks alright to me.  Are you OK?
> 
> 
> Regarding your issue with 4.1.2 (which you consider as a 
> omission), I tend to slightly differ.  Note that section 
> 4.1.2 is exclusively meant for all implementations - old and 
> new.  So I did not want to put any wording in there that 
> requires them to implement and support FastAbort on 
> third-party sessions as the baseline behavior (that imposes 
> an unfair requirement on all targets to implement unlike 
> initiators which can choose to implement the new semantics).  
> But your comment OTOH is valid.  So I think the best way to 
> address your comment is put in more text (sigh...) in a new 
> section 4.1.5.  It's attached below.  Take a look and let me 
> know if that's along the lines of what you are looking for or 
> I'm off.....
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> 
> ----- Original Message ----
> From: "[email protected]" <[email protected]>
> To: [email protected]; [email protected]
> Sent: Thursday, January 25, 2007 6:35:02 PM
> Subject: RE: Last Call TMF resolution (Was Re: [Ips] iSCSI 
> Implementer's Guide -WG Last Call status, 2nd try)
> 
> 
> Mallikarjun, 
> 
> > Let me respond to your note under two separate covers.
> > 
> > Regarding b1, good catch!  I fixed the text as below:
> > 
> > d. MUST generate an Asynchronous Message PDU with AsyncEvent=5
> (section 8.1) on:
> > i) each connection of each third-party session to which at 
> > least one affected task is allegiant if 
> > TaskReporting=FastAbort is operational on that third-party session,
> 
> I think g. needs some related attention, as it assumes a Nop-Out
> that won't happen when the AsyncEvent=5 message is not sent.
> 
> > Regarding b2, I agree with you that it should be at least a 
> > SHOULD, if not a MUST (since FastAbort was already negotiated 
> > on that session).  However, I do not see which specific text 
> > in 4.1.2 you believe is implying a MUST NOT.  Need more help 
> > here.  Just to be clear, I now added the following to 
> > initiator behavior in 4.1.3:
> > 
> > c. MUST respond to each Async Message PDU with AsyncEvent=5 
> > as defined in section 8.1 (this step also applies when the 
> > initiator is receiving the Async Message in the third-party role).
> 
> The 4.1.2 problem is omission of text.  4.1.2 never covers the
> possibility that one could use FastAbort on a third-party session
> when the TMF arrived on a non-FastAbort session.  I interpret this
> as "MUST NOT" on the theory that this area of task management is
> tightly specified, and hence both 4.1.2 and 4.1.3 come with
> "MUST NOT do anything else" requirements.  We'd be better off
> explicitly explaining what to do.
> 
> Thanks,
> --David
> 
> 
> 4.1.4 Affected tasks shared across Legacy & FastAbort sessions
> If an iSCSI target implementation is capable of supporting 
> TaskReporting=FastAbort functionality (section 9.1), it may 
> end up in a situation where some sessions have 
> TaskReporting=Legacy operational (Legacy sessions) while some 
> other sessions have TaskReporting=FastAbort operational 
> (FastAbort sessions) even while accessing a shared set of 
> affected tasks (section 4.1.1).
> 
> If the issuing session is a Legacy session, iSCSI target 
> implementation is FastAbort-capable and third-party affected 
> session is a FastAbort session, the following behavior SHOULD 
> be exhibited by the iSCSI target layer:
> a. Between steps c and d of target behavior in section 4.1.2, 
> send an Asynchronous Message PDU with AsyncEvent=5 (section 
> 8.1) on each connection of each third-party session to which 
> at least one affected task is allegiant.  If there are 
> multiple affected LUs, then send one Async Message PDU for 
> each such LU on each connection that has at least one 
> allegiant affected task.  When sent, the LUN field in the 
> Asynchronous Message PDU MUST be set to match the LUN for 
> each such LU.
> b. After step e of target behavior in section 4.1.2, free up 
> the affected TTTs (and STags, if applicable) and the 
> corresponding buffers, if any, once each associated Nop-Out 
> acknowledgement is received that the third-party initiator 
> generated in response to each Async Message sent in step a.
> 
> If the issuing session is a FastAbort session, iSCSI target 
> implementation is FastAbort-capable and third-party affected 
> session is a Legacy session, the following behavior MUST be 
> exhibited by the iSCSI target layer: Asynchronous Message 
> PDUs MUST NOT be sent on the third-party session to prompt 
> the FastAbort behavior.
> 
> 
>  
> ______________________________________________________________
> ______________________
> It's here! Your new message!  
> Get new email alerts with the free Yahoo! Toolbar.
> http://tools.search.yahoo.com/toolbar/features/mail/
> 
> _______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 

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