Re: iSCSI state transitions

["Mallikarjun C." <cbm@rose.hp.com>]

Sandeep,

I think #2 below is closed.  

I have an open mind on #1, since it is rather subjective. 
My only observation was that none of the reviewers including the 
ERT (and several other colleagues) - found it an issue so far. 
If more reviewers think it needs to be separated - I can split
it (I will try it anyway to see how it shapes up, but probably 
not before London).  

#3 is where I have a problem.  IMHO, a seemingly simple solution of 
dropping XPT_* states is a bad idea since presence/absence of a valid
transport connection is obviously, inherently part of the "state" of 
the iSCSI connection record! I strongly believe that, contrary to your
opinion, having these states increases the ease of understanding of 
the iSCSI state diagrams, NOT decrease it.  It is easier to assume that 
transport connections get created "on the fly"/"on the transition", but 
that's only good for explaining, not for implementation - as I 
clearly explained below in my response.  

Ofcourse, comments from others are also appreciated.

Regards.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com

>Ok.. here is what I had in mind before I saw the new state diagram.
>
>This is probably not detailing all the events/actions but I sincerely
>think the current 14-state machine probably wont make it as-is 
>into most implementations (i.e. it will get ignored by the 
>silent majority - overspecification creates the same result as
>underspecification)
>
>To respond to all the comments below :
>
>1) You are right, the states for target & initiator may be
>   the same but the transitions events are different.  
>   Separating the diagrams will make it *much* easier to read.
>   See Barry's (Reinhold) login phase diagrams for a good example.
>  
>2) State S13-BUSY can get confused with full-feature phase.
>   RECOVERY_START sounds like a better name.  
>
>3) As regards TCP-related state, I think we are talking of nested
>   state machines.  From my limited knowledge of VHDL, I think
>   these would become nested entities in a design hierarchy with
>   their own state machines - the iSCSI state machine would be
>   blocked until the TCP state machine comes back with a new
>   connection and then enable the READY/GRANT signal or whatever.
>   I still dont think the TCP state needs to show up in iSCSI 
>   connection state - it may be correct but it does not seem necessary.
>
>regards,
>-Sandeep
>
>"Mallikarjun C." wrote:
>> 
>> Sandeep,
>> 
>> Thanks for the comments.
>> 
>> >pages 5-6 look good
>> >but pages 1-4 have a high information density.
>> >(Uneasy rests the eye which traces the transitions..)
>> 
>> Not sure what's implied above....
>> 
>> I was merely trying to keep the pdf file small.
>> 
>> >I suspect the primary problem is that the initiator and
>> >target connection state diagrams have got combined into
>> >one diagram.
>> 
>> Depends on the viewpoint.  Out of 30 transitions, 7 are
>> role-specific, rest are role-agnostic - that is 76.6% are
>> the same.  I consider duplicating >75% in two separate diagrams
>> as unnecessary.  Besides, 100% of the transitions are the same
>> for both roles in both connection recovery and session state
>> diagrams.  While this hasn't been a "problem" for any of the
>> reviewers so far, let us wait for more comments.
>> 
>> >State S13 should be called "suspended" or "to_be_recovered"
>> >  The tasks are undoubtedly "busy" but the connection is
>> >  certainly suspended.
>> 
>> I am not that certain.  The connection state machine is simply
>> entering into the recovery state diagram, S13 is _not_ a suspended
>> dead end.  When in S13, CSM-R is actively counting time to
>> possibly take transition M1 to get to R3.
>> 
>> Would RECOVERY_START be a better name than BUSY?
>> 
>> > We seem to be tracking the TCP state (S2, S12 for SYN,FIN)
>> >  It adds to the complexity and sidetracks one
>> >  from the main purpose, which (i thought) was to document
>> >  error recovery.
>> 
>> Sorry, not true - section 6 goes beyond error recovery(section 7).
>> As stated in the preface, these document the entire life of the
>> iSCSI connection and iSCSI session.
>> 
>> At the iSCSI level, we have to clearly specify how iSCSI state
>> machines react to transport connection events, since an implementation
>> must deal with those.  Section 1.2.6 clearly lays out how to deal with
>> transport connection termination events for the same reason.
>> 
>> >Assume that connection
>> >  establishment and destruction is an action on transition
>> ..
>> >  On error, the connection will be closed and the state can be
>> >  restored to S1 in one step.
>> 
>> These state diagrams are hoped to be implementable "as is".
>> In reality, connection establishment is not atomic - an iSCSI
>> driver/ASIC has to send a connect request and wait for the
>> result, S2 represents the state of the iSCSI connection record
>> during that time.  Similar comments apply for connection
>> termination.
>> 
>> Regards.
>> --
>> Mallikarjun
>> 
>> Mallikarjun Chadalapaka
>> Networked Storage Architecture
>> Network Storage Solutions Organization
>> MS 5668 Hewlett-Packard, Roseville.
>> cbm@rose.hp.com
>> 
>> >Mallikarjun,
>> >
>> >Just a few comments on this.. pages 5-6 look good
>> >but pages 1-4 have a high information density.
>> >(Uneasy rests the eye which traces the transitions..)
>> >
>> >I suspect the primary problem is that the initiator and
>> >target connection state diagrams have got combined into
>> >one diagram.  As a result, most states as well as transitions
>> >have got special-cased as initiator-only or target-only.
>> >
>> >(For example, T1, T2, T3, T7, T15 are all initiator-only)
>> >
>> >Other points:
>> >a) State S13 should be called "suspended" or "to_be_recovered"
>> >  The tasks are undoubtedly "busy" but the connection is
>> >  certainly suspended.  The state name must reflect the state
>> >  of the connection, not the individual tasks.
>> >
>> >b) We seem to be tracking the TCP state (S2, S12 for SYN,FIN)
>> >  It adds to the complexity and sidetracks one
>> >  from the main purpose, which (i thought) was to document
>> >  error recovery.   If we remove the TCP state tracking, we
>> >  may be be able to eliminate some states (S2, S12, etc)
>> >  and keep the focus on iSCSI.  Assume that connection
>> >  establishment and destruction is an action on transition,
>> >  not a whole new state to document.
>> >
>> >c) Transitions T7, T8 can be removed. How individual implementations
>> >  behave on login errors (do a retry/bailout) need not be covered.
>> >  On error, the connection will be closed and the state can be
>> >  restored to S1 in one step.
>> >
>> >All in all, it should be possible to express the connection state
>> >for each end (with error recovery) in about 7-8 states.
>> >
>> >The following patterns would then be easy to spot:
>> >1) There is one way to move from FREE to LOGGED_IN
>> >2) There are four ways to move from LOGGED_IN to FREE
>> >   a) by self-initiated logout
>> >         -target sends Async
>> >         -initiator sends Logout command
>> >   b) by "other-end" requested logout
>> >         -target receives a Logout command
>> >         -initiator receives an Async message
>> >   c) a transport failure followed by connection recovery failure
>> >         which indicates a need to abort tasks.
>> >   d) a transport failure followed by connection recovery success
>> >         which indicates a clean shutdown.
>> >
>> >regards,
>> >-Sandeep
>> >
>> >
>> >"Mallikarjun C." wrote:
>> >>
>> >> All:
>> >>
>> >> Excuse my posting of the (relatively small sized, 27KB)
>> >> pdf file with the iSCSI state diagrams.  I'll post a URL
>> >> shortly, but I wanted to get this out sooner to give
>> >> reviewers a graphical description of rev07, section 6.
>> >>
>> >> This was reviewed in the ERT forum, and the ASCII versions
>> >> of this slide set were incorporated into rev07.
>> >>
>> >> Mallikarjun
>> >>
>> >> Mallikarjun Chadalapaka
>> >> Networked Storage Architecture
>> >> Network Storage Solutions Organization
>> >> Hewlett-Packard, Roseville
>> >> cbm@rose.hp.com
>> >>
>> >>   ------------------------------------------------------------------------
>> >>                               Name: iscsi_states.pdf
>> >>    iscsi_states.pdf           Type: Portable Document Format (application/pdf)
>> >>                           Encoding: base64
>> >>                    Download Status: Not downloaded with message
>> >
>