Subject: CmdSN during login

From: Sanjay Goyal <[email-masked]>
Date: Thu, 9 Aug 2001 16:25:22 -0400

Hi

 Assuming Target and Initiator support multiple connections and the session
is having multiple connection. Assuming out-of-order CmdSN is a possibility
for this session.

 Connection #	1	|	2	|	3
-------------------------------------------------------
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9
Login Cmd  CmdSN=  0	|   CmdSN=8	|  CmdSN=9

---

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

Fine. Just use immediate and you are done.  Julo

Sanjay Goyal <[email-masked]>@ece.cmu.edu on 09-08-2001 23:34:58

Please respond to Sanjay Goyal <[email-masked]>

Sent by:  [email-masked]

To:   "Ips (E-mail)" <[email-masked]>
cc:   Sanjay Goyal <[email-masked]>
Subject:  CmdSN during login

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

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 11 Aug 2001 10:20:24 +0300

Mallikarjun,

I do realize that there are cases when the whole of the login sequence have
to be executed "out of order".
There are however cases when the login has to be executed in order (e.g.,
after an abort or after a logoout).
This is why I think that no new mechanism is needed (not considering them
unnumbered by default) and the Immediate command flag will cover all the
needs (together with the "one outstanding command" rule that holds for
login).
The confusion previously quote is when does numbering start and that is
from the first command of the first login.
For the leading login (the one creating a session) having the commands
immediate or not is less relevant as
those are the only commands arriving and no other connection can be
established.

Regards,
Julo

"Mallikarjun C." <[email-masked]>@ece.cmu.edu on 10-08-2001 17:54:38

Please respond to [email-masked]

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

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]

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 <[email-masked]>@ece.cmu.edu on 09-08-2001 23:55:25
>
> Please respond to Mark Bakke <[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
> >
----------------------------------------------------------------------------------------------------

>
> >
> >    Part 1.2    Type: application/ms-tnef
> >            Encoding: base64
>
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 11 Aug 2001 18:36:41 +0300

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]>

cc:   <[email-masked]>

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

by
> > What I want to convey from this example is why not use CmdSN just
during
--------------------------------------------------------------------------
--------------------------

---

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Mon, 13 Aug 2001 17:34:56 +0100

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

Julo

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

by

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 15 Aug 2001 16:28:05 +0300

Mark,

I am uneasy about mandating the I bit instead of recommending it strongly
and I am against recommending for the CmdSN field other values than our
"reference" CmdSN (i.e., your preferred 0).

Consider the following scenario:

Connection1:
I->T c1(lu1)c2(lu1)c3(lu1)c4(lu2)c5(lu2)c6(lu2)Clear-ACA-LU1(#7) c7(lu1)
c8(lu1) c9(lu1)

Command are executed at target but no statuses make it hardly back.
C2 ends in an error that blocks the execution of C3. Clear-LU1 is meant to
clean the error.
No other traffic after the error report makes it back.

Initiator starts connection 2 and issues a login+restart for connection 1

The target sees the following sequence

c1,c2,c3,c4,c5,c6, Login, Clear-LU1(#7), c7, c8, c9

Target not having a reference for the logout/login will probably not
execute Clear-ACA-LU1(#7).

The initiator can now reissue c9,c8,c7,Clear-ACA-LU1 and all will be
dropped (when c7 arrives)  before Clear-ACA-LU1 is executed.

Although this a "legal" sequence and actions are legal (but not optimal) I
am afraid that there are other sequences in which the side effects are
"non-serial" schedules.

Julo

Sent by:  [email-masked]

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

Julian Satran wrote:
>
> 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]>
>
> cc:
> Subject:  RE: CmdSN during login
>

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

---

From: [email-masked]
Date: Wed, 15 Aug 2001 21:28:49 -0400

This seems too clever by half.  If I understand Julian's
example correctly, it looks like a task management command
sent for immediate delivery is being retried on the second
connection.  Retrying a command that was sent for immediate
delivery and hence does not have its own CmdSN sounds difficult;
how is the target supposed to figure out whether the original
was executed?  Clear-ACA is somewhat unique in this fashion
as unintentionally doing it twice is a cause of potential
grief - hence it needs its own CmdSN if it's ever going
to be retried, and I suspect the upshot here is to
RECOMMEND use of a CmdSN and ordered delivery for Clear ACA.

I am completely mystified about why the Login ought to be
ordered with respect to the Clear ACA on the other connection,
as there's no interaction between those two commands.
Retrying the Clear ACA seems preferable, and one then gets
some sort of reasonable interaction between the original
Clear ACA and the retry.

In contrast, I think Julian's original concern about the
LU and Target Resets is misplaced.  If the initiator is
not sure whether the reset occurred, the right thing to
do is open up a new connection and issue a new reset (i.e.,
not a retry of the one from the old connection) using
immediate delivery just to be sure.  A well-placed TCP
RST on the original connection wouldn't hurt either.
Once the target's in a known state, it becomes possible
to resume operations.

Let's keep in mind that we're dealing with error situations
in which correctness is more important than performance,
and hence the inability to issue more commands until things
settle down is acceptable.  I agree with Mark that requiring
immediate delivery on all login commands and text commands
in the login phase seems like the right approach.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> Sent: Wednesday, August 15, 2001 9:28 AM
> To: [email-masked]
> I->T 
> c1(lu1)c2(lu1)c3(lu1)c4(lu2)c5(lu2)c6(lu2)Clear-ACA-LU1(#7) c7(lu1)
> c8(lu1) c9(lu1)
> 
> > 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
> > > >  Assuming Target and Initiator support multiple 
> connections and the
> > > session
> > > > CmdSN=7 is last of the Login sequence and it is 
> acknowledged by the
> > > Target
> > > > What I want to convey from this example is why not use 
> CmdSN just
> > during
> > > the
> > > > FullFeature phase only.
> > > >
> > > > Regards
> > > > Sanjay Goyal
> > > >
> > > >
> > >
> >