Subject: RE: iSCSI: ISIDs

From: [email-masked]
Date: Fri, 7 Sep 2001 10:09:25 -0400

>   >  > 	Without an initiator assigned ISID the target is
>   >  presented with no
>   >  > information with which to distinguish HBAs in a host.
>   >  Assuming that
>   >  > HBA 1 has an existing session, how can the target tell
>   >  the difference
>   >  > between HBA 2 sending a leading login with the intent
>   >  of starting a
>   >  > new session, and HBA 1 sending a leading login after
>   >  an uncontrolled
>   >  > restart?
>   >
>   >  HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the
>   >  session it's
>   >  trying to recover.  Two HBAs are not necessary to create
>   >  this scenario -
>   >  it can occur with two sessions on a single HBA.  If the
>   >  HBA has forgotten
>   >  the identity of the session it's trying to recover, that
>   >  session is
>   >  unrecoverable, but see above comment on differences in
>   >  remembering
>   >  an ISID vs. a TSID.
>   >
> 
> This is where I think we have a problem, if HBA 1 isn't trying to
> recover because it has had an uncontrolled restart it too will send a
> TSID of 0. How then can the target know whether it should clean the
> old session to HBA 1, or open a new session to HBA 2. IP address?

If both HBA 1 and HBA 2 send TSID's of zero, the result is two sessions,
one to HBA 1 and one to HBA 2, with different TSIDs assigned by the
Target.  If HBA 1 sends a TSID of zero, it has lost interest in
and/or forgotten about its old session.  Clearing the old session
is then a matter of the target timing it out and disposing of it in
some fashion and/or some sort of Reset being issued on another
session if there's something like a Persistent Reserve that needs
to be cleared.  If there was a Persistent Reserve, and the initiating
HBA has forgotten which session it was associated with, that initiating
HBA has a problem no matter what.  One advantage of only using TSIDs
is that it could allow a session with a Persistent Reserve to
be picked up in some fashion on a different HBA if ISID ranges are
statically assigned to HBAs (consider an HBA failure).

Part of this is a difference in approach - your email seems to
be concerned with distinguishing HBAs, whereas iSCSI has no problem
spreading the connections of a single session across multiple HBAs
and hence is concerned with identifying and distinguishing sessions.

Thanks,
--David

> 
> I fear I am missing something.
> 
>   >  Thanks,

> -----Original Message-----
> From: Rod Harrison [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 10:05 AM
> To: [email-masked]; [email-masked]
> Subject: RE: iSCSI: ISIDs
> 
> 
> David,
> 
> 	Comments below.
> 
> 	- Rod
> 
>   >  -----Original Message-----
>   >  From: [email-masked] [mailto:[email-masked]]
>   >  Sent: Friday, September 07, 2001 2:48 PM
>   >  To: [email-masked]; [email-masked]
>   >  Subject: RE: iSCSI: ISIDs
>   >
>   >
>   >  Rod,
>   >
>   >  > 	I don't see how having the target assign the ISID,
>   >  and effectively
>   >  > the whole SSID helps with the original problem of
>   >  recovery from an
>   >  > uncontrolled restart. In fact, I think it makes it worse.
>   >
>   >  It helps with the following problem:
>   >
>   >  	When the initiating adapter/interface assigns the
>   >  ISID, mistakes
>   >  	in assigning the ISID (inadvertently using the same ISID twice
>   >  	on two different interfaces) can cause sessions to
>   >  step on each
>   >  	other when that was not the intended result.  If there's no
>   >  	ISID, and TSID is dynamically assigned by the Target, this
>   >  	problem can't happen.
>   >
> 
> I agree that this part is simpler, my concern was over uncontrolled
> restart.
> 
>   >  Recovery from an uncontrolled restart wouldn't change in
>   >  principle.
>   >  In order to recover session resources (e.g., persistent
>   >  reserves), the
>   >  HBA had to remember the ISID - now it would have to
>   >  remember the TSID.
>   >  In practice, this may be an important difference - an
>   >  HBA can "remember"
>   >  the ISID(s) by always using the same ISID value(s),
>   >  whereas the TSID(s)
>   >  have to be stored after being provided by the target.
>   >
>   >  > 	Without and initiator assigned ISID the target is
>   >  presented with no
>   >  > information with which to distinguish HBAs in a host.
>   >  Assuming that
>   >  > HBA 1 has an existing session, how can the target tell
>   >  the difference
>   >  > between HBA 2 sending a leading login with the intent
>   >  of starting a
>   >  > new session, and HBA 1 sending a leading login after
>   >  an uncontrolled
>   >  > restart?
>   >
>   >  HBA 2 sends a TSID of zero, HBA 1 sends the TSID of the
>   >  session it's
>   >  trying to recover.  Two HBAs are not necessary to create
>   >  this scenario -
>   >  it can occur with two sessions on a single HBA.  If the
>   >  HBA has forgotten
>   >  the identity of the session it's trying to recover, that
>   >  session is
>   >  unrecoverable, but see above comment on differences in
>   >  remembering
>   >  an ISID vs. a TSID.
>   >
> 
> This is where I think we have a problem, if HBA 1 isn't trying to
> recover because it has had an uncontrolled restart it too will send a
> TSID of 0. How then can the target know whether it should clean the
> old session to HBA 1, or open a new session to HBA 2. IP address?
> 
> I fear I am missing something.
> 
>   >  Thanks,
>   >  --David
>   >  ---------------------------------------------------
>   >  David L. Black, Senior Technologist
>   >  EMC Corporation, 42 South St., Hopkinton, MA  01748
>   >  +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
>   >  [email-masked]       Mobile: +1 (978) 394-7754
>   >  ---------------------------------------------------
>   >
>   >  > -----Original Message-----
>   >  > From: Rod Harrison [mailto:[email-masked]]
>   >  > Sent: Friday, September 07, 2001 5:34 AM
>   >  > To: [email-masked]; [email-masked]
>   >  > Subject: RE: iSCSI: ISIDs
>   >  >
>   >  >
>   >  >
>   >  > 	I don't see how having the target assign the ISID,
>   >  and effectively
>   >  > the whole SSID helps with the original problem of
>   >  recovery from an
>   >  > uncontrolled restart. In fact, I think it makes it worse.
>   >  >
>   >  > 	Without and initiator assigned ISID the target is
>   >  > presented with no
>   >  > information with which to distinguish HBAs in a host.
>   >  Assuming that
>   >  > HBA 1 has an existing session, how can the target tell
>   >  the difference
>   >  > between HBA 2 sending a leading login with the intent
>   >  of starting a
>   >  > new session, and HBA 1 sending a leading login after
>   >  an uncontrolled
>   >  > restart?
>   >  >
>   >  > 	- Rod
>   >  >
>   >  > -----Original Message-----
>   >  > From: [email-masked]
>   >  [mailto:[email-masked]]On Behalf Of
>   >  > [email-masked]
>   >  > Sent: Thursday, September 06, 2001 10:40 PM
>   >  > To: [email-masked]
>   >  > Subject: iSCSI: ISIDs
>   >  >
>   >  >
>   >  > Time to back up and regroup on this topic.  It's clear
>   >  that ISID
>   >  > management needs more attention, and hence there are
>   >  some issues
>   >  > more basic than the attempted consensus call to work out.  So,
>   >  > I'm going to abandon the attempted consensus call, and try to
>   >  > make progress on the underlying ISID issue.  Those whose posts
>   >  > have called ISID management into question should not feel it
>   >  > necessary to apologize - this is an important issue to
>   >  unscramble.
>   >  >
>   >  > A rough summary of where we find ourselves is:
>   >  > - iSCSI Initiator Names span network interfaces/adapters,
>   >  > 	as do iSCSI Target Names.
>   >  > - Multiple sessions are allowed between an iSCSI Initiator
>   >  > 	and Target.  These are identified by an ISID and a
>   >  > 	TSID.
>   >  > - The ISID is the Initiator portion of the Session identifier
>   >  > 	and is used to track certain resources associated with
>   >  > 	the session (e.g., persistent reserves).
>   >  > - The TSID is the Target portion of the Session identifier,
>   >  > 	and serves primarily to make sure that all session
>   >  > 	identifiers (SSID = ISID||TSID) are unique at the
>   >  > 	Target.
>   >  >
>   >  > Michael Schoberg suggest getting rid of the ISID:
>   >  >
>   >  > > ISID - initiator-defined session-identifier
>   >  > >
>   >  > > Since initiators don't know about other initiators
>   >  connected to this
>   >  > target,
>   >  > > this has the potential of causing problems.
>   >  Eliminate it.  The
>   >  > initiator
>   >  > > should simply state it's intentions of establishing
>   >  a new session or
>   >  > adding
>   >  > > a connection to an existing session (via binary flags).
>   >  >
>   >  > The implication of this would be to make SSID = TSID,
>   >  dynamically
>   >  > assigned by the Target (0 is a reserved value on Login
>   >  asking Target
>   >  > to do this assignment), and partitioned appropriately across
>   >  > interfaces.
>   >  > Recoverable session resources would be associated with
>   >  the combination
>   >  > of <iSCSI Initiator Name, TSID> at the iSCSI Target,
>   >  and the initiator
>   >  > tracks via <iSCSI Target Name, TSID> - in both cases
>   >  the TSID replaces
>   >  > the ISID.  From a functional standpoint, this looks
>   >  like it works,
>   >  > and has the nice additional property that session
>   >  resources can be
>   >  > recovered through any iSCSI Initiator interface vs.
>   >  having to go back
>   >  > to the one that's allowed to use the ISID for that
>   >  session if ISIDs
>   >  > are statically partitioned.
>   >  >
>   >  > Does this cause any problems for the SAM-2 to iSCSI mapping?
>   >  >
>   >  > Thanks,
>   >  > --David
>   >  >
>   >  > ---------------------------------------------------
>   >  > David L. Black, Senior Technologist
>   >  > EMC Corporation, 42 South St., Hopkinton, MA  01748
>   >  > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
>   >  > [email-masked]       Mobile: +1 (978) 394-7754
>   >  > ---------------------------------------------------
>   >  >
>

---

From: "Rod Harrison" <[email-masked]>
Date: Fri, 7 Sep 2001 15:41:06 +0100

>  Sent: Friday, September 07, 2001 3:09 PM

I see. I was worrying about how the target could distinguish HBA 1
from HBA 2, but now I see it doesn't have to.

In the current scheme the target has to deal with cleaning old
sessions if an ISID is reused with TSID=0. If the target always issues
a new SSID when it gets a leading login it doesn't have to distinguish
between the HBAs. The only difference is that old sessions may get
left lying around for longer while they wait for something to time
out.

- Rod

  > If HBA 1 sends a TSID of zero, it has lost interest in