Re: iSCSI state transitions

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Ok.. here is what I had in mind before I saw the new state diagram.
 See http://www.bell-labs.com/user/sandeepj/conn.pdf

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
> >