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