Subject: [Ips] session re-instatement

From: "Paul Hughes" <[email-masked]>
Date: Mon, 26 Feb 2007 09:22:48 -0700

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: "Sandars, Ken" <[email-masked]>
Date: Mon, 26 Feb 2007 18:26:05 -0800

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

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 27 Feb 2007 11:15:28 -0500

session re-instatementI 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 
  To: Paul Hughes ; IP Storage Mailing List (E-mail) 
  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

------------------------------------------------------------------------------

  Thanks, 
  Paul 

------------------------------------------------------------------------------