RE: ISCSI: CmdSN in non-leading login

["Mark S. Edwards" <marke@muttsnuts.com>]

David,


At 02:04 PM 5/10/2002 -0400, Black_David@emc.com wrote:
> > There is a certain ambiguity about 9.12.8.  The text describes how in a
> > leading connection, the target takes must accept and use a non-zero CmdSN,
>
> > but it does not explain what should be present for a non-leading
>connection.
> >
> > There are a couple of problems here for the target.  At what point is a
> > non-leading connection considered to be part of the session ?   Is it the
> > moment that the login request is received with a non-zero TSIH ?  Or is it
>
> > only when the non-leading login succeeds and it enters full feature phase
>?
>
>My recollection is the latter, so a non-leading login carries a CmdSN
>that only applies to that login, and it starts using session-wide CmdSN
>numbering when it enters full-feature phase.  I see the ambiguity in the
>9.12.8 text, and believe the answer is that a non-leading login can use
>any CmdSN it likes, but only for login purposes, and starts using the
>session CmdSN numbering when it enters full-feature phase.

We can live with that.  The text as it stands is applicable only to the 
leading connection, it just needs additional words to describe the more 
limited scope of a CmdSN in a non-leading connection.

> > So, should an initiator set the CmdSN in the first login request to zero
> > and only synchronise with the session command stream after full feature
> > phase is established ?  This is my preferred option.
>
>Synchronization in full feature phase should be required.  Zero should
>be allowed, but not required.  As long as the Initiator chooses the
>number and can use what it wants, Mark's initiators are free to choose
>zero.  Text would need to be added to explain this.

Fine, our target will just echo the CmdSN that the initiator chooses.  All 
we wanted was text to clarify that whatever this value is in a non-leading 
connection is meaningless within the context of the real session CmdSN.


> > What happens if the initiator tries using the current session command
> > sequence number is that whilst the login negotiation occurs, other
> > connections within the session can be issuing new commands, so by the time
>
> > that the login is finished the CmdSN exchanged in the initial request is
> > invalid anyway.
>
>Non-leading login should not affect the session until it enters full-
>feature phase.

That's exactly what I wanted to hear ... over to you Julian :)

Mark.