Re: iSCSI : target session login behaviour

[Mark Bakke <mbakke@cisco.com>]

Hari-

Although it looks like we didn't explicitly state this in the latest
name-disc draft, we did discuss the splitting of the ISID identifier
space amongst iSCSI HBAs.  We should add a statement like:

All entities (iSCSI HBAs, drivers, hosts in a cluster, whatever) that
share the same Initiator Name MUST coordinate the use of ISIDs amongst
themselves to avoid ISID re-use collisions.

I don't think that's quite the right wording, but anyway, I think that
this helps.

--
Mark

"Mudaliar, Hari" wrote:
> 
> Santosh,
>         I get your point. But what if there is more than one iSCSI Host bus
> adapter in a system? The Initiator Name will be the same and ISID MAY turn
> out to be the same (unless the ISIDs are apportioned between the initiators
> through some configuration method). This assumes that multiple sessions can
> exist between one initiator system (containing multiple iSCSI off-load
> engines/HBAs) and a target.
> 
> - Hari
> 
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Wednesday, April 25, 2001 4:18 PM
> To: Mudaliar, Hari
> Cc: IPS Reflector
> Subject: Re: iSCSI : target session login behaviour
> 
> "Mudaliar, Hari" wrote:
> 
> >         I am assuming that you are referring to the creation of a new
> > session with TSID=0 in your example below. Take the case of an initiator
> I1
> > who has established a session with a target with an ISID=ISID1. What if a
> > second initator I2 tries to login to the same target with ISID1? The
> target
> > cannot decide to logout the first initiator (who already has a session
> > established with ISID1) as suggested by you.
> 
> Hari,
> 
> You may want to take a second look at my mail. It specifically refers to
> the problem in the context of a given (Initiator Name, ISID). Your
> example above does not fall under that category. A 2nd initiator using
> the same ISID would have a different Initiator Name. (a.k.a initiator
> WWUI).
> 
> The problem raised is in the context of an existing session for a given
> (Initiator Name, ISID). How does a target deal with a second session
> login received for the same (Initiator Name, ISID) with a NULL TSID ?
> 
> >         Also, depending on implementation, the target may realize that the
> > TCP connections for a session were lost (using Keep-Alives or iSCSI NOPs
> > etc.) when the initiator rebooted thus terminating the session. By the
> time
> > a new login from the same initiator is received, the old session info may
> > have been cleared.
> 
> Then again, it may not. There's 2 aspects to this issue :
> 1) Successful session re-logins from the rebooted host.
> 2) Garbage collection and cleanup of the old session resources.
> 
> (1) is a more serious issue, since the target MUST NOT reject the login
> based on a pre-existing active session for a given (Initiator Name,
> ISID).
> 
> (2) is handled through garbage collection algorithms, but implementation
> of the proposal would help accelerate the release of stale session
> resources.
> 
> - Santosh
> 
> >
> > -----Original Message-----
> > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > Sent: Wednesday, April 25, 2001 11:19 AM
> > To: IPS Reflector
> > Subject: iSCSI : target session login behaviour
> >
> > All,
> >
> > How should a target respond when it receives a session login  [on a new
> > TCP connection] with the same (ISID, Initiator Name) as a session
> > already active at the target.
> >
> > Does such a login request imply :
> >
> > 1) the target should perform implicit logout and re-login of the session
> > identified by (ISID, initiator name) ?
> >
> > 2) Or does this result in the target responding to the session login
> > with :
> > a login response with status class of non-zero indicating target is
> > rejecting the login ?
> >
> > [The draft does not describe target behaviour for this scenario.]
> >
> > iSCSI session login semantics should explicitly state that the above
> > scenario will result in case (1) above. i.e. when a target sees a
> > session login for a given (ISID, initiator name), it MUST treat this as
> > an implicit logout of any previous session active at the target for that
> > (ISID, initiator name) and then, establish a new session.
> >
> > This is required because the above scenario can typically occur when an
> > initiator reboots without having performed a session logout on all
> > active sessions.(system did not perform an orderly shutdown).
> >
> > As a side note, the iSCSI draft Status Class/Codes could do with a misc
> > error category along the lines of the FC "No additional Explantion"
> > reason explantion. This would help deal with error conditions that don't
> > come under the listed category.
> >
> > - Santosh

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054