Subject: RE: [Ips] session re-instatement

From: "Carlos Rimola" <[email-masked]>
Date: Sun, 4 Mar 2007 18:44:22 -0800

I believe Ken explains it well though you need to have a good
understanding of exactly when the state transitions take place.  The
actual session reinstatement should not take place until precisely the
moment that the new session reaches full feature phase.  At that point,
the original (now reinstated session) should reach FREE state and *it*,
together with all of its resources can be freed.  That is, after
*safely* having moved those resources to the new session (yes, using a
safe, including SMP, mutual exclusion mechanism).

Carlos

Carlos Rimola
Sr. Principal Software Engineer
Symantec - Next Generation Storage
Tel.: 650-527-450From [email-masked] Sun Mar 04 21:44:54 2007
Content-class: urn:content-classes:message
Subject: RE: [Ips] session re-instatement
Date: Sun, 4 Mar 2007 18:44:22 -0800
From: "Carlos Rimola" <[email-masked]>
To: "Sandars, Ken" <[email-masked]>,
	"Paul Hughes" <[email-masked]>,
	"IP Storage Mailing List \(E-mail\)" <[email-masked]>
Cc: 

This is a multi-part message in MIME format.
I believe Ken explains it well though you need to have a good
understanding of exactly when the state transitions take place.  The
actual session reinstatement should not take place until precisely the
moment that the new session reaches full feature phase.  At that point,
the original (now reinstated session) should reach FREE state and *it*,
together with all of its resources can be freed.  That is, after
*safely* having moved those resources to the new session (yes, using a
safe, including SMP, mutual exclusion mechanism).

Carlos

Carlos Rimola
Sr. Principal Software Engineer
Symantec - Next Generation Storage
Tel.: 650-527-4505
Cell: 408-858-5548

________________________________

From: Sandars, Ken [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 6:26 PM
To: Paul Hughes; IP Storage Mailing List (E-mail)
Subject: RE: [Ips] session re-instatement

Hi Paul,

Section 5.3.5 [RFC3720] para 2 states:

	The initiator session state MUST be FAILED (Section 7.3 Session
State Diagrams) when the initiator attempts a session reinstatement.

In your scenario the initiator violates this rule since both are in
state FREE (Q1).

The part of your question explores what happens at the target if this
scenario does occur.

The connection and session state machines for the target show that the
session begins life in the ACTIVE state (Q2) when the login phase of the
leading connection starts (S4). Once the leading connection transits
(T5) to LOGGED_IN (S5), the session performs the equivalent transit (N2)
to LOGGED_IN(Q3).

In your scenario, there are two new sessions in ACTIVE state, racing
towards LOGGED_IN. A sensible target implementation waits until a
connection makes the T5 transition (corresponding to the session's N2
transition) before enacting the session reinstatement action. Afterall,
it would be a shame to nuke a potentially viable session with a dodgy
login attempt.

Some sort of implementation-specific mutual exclusion mechanism must be
used on the target to ensure only one party manipulates the session
state. Hence one connection reaches the T5 transition point and runs the
session reinstatement algorithm.

At this point the other session is in Q2 and its connection is in S4
(albeit on the cusp of its transition). While not listed as a T7 reason,
I'd think a resilient target would take that action on the connection.
The session would make the N9 transition (again, not explicitly listed
as a reason, but follows as a consequence of the T7 transit).

In other words, the first one to reach full feature phase survives and
the other gets trashed. Sound fair?

Cheers

Ken

________________________________

From: Paul Hughes [mailto:[email-masked]] 
Sent: Tuesday, 27 February 2007 03:23
To: IP Storage Mailing List (E-mail)
Subject: [Ips] session re-instatement

Is there any text in RFC 3720 or the implementer's guide that prevents
an initiator from simultaneously logging-in on two connections to the
same target portal using the same InitiatorName, ISID, and TSIH=0?  If
the logins were done sequentially, the second login would re-instate the
session created by the first login, but I can see how a target might not
do session re-instatement if the sessions are being created
simultaneously.

Thanks, 
Paul 

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

---

From: "Carlos Rimo width=3D"100%" align=3Dcenter tabIndex=3D-1>
Date: Sun, 4 Mar 2007 18:44:22 -0800

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> Paul
Hughes [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, 27 =
February 2007
03:23<br>
<b><span style=3D'font-weight:bold'>To:</span></b> IP Storage Mailing =
List
(E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Ips] session
re-instatement</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><!-- Converted from =
text/rtf format -->Is
there any text in RFC 3720 or the implementer's guide that prevents an
initiator from simultaneously logging-in on two connections to the same =
target
portal using the same InitiatorName, ISID, and TSIH=3D0?&nbsp; If the =
logins were
done sequentially, the second login would re-instate the session created =
by the
first login, but I can see how a target might not do session =
re-instatement if
the sessions are being created =
simultaneously.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Thanks,</span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Paul</span></font>
<o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C75ED0.2E55C06E--

--===============1620369389==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1620369389==--

---

From: "Carlos Rimola" <[email-masked]>
Date: Sun, 4 Mar 2007 18:44:22 -0800

You may have asynchronous events or I/O activity still taking place on
the failed session, it may help you to have a flag or a state that marks
that session as being in reinstatement.  Depending on your
implementation, this may help you avoid taking action on an event that
that no longer applicable nor has a chance of success on a failed
session.  

You may even keep an internal pointer to the session block/state that is
supplanting the failed session.

The key thing to marking the session as failed is to avoid race
conditions between the failed session and the spanking new session that
is about to replace it..

Carlos

[ formerly at Silverback Systems, iSCSI pioneers.. :) ]

Carlos Rimola

From: Eddy Quicksall [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 8:15 AM
To: Sandars, Ken; Paul Hughes; IP Storage Mailing List (E-mail)
Subject: Re: [Ips] session re-instatement

I think the correct way is what Ken says. In simple terms don't put the
reinstatement logic in the place where you receive the first PDU;
instead let it go through the full login and when that is finished check
to see if this is a reinstatement. Temporarily you will have two
sessions that will appear to conflict but before you go to FFP you will
resolve the problem and end up with only one session.

	----- Original Message ----- 

	From: Sandars, Ken <mailto:[email-masked]>  

	To: Paul Hughes <mailto:[email-masked]>  ; IP Storage
Mailing List (E-mail) <mailto:[email-masked]>  

	Sent: Monday, February 26, 2007 9:26 PM

	Hi Paul,

		The initiator session state MUST be FAILED (Section 7.3
Session State Diagrams) when the initiator attempts a session
reinstatement.

	In your scenario the initiator violates this rule since both are
in state FREE (Q1).

	The part of your question explores what happens at the target if
this scenario does occur.

	The connection and session state machines for the target show
that the session begins life in the ACTIVE state (Q2) when the login
phase of the leading connection starts (S4). Once the leading connection
transits (T5) to LOGGED_IN (S5), the session performs the equivalent
transit (N2) to LOGGED_IN(Q3).

	In your scenario, there are two new sessions in ACTIVE state,
racing towards LOGGED_IN. A sensible target implementation waits until a
connection makes the T5 transition (corresponding to the session's N2
transition) before enacting the session reinstatement action. Afterall,
it would be a shame to nukla" <[email-masked]>
To: "Eddy Quicksall" <[email-masked]>,
	"Sandars, Ken" <[email-masked]>,
	"Paul Hughes" <[email-masked]>,
	"IP Storage Mailing List \(E-mail\)" <[email-masked]>
Cc: 

This is a multi-part message in MIME format.
You may have asynchronous events or I/O activity still taking place on
the failed session, it may help you to have a flag or a state that marks
that session as being in reinstatement.  Depending on your
implementation, this may help you avoid taking action on an event that
that no longer applicable nor has a chance of success on a failed
session.  

You may even keep an internal pointer to the session block/state that is
supplanting the failed session.

The key thing to marking the session as failed is to avoid race
conditions between the failed session and the spanking new session that
is about to replace it..

Carlos

[ formerly at Silverback Systems, iSCSI pioneers.. :) ]

Carlos Rimola

From: Eddy Quicksall [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 8:15 AM
To: Sandars, Ken; Paul Hughes; IP Storage Mailing List (E-mail)
Subject: Re: [Ips] session re-instatement

I think the correct way is what Ken says. In simple terms don't put the
reinstatement logic in the place where you receive the first PDU;
instead let it go through the full login and when that is finished check
to see if this is a reinstatement. Temporarily you will have two
sessions that will appear to conflict but before you go to FFP you will
resolve the problem and end up with only one session.

	----- Original Message ----- 

	From: Sandars, Ken <mailto:[email-masked]>  

	To: Paul Hughes <mailto:[email-masked]>  ; IP Storage
Mailing List (E-mail) <mailto:[email-masked]>  

	Sent: Monday, February 26, 2007 9:26 PM

	Hi Paul,

		The initiator session state MUST be FAILED (Section 7.3
Session State Diagrams) when the initiator attempts a session
reinstatement.

	In your scenario the initiator violates this rule since both are
in state FREE (Q1).

	The part of your question explores what happens at the target if
this scenario does occur.

	The connection and session state machines for the target show
that the session begins life in the ACTIVE state (Q2) when the login
phase of the leading connection starts (S4). Once the leading connection
transits (T5) to LOGGED_IN (S5), the session performs the equivalent
transit (N2) to LOGGED_IN(Q3).

	In your scenario, there are two new sessions in ACTIVE state,
racing towards LOGGED_IN. A sensible target implementation waits until a
connection makes the T5 transition (corresponding to the session's N2
transition) before enacting the session reinstatement action. Afterall,
it would be a shame to nuke a potentially viable session with a dodgy
login attempt.

	Some sort of implementation-specific mutual exclusion mechanism
must be used on the target to ensure only one party manipulates the
session state. Hence one connection reaches the T5 transition point and
runs the session reinstatement algorithm.

	At this point the other session is in Q2 and its connection is
in S4 (albeit on the cusp of its transition). While not listed as a T7
reason, I'd think a resilient target would take that action on the
connection. The session would make the N9 transition (again, not
explicitly listed as a reason, but follows as a consequence of the T7
transit).

	In other words, the first one to reach full feature phase
survives and the other gets trashed. Sound fair?

	Cheers

	Ken

	Is there any text in RFC 3720 or the implementer's guide that
prevents an initiator from simultaneously logging-in on two connections
to the same target portal using the same InitiatorName, ISID, and
TSIH=0?  If the logins were done sequentially, the second login would
re-instate the session created by the first login, but I can see how a
target might not do session re-instatement if the sessions are being
created simultaneously.

	Thanks, 
	Paul