Re: CmdSN during login

["Mallikarjun C." <cbm@rose.hp.com>]

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.
cbm@rose.hp.com

Julian Satran wrote:
> 
> 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 <mbakke@cisco.com>@ece.cmu.edu on 09-08-2001 23:55:25
> 
> Please respond to Mark Bakke <mbakke@cisco.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Sanjay Goyal <sanjay_goyal@ivivity.com>
> cc:   "Ips (E-mail)" <ips@ece.cmu.edu>
> 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
> mbakke@cisco.com
> 763.398.1054