RE: Single 3-valued key for task reporting

Something to think about on this one.  Following on Julian's concern
about the complexity of fast task abort, one possibility would be to
say, that *if* this key is implemented:
- support for ResponseFence is mandatory
- support for FastTaskAbort is optional
I think the current IG text makes fast task abort support mandatory.

Comments?

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun C. [mailto:[email protected]] 
> Sent: Wednesday, December 27, 2006 11:33 PM
> To: IPS
> Subject: [Ips] Single 3-valued key for task reporting
> 
> Per the email conversation at the bottom of this email, I 
> propose the following text for a new 3-valued key 
> "TaskReporting" that replaces the FastMultiTaskAbort key.  
> Comments are welcome.
> 
> 9.1 TaskReporting
> Use: LO
> Senders: Initiator and Target
> Scope: SW
> Irrelevant when: SessionType=Discovery
> TaskReporting=<list-of-values>
> Default is Legacy.
> Result function is AND.
> This key is used to negotiate the task completion reporting 
> semantics from the SCSI target.  Following table describes 
> the semantics an iSCSI target MUST support for respective 
> negotiated key values.  The Legacy value MUST be offered as 
> an option by negotiation originator.
> +--------------+------------------------------------------+
> | Name       |             Description                  |
> +--------------+------------------------------------------+
> | Legacy    | RFC 3720-compliant semantics.  Response  |
> |                | fencing is not guaranteed and fast       |
> |                | completion of multi-task aborting is not |
> |                | supported                                |
> +--------------+------------------------------------------+
> | ResponseFence| Response Fence (section 3.3.1) semantics |
> |                        | MUST be supported in reporting task      |
> |                        | completions                              |
> +--------------+------------------------------------------+
> | FastAbort   | Updated fast multi-task abort semantics  | 
> |                  | defined in section 4.1.3 MUST be         |
> |                  | supported.  Support for Response Fence is|
> |                  | implied - i.e. section 3.3.1 semantics   |
> |                  | MUST be supported as well                |
> +--------------+------------------------------------------+
> When TaskReporting is not negotiated to FastAbort, The 
> default behavior is to use the [RFC3720] TMF semantics as 
> clarified in section 4.1.2. 
> 
> 
> 
> 
> ----- Original Message ----
> From: "[email protected]" <[email protected]>
> To: [email protected]; [email protected]
> Sent: Monday, December 11, 2006 10:56:02 AM
> Subject: RE: [Ips] Implementer's Guide - Task Management Issue
> 
> 
> Mallikarjun,
> 
> ......
> > The other thing that came to my mind after reading your note 
> > is that we don't currently have a generic key to capture the 
> > Response Fence behavior - although response fencing underlies 
> > both the fast multi-task abort as well as addressing ACA race 
> > conditions (and perhaps others down the road. e.g. around 
> > persistent reservations).  So, today, the Note at the end of 
> > section 3.3.3 advises that implementations may check the 
> > FastMultiTaskAbort key to verify if safe behavior for MCS ACA 
> > is supported, although ACA has really nothing to do with 
> > multi-task aborting.  I am wondering if we should create a 
> > new key (say ResponseFence), so the semantics would become:
> >                                                             
>           
> >        ResponseFence    "Yes"  fencing done by target      
> >                                    "No"   legacy, no fencing 
> > (so "clarified" TMF semantics are not possible either)
> >        
> > With ResponseFence=    "Yes"
> > FastMultiTaskAbort     
> >       "Yes"                   fast abort & fencing              
> >        "No"                    traditional wait on 
> > outstanding TTTs (fencing on ACA is still possible)
> > 
> > With ResponseFence=    "No"
> > FastMultiTaskAbort     
> >       "Yes"                   Illegal, Response Fence must be "Yes"
> >        "No"                    No fencing, must wait on 
> > outstanding TTTs
> >   
> > 
> > The downside of this scheme is that it may be going in the 
> > opposite direction than you wanted (introduces a second key 
> > that 3720-compliant implementations don't know about).  We 
> > could alternatively simply mandate the behavior equivalent to 
> > ResponseFence = "Yes" always and avoid the second key, but 
> > doing so could make the current 3720-compliant 
> > implementations technically non-iSCSI-compliant.
> > 
> > Comments?
> 
> Given the inter-dependence of ResponseFence and FastMultiTaskAbort,
> a single 3-valued key is probably simpler than two boolean keys.
> I think having an explicit means of determining whether ACA behaves
> correctly on an multi-connection-session is worth adding.
> 
> Thanks,
> --David 
> 
> > Mallikarjun
> 
> __________________________________________________
> 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
> 
> 

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