Subject: Re: CmdSN during login

From: "Julian Satran" <[email-masked]>
Date: Fri, 10 Aug 2001 09:43:26 +0300

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: "Eddy Quicksall" <[email-masked]>
Date: Fri, 10 Aug 2001 11:13:32 -0400

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 10 Aug 2001 07:54:38 -0700

Julian,

I tend to agree with Mark and Sanjay.

In cases where all connections in a session failed and a new
connection is being added to the existing session state (before
the session timeout), an initiator must issue the Login as an
immediate command to avoid the possibility of a deadlock - since
the initiator does not know for sure if target received all commands
on the failed connections.

Since this appears to be a mandatory requirement, I suggest that
we make it the default behavior - that Login PDUs never *consume*
CmdSNs (though the leading login carries a valid "seed" CmdSN), 
including the leading login PDU.  There are no conditionals this way.

Sorry, I can't find the reasoning you offered earlier for rev07 
behavior, in the middle of my travel.  Please comment if I missed
something.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
[email-masked]