RE: ISCSI: CmdSN in non-leading login

[Eddy Quicksall <eddyq@ivivity.com>]

It seems like the current wording is already clear. Maybe an example would
be appropriate in appendix B.

Eddy

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Friday, May 10, 2002 9:57 PM
To: Mark__S.__Edwards"
<marke@muttsnuts.com/@boulder.ibm.com"@twestrelay04.boulder.ibm.com
Cc: ips@ece.cmu.edu
Subject: Re: ISCSI: CmdSN in non-leading login


I have a correction to the previous note (below).  We removed the Immediate
bit but there is clear statement that "Login requests are always considered
as immediate.".  (This means they always get the next CmdSN but do not
advance the ExpCmdSN.)  The rest of the message is correct, and the
suggested update of the wording, is approprate.  It will not, however,
change the way things work.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com
---------------------- Forwarded by John Hufferd/San Jose/IBM on 05/10/2002
06:49 PM ---------------------------

John Hufferd
05/10/2002 05:38 PM

To:    "Mark S. Edwards" <marke@muttsnuts.com>
cc:    <ips@ece.cmu.edu>
From:  John Hufferd/San Jose/IBM@IBMUS
Subject:    Re: ISCSI: CmdSN in non-leading login  (Document link: John
       Hufferd)

The text as it is written has not been updated since we at one point had
the Login command marked as and Immediate command.  Therefore, it always
had to pick up the next value that would be assigned to the next non
immediate command.  Also since it was an immediate command the ExpCmdSN was
not advanced so it did not effect the commands in the rest of the session.
They would continue with the next CmdSN as usual.  Login is still not
suppose to advance the ExpCmdSN, so there should still not be a problem.

When we removed the flag that said that it was an immediate command, the
wording in the draft about the Initial Login was not adjusted.

I suggest that the only thing that needs to be changed is the following:
At the end of the first paragraph under 9.12.8, we should add, the words
"Similar rules exist for the Leading Login for a non leading connection,
that is, the next CmdSN value is used for the Leading Login of the non
leading connection, and that same number is used with all the subsequent
Login PDUs on that connection. But at completion of the Login of the
connection, the ExpCmdSN is not advanced and the subsequent commands take
the next CmdSN value in the session."

This is what we were all doing, and simply did not change anything with the
Immediate bit was dropped from the Login PDU.  I suggest we leave it with
that operational intent, since it was so long ago that we establish this
way of operating I can not remember exactly why, but would not like to be
surprised sometime in the future, and I do not see why we would have to
change it.




.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 05/10/2002 10:38:07
AM

Sent by:    owner-ips@ece.cmu.edu


To:    John Hufferd/San Jose/IBM@IBMUS
cc:    <ips@ece.cmu.edu>
Subject:    Re: ISCSI: CmdSN in non-leading login



John,

If an initiator opens a new connection on a session and in the first login
request uses the current session CmdSN, the lifetime of that CmdSN
continues all the way through until the completion of the first
non-immediate command on that new connection.

This means that the initiator has to reserve the use of that CmdSN for the
first non-immediate command on that particular session.  That's stupid.

Especially bearing in mind that it could be pumping commands like crazy
down other open connections in the session.

There is also another side effect, if the login takes any length of time,
like computing a DH or having to make external calls to a Radius or a
Kerberos server, then because this CmdSN is outstanding, the other
connections in the session will block as soon as the command window is
filled.

The final sentence in 9.12.8 is meaningless for a non-leading
connection.  The target either has to block the whole session until the
login is completed, or run the risk of corrupting session state.

Mark


At 10:14 AM 5/10/2002 -0700, John Hufferd wrote:

>I do not see the issue, it works as is, it does not effect the first non
>immediate command unless it completes as a authorized connection. Again, I
>do not see the issue, in fact it works as is.
>
>.
>.
>.
>John L. Hufferd
>Senior Technical Staff Member (STSM)
>IBM/SSG San Jose Ca
>Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
>Home Office (408) 997-6136, Cell: (408) 499-9702
>Internet address: hufferd@us.ibm.com
>
>
>"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 05/10/2002 09:47:53
>AM
>
>Sent by:    owner-ips@ece.cmu.edu
>
>
>To:    Bill Studenmund <wrstuden@wasabisystems.com>
>cc:    <ips@ece.cmu.edu>
>Subject:    Re: ISCSI: CmdSN in non-leading login
>
>
>
>At 09:13 AM 5/10/2002 -0700, Bill Studenmund wrote:
> >On Fri, 10 May 2002, Mark S. Edwards wrote:
> >
> > > 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 ?
> >
> >I think the target shouldn't let anything from a new connection
influence
> >things until after at least the security phase has been passed.
Otherwise
> >we have a security hole. After operational negotiation would probably be
> >best.
>
>Good, as far as I can see, a new connection should not be allowed to
>influence any session context until the connection reached full-feature
>phase.  But this is a problem if we have to follow the CmdSN rules of
>9.12.8.   See next comment.
>
>
> > > 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.
> > >
> > > 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.
> > >
> > > I would like to see something along the lines that for a non-leading
> > > connection, the CmdSN field MUST be zero and that the connection can
>not be
> > > considered part of the session until full feature phase is entered,
at
> > > which point any commands issued on the connection are now
synchronised
>with
> > > the session command sequence number as observed by all other existing
> > > connections on the session.
> >
> >I thought login counted as a command, so it got its own command number,
in
> >the stream of all other commands. ??
>
>
>For a leading connection the CmdSN, whether zero or non-zero, is regarded
>as a primer with which to set the initial session command sequence number,
>all the login requests exchanged in the negotiation, no matter how many
>carry the same CmdSN as does the first non-immediate command.  In other
>words, the first pdu in a leading connection does influence session state.
>
>So if we agree that a non-leading connection can not influence session
>state until full-feature phase, then we have to also state that the rule
in
>9.12.8 about the first non-immediate command carrying the same CmdSN as
the
>initial login request can not work for a non-leading connection.  In this
>case, the first non-immediate command must be set from the next logical
>value in the session context.  I would like the spec to have this added
and
>to explicitly say that the CmdSN in a login request for a non-leading
>connection is ignored by the target.  I'd really prefer that the actual
>value be zero, but that's not necessary from a protocol perspective if the
>target ignores the field.
>
>Mark.