Subject: RE: CmdSN during login

From: "Julian Satran" <[email-masked]>
Date: Tue, 14 Aug 2001 09:08:40 +0300

I can see scenarios in which you would want the login request  be regular -
as when you issue it after
a task management clear LU or reset command and want to make sure that it
executed after the clear and the CmdSN clearly indicates that.  However
even this effect can be achieved by other means and the discussion is
rather academic - should we mandate the I bit in the login phase (MUST) or
just say that it should be used whenever adequate and explain why (which I
prefer) as it won't be required in all cases (e.g., it is not necessary in
a session establishing login).

Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
@ece.cmu.edu on 13-08-2001 19:34:56

Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
      <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: CmdSN during login

Could commands sent during the login phase (ie LOGIN + TEXT) be mandatory
to
be immediate and therefore MUST have the I bit set or is there a reason why
non-immediate login phase commands make sense?

Cheers

Matthew Burbridge

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Saturday, August 11, 2001 4:37 PM
To: [email-masked]
Subject: Re: CmdSN during login

There was ambiguity at first login that we have cleared in text and as I
said I don't see any good reason
for another case of immediate when we have the immediate bit available.
What we could do is add anothe pragraph to 8
recommending when to use the I bit in login.

Julo

"Eddy Quicksall" <[email-masked]> on 10-08-2001 18:13:32

Please respond to "Eddy Quicksall" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <[email-masked]>
Subject:  Re: CmdSN during login

But, what if someone does this without setting the Immediate bit? What
would
one do?

What is wrong with just making the CmdSN not run during login? It seems
like
it was an arbitrary choice in the first place since it was originally
optional and not using it actually worked.

If CmdSN is stated as only used in FFP, then I don't see any ambiguity.

Eddy
----- Original Message -----
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 10, 2001 2:43 AM
Subject: Re: CmdSN during login

>
> Sanjay,
>
> If you want to ignore CmdSN and expedite Login processing you can do so
by
> having the commands being issued as immediate.
> This will help us keep away from creating ambiguity about (or another
> conditional) for when CmdSN is to be used or not.
>
> Julo
>
> Mark Bakke <[email-masked]>@ece.cmu.edu on 09-08-2001 23:55:25
>
> Please respond to Mark Bakke <[email-masked]>
>
> Sent by:  [email-masked]
>
>
> To:   Sanjay Goyal <[email-masked]>
> cc:   "Ips (E-mail)" <[email-masked]>
> Subject:  Re: CmdSN during login
>
>
>
>
> Sanjay-
>
> I absolutely agree with this; CmdSN is owned by the session, and
> should not be used until the connection has fully joined the session,
> which means full feature phase.
>
> This should also clean up any ambiguity on when to start
> using CmdSN.
>
> --
> Mark
>
> Sanjay Goyal wrote:
> >
> > Hi
> >
> >  Assuming Target and Initiator support multiple connections and the
> session
> > is having multiple connections. Assuming out-of-order CmdSN is a
> possibility
> > for this session.
> >
> >  Connection #   1       |       2       |       3
> > -------------------------------------------------------
> > Login Cmd  CmdSN=0      |   CmdSN=8     |  CmdSN=9
> > Txt   Cmd  CmdSN=1      |               |
> >                                 |               |
> >                                 |               |
> > Login Cmd  CmdSN=7      |  CmdSN=10     |  CmdSN=11
> > -------------------------------------------------------
> > Data Cmd   CmdSN=12     | CmdSN=14      | CmdSN=15
> > Data Cmd   CmdSN=13     |               |
> >                                 |               |
> >
> > CmdSN=7 is last of the Login sequence and it is acknowledged by the
> Target
> > with "accept login" response.
> >
> > Target would receive the PDUs in this CmdSN order
> >  0 to 7, 8, 9, 12, 10, 11, 13, 14, 15
> >
> > Now as Login and Text PDUs are being processed even though you have
> received
> > Data Cmd PDUs, you can not pass them to iSCSI layer and hence you are
> adding
> > latency.
> >
> > What I want to convey from this example is why not use CmdSN just
during
> the
> > FullFeature phase only.
> > Regards
> > Sanjay Goyal
--------------------------------------------------------------------------
--------------------------
>
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054
>
>
>
>

---

From: Mark Bakke <[email-masked]>
Date: Tue, 14 Aug 2001 09:45:15 -0500

Julian-

What are the specific scenarios where this would happen?  My
assumption has been that there is exactly one login exchange
when a connection is established, and if a connection is logged
out for some reason, that connection is destroyed.  To do
another login, a new connection would have to be created.  If
a connection is joining a session already in progress, how
would it make any difference if task management commands were
happening in full feature phase within other connections on
the session?  Why would the login have to wait?  You mentioned
that there were other ways to handle this.  Can we settle on
using the "other ways" instead?

I do think that your suggestion of mandating the I bit set
during login and negotiation would work; if the I bit is set,
the CmdSN is ignored and can be set to anything (I'd prefer
zero).  This effectively means that CmdSN does not start
incrementing until full feature phase, which is what we wanted,
but is still in the login and text command format "just in case"
it's needed at some other time.

However, I would like to strongly word this such that the login
and negotiation phases always set the I bit, send CmdSN=0, and
ignore CmdSN on receive, until full feature phase is started.
I think that a statement like "use whenever adequate" is too
weak and ambiguous.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Ken Sandars" <[email-masked]>
Date: Tue, 14 Aug 2001 17:15:44 +0100

Gidday,

Please read these inline comments standing on your head as they are
coming from an Australian ;-) ....

----- Original Message -----
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 14, 2001 7:08 AM
Subject: RE: CmdSN during login

> even this effect can be achieved by other means

Yes - like waiting for the Task Management response before issuing the
login.

>and the discussion is

Yes. Consider this as a guide. "Until a connection has reached Full Feature
Phase, it is not a member of the session it is either trying to create or
join." As such, there seems no point in regulating the flow of Login Phase
commands with respect to the session context.

> a session establishing login).

By all means, but ONLY if those circumstances can be spelled out in black
and white. Leaving things open to interpretation leads to inconsistent
handling
between implementations. I haven't seen any scenarios yet, and until one is
presented, please rule it out.

Thanks,

Ken Sandars
[email-masked]
Eurologic Systems
+44 117 930 9616