RE: iSCSI Change - Login phase

["BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>]

Hi Ayman,

If the first command in full feature phase is also immediate then it too
will have the same CmdSN as the login PDUs.  The CmdSN gets "used up" only
with non immediate commands and is incremented for the next non-immediate
command.

Cheers

Matthew

-----Original Message-----
From: Ayman Ghanem [mailto:aghanem@cisco.com]
Sent: Wednesday, September 05, 2001 5:49 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI Change - Login phase


Since all login requests are immediate, the first non-immediate command is
actually the first command in full feature phase. I would suggest changing
the reference to "the next non-immediate command" to be "the first command
in full feature phase". Section 1.1.8 would read:

    CmdSN is the initial command sequence number of a session, and is
    valid on the first login request of the leading connection in a
    session.  This determines the CmdSN used in the first command after
    full feature phase on the session (e.g., if the leading login request
carries
    the CmdSN 123 the first command in full feature phase carries the number
    124 etc.).

-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Mark Bakke
> Sent: Wednesday, September 05, 2001 10:03 AM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI Change - Login phase
>
>
>
> Julian and Matthew-
>
> This is looking good; I have just a few comments:
>
> Julian Satran wrote:
> > 1.1.2     I - Immediate
> >
> >    Login SHOULD be issued as an immediate request (I=1) except for the
> >    leading login phase in which all requests that MUST have I=0.
>
> Did you mean "leading connection"?  If so, the only thing that is
> special about the leading connection is that it needs to communicate
> the initial CmdSN value; there is no reason to use I=0 for the
> login requests themselves.
>
> To make this interoperate easier, I would like to get rid of
> the SHOULD.  How about:
>
>    Login MUST be issued as an immediate request (I=1) except for the
>    leading login request of the leading connection in a session, which
>    MUST have I=0 and a valid CmdSN.
>
> I think that this would be simpler, and still get what we need,
> which is to communicate a CmdSN to start with when we hit full
> feature phase.
>
> > 1.1.8     CmdSN
> >
> >    CmdSN is either the initial command sequence number of a session (for
> >    the first Login of a session - the "leading" login) or the command
> >    sequence number in the command stream (e.g., if the leading login
> >    carries the CmdSN 123 the next non-immediate command carries
> the number
> >    124 etc.).
>
> If we make the above change regarding the Immediate bit, this changes to:
>
>    CmdSN is the initial command sequence number of a session, and is
>    valid on the first login request of the leading connection in a
>    session.  This determines the CmdSN used in the next non-immediate
>    command in the session (e.g., if the leading login request carries
>    the CmdSN 123 the next non-immediate command carries the number
>    124 etc.).
>
>
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>