RE: iSCSI: new state diagrams for rev09

[Black_David@emc.com]

Oops, "A bit tardy" refers to me taking a week to get
this message out, not to the time taken to produce these
diagrams.  Apologies for any confusion.  --David

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Friday, November 09, 2001 10:29 PM
> To: cbm@rose.hp.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: new state diagrams for rev09
> 
> 
> A bit tardy, but I'd like to thank everyone whose efforts
> have contributed to these diagrams and explanations.  Getting
> error behavior completely specified is not easy, and very
> important to the overall specification of iSCSI.  Keep up
> the good work.
> 
> Many Thanks,
> --David 
> 
> > -----Original Message-----
> > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> > Sent: Friday, November 02, 2001 1:33 PM
> > To: ips
> > Subject: iSCSI: new state diagrams for rev09
> > 
> > 
> > All:
> > 
> > Consequent to the feedback I received both online and
> > offline, iSCSI state diagrams are considerably revamped.
> > Thanks to all those who provided the feedback.  The new
> > state diagrams are posted at:
> > 
> > 	http://storage-arch.hp.com/iscsi_states_rev09.pdf
> > 
> > The ASCII forms of the above are currently part of rev 08-90
> > draft that Julian posted on his web.
> > 
> > The major changes are -
> > 
> > - The initiator and target state machines are split for 
> >   both standard connection diagram and session state 
> >   diagram.  It is hoped that this separation makes it
> >   easier to follow.
> > 
> > - Several (informative, but) non-essential states were
> >   eliminated, since they were waiting for internal events 
> >   (like acquiring resources) that are likely non-existent 
> >   in good implementations.  That leaves us with a 7-state
> >   machine for both initiator and target.
> > 
> > - The reduction of states has a salutary effect on the ASCII
> >   representation.  I was able to translate all the diagrams
> >   into ASCII!
> > 
> > - The state descriptions are more descriptive now, specifically
> >   calling out the event(s) that the state machine is waiting 
> >   for in that state.
> > 
> > - The transition descriptions are also more descriptive,
> >   listing the set of events that causes the given transition
> >   for each of the roles.
> > 
> > - The "connection recovery state diagram" has been renamed 
> >   as "connection cleanup state diagram" since the word "recovery"
> >   was inadvertently overloaded.  Connection recovery (the 
> >   act of reassigning the task allegiance to a different connection)
> >   happens outside the scope of this state machine depending on
> >   the operational ErrorRecoveryLevel - all this diagram
> >   specifies is the dynamics of gracefully closing an active 
> >   iSCSI connection, perhaps replacing with a new connection.
> > 
> > - Consequent to the above and for general clarity, some 
> >   states have been renamed to reflect the "wait reason" better.
> > 
> > - Certain missing/incorrect transitions are now fixed -
> >   like the "close the session" Logout handling etc.
> > 
> > - I added some text on the first slide that describes the
> >   design philosophy behind the current model, perhaps also 
> >   can be called design assumptions.
> > 
> > 
> > I have only one (likely) open issue on my list.  I received
> > feedback from one reviewer that the _description_ of the diagrams 
> > is not "traditional" - for example, the current tabular format 
> > captures the transitions (each caused by a set of events) in 
> > a state-state matrix, but does not describe them in terms of 
> > an event-state matrix for each state (which would run into 
> > several pages).  The current description scheme seemed quite 
> > acceptable to myself (and also to Julian among others) - but 
> > I am open on this.  Please comment if you strongly feel about 
> > this issue.
> > 
> > Thanks! 
> > -- 
> > Mallikarjun 
> > 
> > 
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > MS 5668	Hewlett-Packard, Roseville.
> > cbm@rose.hp.com
> > 
>