Re: Single 3-valued key for task reporting
"Mallikarjun C." <[email protected]>
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <[email protected]> |
It might be OK, the fact that the new key allows two values (other than Legacy) in itself implies that flexibility. I don't think the current IG text really makes the support mandatory. But let's have more discussion on Julian's concern to see if we can further simplify. Mallikarjun ----- Original Message ---- From: "[email protected]" <[email protected]> To: [email protected]; [email protected] Sent: Thursday, December 28, 2006 12:21:37 PM Subject: RE: [Ips] 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 > > __________________________________________________ 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