Subject: [Ips] iSCSI: reinstatement

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 9 Feb 2004 13:40:43 -0500

When an initiator reinstates a connection/session, it will supply the ExpStatSN and CmdSN in the new login.

I would like to confirm my understanding (ERL 0) ... 

Should the target remember the last StatSN for the lost connection or should it use the initiator's new ExpStatSN for the next StatSN? I am expecting that the target uses the ExpStatSN.

Should the target remember the last ExpCmdSN for the lost session (last lost connection of a session) or should it use the initiator's new CmdSN for the next ExpCmdSN? I am expecting that the target uses the CmdSN.

Eddy

---

From: [email-masked]
Date: Mon, 9 Feb 2004 11:15:49 -0800 (PST)

On Mon, 9 Feb 2004, Eddy Quicksall wrote:

> Should the target remember the last StatSN for the lost connection or
> should it use the initiator's new ExpStatSN for the next StatSN? I am
> expecting that the target uses the ExpStatSN.

>From Login Request:

10.12.9  ExpStatSN

   For the first Login Request on a connection this is ExpStatSN for
   the old connection and this field is only valid if the Login request
   restarts a connection (see Section 5.3.4 Connection Reinstatement).

   For subsequent Login Requests it is used to acknowledge the Login
   Responses with their increasing StatSN values.

And from Login Response:

10.13.4  StatSN

   For the first Login Response (the response to the first Login
   Request), this is the starting status Sequence Number for the
   connection. The next response of any kind, including the next login
   response, if any, in the same Login Phase, will carry this number +
   1. This field is only valid if the Status-Class is 0.

Thus where the StatSN sequence starts is the purvue of the target. Once
it's started (first Login Response on a connection), the StatSN rules
dictate how it changes through the connection.

The target can start each connection with a totally-random number, and
that'd be ok.

> Should the target remember the last ExpCmdSN for the lost session (last
> lost connection of a session) or should it use the initiator's new CmdSN
> for the next ExpCmdSN? I am expecting that the target uses the CmdSN.

I think "10.12.8 CmdSN" covers CmdSN for all cases other than session
reinstatement.

I'm a bit confused about session reinstatement. I _think_ a session
reinstatement connection should be treated as a leading connection, in
which case the target should respect the supplied CmdSN.

The reason I think this is in thinking about what happens if the initiator
suddenly reboots. When it comes up, it won't know it has a session with
the target(*). So it will be performing an "initial login" which looks
like session reinstatement to the target. If this connection isn't treated
as "leading", then the initiator may get confused when it tries to
negotiate some "leading-only" parameters with the target.

(*) Unless we are requiring the initiator remember it had a session, so
then it could know it was doing session-reinstatement.

Am I understanding this correctly?

Take care,

Bill

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 9 Feb 2004 16:12:54 -0500

Yes, I think you are understanding it and I just want to see if everyone
agrees.

Consider ERL 2 session reinstatement. According to 10.12.8, the initiator
would have to keep track of the CmdSN (since the ExpCmdSN will be the
leading login's CmdSN+1). Otherwise the following would be broken. Right? If
the correct CmdSN is not used, the out-of-order commands already in the
target will get stuck and/or new commands will appear "out of the command
window".

----Connection 0
T->I CmdSN=5
I->T ExpCmdSN=6
----Connection 1
T->I CmdSN=7
I->T ExpCmdSN=6
----Both connections are lost
----The initiator would have to use CmdSN=5 for the new leading login.

Eddy

---

From: "Ken Sandars" <[email-masked]>
Date: Tue, 10 Feb 2004 16:01:14 -0000

Hi Eddy & Bill

I reckon Bill has hit the nail on the head. The connection which causes
session reinstatement must have been negotiated as a leading login (TSID
is 0) to a NEW session - it's a fresh start in life. There is a
convenient side-effect where any previous session (from the target's
point of view) on that I-T-nexus gets nuked from outer space (regardless
of ERL).

Cheers,
Kens Sandars
Elipsan UK

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eddy Quicksall
> Sent: 09 February 2004 21:13
> To: [email-masked]
> Cc: [email-masked]
> Yes, I think you are understanding it and I just want to see 
> if everyone agrees.
> 
> Consider ERL 2 session reinstatement. According to 10.12.8, 
> the initiator would have to keep track of the CmdSN (since 
> the ExpCmdSN will be the leading login's CmdSN+1). Otherwise 
> the following would be broken. Right? If the correct CmdSN is 
> not used, the out-of-order commands already in the target 
> will get stuck and/or new commands will appear "out of the 
> command window".
> 
> ----Connection 0
> T->I CmdSN=5
> I->T ExpCmdSN=6
> ----Connection 1
> T->I CmdSN=7
> I->T ExpCmdSN=6
> > > When an initiator reinstates a connection/session, it will supply 
> > > the ExpStatSN and CmdSN in the new login.
> > >
> > > Should the target remember the last StatSN for the lost 
> connection 
> > > or should it use the initiator's new ExpStatSN for the 
> next StatSN? 
> > > I am expecting that the target uses the ExpStatSN.
> >
> > From Login Request:
> >
> > 10.12.9  ExpStatSN
> >
> > Thus where the StatSN sequence starts is the purvue of the target. 
> > Once it's started (first Login Response on a connection), 
> the StatSN 
> > rules dictate how it changes through the connection.
> >
> > > Should the target remember the last ExpCmdSN for the lost session 
> > > (last lost connection of a session) or should it use the 
> initiator's 
> > > new CmdSN for the next ExpCmdSN? I am expecting that the 
> target uses 
> > > the CmdSN.
> >
> > The reason I think this is in thinking about what happens if the 
> > initiator suddenly reboots. When it comes up, it won't know 
> it has a 
> > session with the target(*). So it will be performing an "initial 
> > login" which looks like session reinstatement to the 
> target. If this 
> > connection isn't treated as "leading", then the initiator may get 
> > confused when it tries to negotiate some "leading-only" parameters 
> > with the target.
> >
> > (*) Unless we are requiring the initiator remember it had a 
> session, 
> > so then it could know it was doing session-reinstatement.
> >

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 10 Feb 2004 14:29:19 -0500

Are the commands always terminated at ERL 2?

3.2.7  Persistent State

   Commands persist beyond connection termination if the session
   persists and command recovery within the session is supported.
   However, when a connection is dropped, command execution, as
   perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the
   affected task), is suspended until a new allegiance is established
   by the 'task reassign' task management function. (See Section 10.5
   Task Management Function Request.)

Eddy

----- Original Message ----- 
From: "Ken Sandars" <[email-masked]>
To: "'Eddy Quicksall'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 10, 2004 11:01 AM
Subject: RE: [Ips] iSCSI: reinstatement

---

From: Julian Satran <[email-masked]>
Date: Tue, 10 Feb 2004 12:27:07 -0800

On the contrary - the assumption is that you will reassign within the time 
bounds specified and terminate only if not.

Julo

"Eddy Quicksall" <[email-masked]> 
Sent by: [email-masked]
10/02/2004 11:29

To
"Ken Sandars" <[email-masked]>, <[email-masked]>
cc
<[email-masked]>
Subject
Re: [Ips] iSCSI: reinstatement

3.2.7  Persistent State

Eddy

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 10 Feb 2004 12:45:34 -0800

Eddy,

The critical phrase in the quoted text from 3.2.7
is "if the session persists".  A session reinstatement
wipes out the old session context in its entirety,
i.e. the old instance does not "persist" any longer,
please see 5.3.5.

M

---

From: [email-masked]
Date: Tue, 10 Feb 2004 12:52:12 -0800 (PST)

> bounds specified and terminate only if not.

Just to make sure we're all on the same page: If we're operating at ERL 2,
and we perform session reinstatement, tasks from the old commands stick
around waiting to get re-attached?

I'd have expected that if we're doing session reinstatement, we would just
kill all the old tasks.

Also, since the session-reinstatement connection should be leading, what
happens if ERL gets negotiated to a different value? Say it was ERL 0
before, and now it's ERL 2?

Take care,

Bill

---

From: [email-masked]
Date: Tue, 10 Feb 2004 13:22:38 -0800 (PST)

> I'd have expected that if we're doing session reinstatement, we would just

Ahhh... Mallikarjun cleared this point up. The session doesn't persist
across session reinstatement, thus my concerns are invalid. :-)

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 10 Feb 2004 16:22:35 -0500

Yes, I have seen the statement that says "Session reinstatement causes all
tasks that were active on the old session to be immediately terminated ...".

But that seems to be contradictory to the first sentence of 3.2.7. It seems
3.2.7 is allowing the session to persist; and I'm assuming that means across
a connection failure where the connection is the only one in the session.
Are you simply saying that a session does not persist across a connection
failure?

Also if session reinstatement wipes out the old session context, how can
task reassignment occur under 5.3.4 without session context since that
contains may contain out of order commands that are waiting for ordering?

I am really confused here and may just need an example. Suppose I have two
connections in a session and both connections fail?

Eddy

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 10 Feb 2004 16:30:00 -0500

Maybe I'm reading too much into this... are you really just saying that a
session can't be reinstated? If they can, what about them is reinstated?

Eddy

----- Original Message ----- 
From: <[email-masked]>
To: "Julian Satran" <[email-masked]>
Cc: "Eddy Quicksall" <[email-masked]>;
<[email-masked]>; "Ken Sandars" <[email-masked]>
Sent: Tuesday, February 10, 2004 4:22 PM
Subject: Re: [Ips] iSCSI: reinstatement

---

From: Julian Satran <[email-masked]>
Date: Tue, 10 Feb 2004 13:41:00 -0800

Eddy,

A session persists even across the last connection failure - if you are at 
ERL 2 and you are not exceeding the time limit to reconnect.

Julo

10-02-2004 13:22

To
"Mallikarjun C." <[email-masked]>, <[email-masked]>
cc

Subject

Yes, I have seen the statement that says "Session reinstatement causes all
tasks that were active on the old session to be immediately terminated 
...".

But that seems to be contradictory to the first sentence of 3.2.7. It 
seems
3.2.7 is allowing the session to persist; and I'm assuming that means 
across
a connection failure where the connection is the only one in the session.
Are you simply saying that a session does not persist across a connection
failure?

Eddy