Re: iSCSI state transitions

[Sandeep Joshi <sandeepj@research.bell-labs.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