RE: session re-instatement

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
Sr. Principal Software Engineer
Symantec - Next Generation Storage
Tel.: 650-527-4505
Cell: 408-858-5548

________________________________

From: Eddy Quicksall [mailto:[email protected]] 
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 protected]>  

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

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

	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 protected]] 
	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 protected]
	https://www1.ietf.org/mailman/listinfo/ips

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