Re: [storm] SPC-2 reserve/release: Proposed text - version 4

["Black, David" <[e-mail]>]

Fred,

> I don't see anywhere that these timers are associated with any SCSI state, or
> with the RESERVE state.  Attempting to tie RESERVE state to these timers is a
> NEW requirement.  Our goal here was specifically to NOT create any new
> requirements.

I think you have a point that this is too specific.  What if we just delete
mention of those timers?  The bullet in question could then simply say:

  - When connection failure causes the iSCSI session to fail, and
      the session is not reinstated or continued, target retention
      of that session's reserve/release reservation state for an
      extended period of time may require the initiator to issue a
      reset (e.g., LOGICAL UNIT RESET, see section 11.5) in order
      to remove that reservation state.

That captures the primary concern that I wanted to alert implementers to.

> We do not want to impact existing iSCSI implementations.  Could we associate
> the action that occurred with the observable behavior the host sees?  I don't
> like putting SCSI layer stuff in a transport layer spec, but it should just be
> informative.

The text that follows explicitly lists the SCSI ASC/Q values (e.g., 29/07, in
hex).  That's something I'd prefer to avoid, e.g., as T10 could easily add
additional ASC/Q values that are relevant to this situation.

As an alternative, I suggest that we state the principle and point to SAM-4
for the details, e.g., add the following text to the end of 4.4.3.1:

   The specific Unit Attention condition that results from session
   re-establishment indicates whether or not nexus state was preserved,
   see Section 6.3.4 of [SAM4].

Would that be ok?

Thanks,
--David

> -----Original Message-----
> From: Knight, Frederick [mailto:[e-mail]]
> Sent: Wednesday, September 26, 2012 8:39 AM
> To: Mallikarjun Chadalapaka; Black, David; [e-mail]
> Subject: RE: SPC-2 reserve/release: Proposed text - version 4
>
> I'm concerned about this new link between Time2Wait and RESERVE state.  Such a
> link has not previously existed.  I don't think we should create such a
> linkage.
>
> Section 4.6.3.3 includes:
> .... In addition, the Logout Response indicates how long the target will
> continue to hold resources for recovery (e.g., command execution that
> continues on a new connection)....
>
> This and many other places where Time2Wait and Time2Retain are discussed, the
> points all have to do with command continuation; no mention of I_T state, or
> RESERVE state, or mode pages, or anything else.
>
> Section 7.5 says:
> .... Time2Wait is the initial "respite time" before attempting an
> explicit/implicit Logout for the CID in question or task reassignment for the
> affected tasks (if any)....
>
> Or, task reassignment of affected tasks; with no mention of I_T state.
>
> Section 7.6 ties the termination of tasks to the Time2Wait / Time2Retain
> timers.  Section 11.14.5 makes the same statements about the task termination
> linkage to those timers.
>
> Section 11.15.3 says those timers are "...the minimum amount of time, in
> seconds, to wait before attempting task reassignment.".
>
> Section 8.3 defines Session State.  And there is one sentence that I can find
> in all 345 pages that associates that session state with these timers.  It is
> in section 11.15.4 where it says: If it is the last connection of a session,
> the whole session state is discarded after Time2Retain.
>
> I don't see anywhere that these timers are associated with any SCSI state, or
> with the RESERVE state.  Attempting to tie RESERVE state to these timers is a
> NEW requirement.  Our goal here was specifically to NOT create any new
> requirements.
>
> We do not want to impact existing iSCSI implementations.  Could we associate
> the action that occurred with the observable behavior the host sees?  I don't
> like putting SCSI layer stuff in a transport layer spec, but it should just be
> informative.  Something like:
>
> If the initiator receives a UA: 29/00 or 29/01 or 29/04 then the RESERVE state
> has been lost.  (Maybe 29/04 belongs in a RESERVE state unknown list).
>
> If the initiator receives a UA: 29/07 then the RESERVE state has been
> preserved.
>
> I didn't list 29/02 or 29/03 or 29/05 or 29/06 since I view those as Parallel
> SCSI specific.  We can debate which items belong in which list, but would this
> kind of observable behavior approach be better than a new requirement?  FYI -
> I didn't invent this; I copied it from SAM-5r11 (sub-clause 6.3.4) where it
> states it as a requirement on the target -  that when an I_T NEXUS LOSS event
> occurs, if the state is retained, 29/07 is returned, and if the state is not
> retained, then 29/01 is returned.
>
> We also don't want to create any new requirement now in this consolidated
> draft that conflicts with this SAM-5 text, since we will eventually have to
> comply with SAM-5 and its follow-ons.
>
> Another approach would be to ignore this for the consolidated draft, and force
> it into the iSCSI-SAM draft - which references SAM-4 and SAM-5 where I_T Nexus
> loss is already defined and the above text already exists.
>
>       Fred
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Mallikarjun Chadalapaka
> Sent: Tuesday, September 25, 2012 9:39 PM
> To: Black, David; [e-mail]
> Subject: Re: [storm] SPC-2 reserve/release: Proposed text - version 4
>
> Looks good to me overall. Two minor comments:
>
> 1) For 4.4.3.1, I have replaced the current sentence with the following one
> (instead of the proposed):
>
> That is, it should reinstate the session via iSCSI session reinstatement
> (Section 6.3.5) or continue via session continuation (Section 6.3.6).
>
> 2) For proposed new text, I have tweaked the version 4 sentence below, keeping
> the existing implementations in view:
>
> VERSION 4:
> The Time2Wait and Time2Retain
>       timeout values (see Section 7.55) apply to retention of reserve/release
>       reservation state after iSCSI session failure because that state
>       is part of the I_T Nexus state.
>
> VERSION 5:
> Instead, implementations are strongly encouraged to apply the
>       Time2Wait and Time2Retain timeout values (see Section 7.5)
>       to manage retention of reserve/release reservation state after
>      iSCSI session failure because that state is part of the I_T nexus state.
>
>
> Thanks.
>
> Mallikarjun
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Black, David
> Sent: Tuesday, September 25, 2012 2:39 PM
> To: [e-mail]
> Subject: [storm] FW: SPC-2 reserve/release: Proposed text - version 4
>
> version 4 changes:
>
> More changes for Mallikarjun's comments, mostly a rewrite of the first
> additional caveat bullet.  I've chosen not to reference Annex B of
> SPC-4 as that seems a bit far afield for a SCSI transport standard like iSCSI.
>
> version 3 changes:
>
> Responding to Mallikarjun's comments (plus some more edits) -
>
> > 1) IMHO, opening sentence of "I_T nexus state includes reservation state"
> > is a little too broad,
>
> I removed that sentence, removed I_T Nexus from new section title and tweaked
> the persistent reservation text to talk about state in general as opposed to
> I_T Nexus state in particular.
>
> > 2) Hard reset is not an LU reset - it is either an iSCSI Target Warm
> > Reset, or (more likely) an iSCSI Target Cold Reset. In either case,
> > any of the three resets should clear the reserve/release state.
>
> I removed the word "hard" - as you noted, an LU reset is sufficient to remove
> a reserve/release reservation.
>
> > 3) Should use Time2Retain+Time2Wait, not Default Time2Wait
>
> Brilliant minds think alike - I got to that one in version 2 ;-).
>
> > 4) Session recovery does not necessarily preserve the I_T nexus state
> > (recovery may not occur within Time2Wait+Time2Retain, and may not use
> > the same ISID when it occurs), but session reinstatement and session
> > continuation certainly should.
>
> I changed "session recovery" to "session reinstatement".
>
> > 5) Should articulate the underlying linkage between Time2Retain (an
> > iSCSI concept), and the reserve/release state (a SCSI state).
>
> I believe I also got to that one in version 2.
>
> version 2 changes:
>
> I moved a paragraph break in response to Ralph's comments, and rewrote the
> first additional consideration to reference the connection timeout values in
> general.  I also found some minor problems that need correction in Section
> 4.6.3.3 (see end of this message).
>
> --- version 4 follows ---
>
> <WG chair hat off>
>
> Here's an initial attempt to propose text to deal with the reserve/ release
> topic in the consolidated iSCSI draft.  Please comment, correct, suggest
> edits, etc.
>
> The new text would be a new section 4.4.3.2 that would follow 4.4.3.1:
>
> 4.4.3.1. I_T Nexus State
>
>   Certain nexus relationships contain an explicit state (e.g.,
>   initiator-specific mode pages) that may need to be preserved by
>   the device server [SAM2] in a logical unit through changes or
>   failures in the iSCSI layer (e.g., session failures). In order for
>   that state to be restored, the iSCSI initiator should reestablish
>   its session (re-login) to the same Target Portal Group using the
>   previous ISID. That is, it should perform session recovery as
>   described in Chapter 6. This is because the SCSI initiator port
>   identifier and the SCSI target port identifier (or relative target
>   port) form the datum that the SCSI logical unit device server uses
>   to identify the I_T nexus.
>
> -------------------------------
>
> First, for clarity, the following change should be made in the above 4.4.3.1
> text to better identify the recovery mechanism:
>
> OLD
>   That is, it should perform session recovery as
>   described in Chapter 6.
> NEW
>   That is, it should recover the session via connection
>   reinstatement as described in Section 6.3.4.
> END
>
> I believe that a lower-case "should" remains appropriate for this text.
>
> -----------------------------------
>
> NEW TEXT (second draft):
>
> 4.4.3.2. Reservations
>
>   There are two reservation management methods defined in the SCSI
>   standards, reserve/release reservations, based on the RESERVE and
>   RELEASE commands [SPC2], and persistent reservations, based on the
>   PERSISTENT RESERVE IN and PERSISTENT RESERVE OUT commands [SPC3].
>   Reserve/release reservations are obsolete [SPC3] and SHOULD NOT be
>   used; persistent reservations SHOULD be used instead.
>
>   State for persistent reservations is required to persist
>   through changes and failures at the iSCSI layer that result in
>   I_T Nexus failures, see [SPC3] for details and specific requirements.
>
>   In contrast, [SPC2] does not specify detailed persistence
>   requirements for reserve/release reservation state after an I_T
>   Nexus failure.  Nonetheless, when reserve/release reservations are
>   supported by an iSCSI target, the preferred implementation approach
>   is to preserve reserve/release reservation state as part of the
>   I_T Nexus state for iSCSI session reinstatement (see Section 6.3.5)
>   or session continuation (see Section 6.3.6).
>
>   Two additional caveats apply to reserve/release reservations:
>
>   - When connection failure causes the iSCSI session to fail, and
>       the session is not reinstated or continued, target retention
>       of that session's reserve/release reservation state for an
>       extended period of time may require the initiator to issue a
>       reset (e.g., LOGICAL UNIT RESET, see section 11.5) in order
>       to remove that reservation state.  The Time2Wait and Time2Retain
>       timeout values (see Section 7.55) apply to retention of reserve/release
>       reservation state after iSCSI session failure because that state
>       is part of the I_T Nexus state.  The need for resets in this
>       scenario may be reduced by suitable selection of values for
>       these two timeouts.
>
>   - Reserve/release reservations may not behave as expected when
>       persistent reservations are also used on the same logical unit;
>       see the discussion of "Exceptions to SPC-2 RESERVE and RELEASE
>       behavior" in [SPC4].
>
> -----------------------
>
> Reference impacts: both [SPC2] and [SPC3] need to be normative references, but
> [SPC4] can be an informative reference.
>
> -------------------------
>
> I deliberately used "the preferred iSCSI implementation approach"
> wording for reserve/release reservation state preservation requirements, as
> SPC-2 is vague on this topic and I'm rather uncomfortable with placing a
> requirement as strong as a "SHOULD" on an obsolete mechanism that "SHOULD NOT"
> be used.
>
> ---------------
>
> New problem in Section 4.6.3.3 - in this text:
>
>    The Logout response indicates that the connection or session
>    cleanup is completed and no other responses will arrive on the
>    connection (if received on the logging out connection). In
>    addition, the Logout Response indicates how long the target will
>    continue to hold resources for recovery (e.g., command execution
>    that continues on a new connection) in the text key Time2Retain
>    and how long the initiator must wait before proceeding with
>    recovery in the text key Time2Wait.
>
> Time2Wait and Time2Retain are not text keys - they're binary fields in the
> Logout Response PDU.  Two changes are in order:
>       - "text key Time2Retain" -> "Time2Retain field"
>       - "text key Time2Wait" -> "Time2Wait field"
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]              FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm