RE: iSCSI: ISIDs

[Black_David@emc.com]

>   >  > 	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:rod.harrison@windriver.com]
> Sent: Friday, September 07, 2001 10:05 AM
> To: Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: ISIDs
> 
> 
> David,
> 
> 	Comments below.
> 
> 	- Rod
> 
>   >  -----Original Message-----
>   >  From: Black_David@emc.com [mailto:Black_David@emc.com]
>   >  Sent: Friday, September 07, 2001 2:48 PM
>   >  To: rod.harrison@windriver.com; ips@ece.cmu.edu
>   >  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
>   >  black_david@emc.com       Mobile: +1 (978) 394-7754
>   >  ---------------------------------------------------
>   >
>   >  > -----Original Message-----
>   >  > From: Rod Harrison [mailto:rod.harrison@windriver.com]
>   >  > Sent: Friday, September 07, 2001 5:34 AM
>   >  > To: Black_David@emc.com; ips@ece.cmu.edu
>   >  > 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: owner-ips@ece.cmu.edu
>   >  [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>   >  > Black_David@emc.com
>   >  > Sent: Thursday, September 06, 2001 10:40 PM
>   >  > To: ips@ece.cmu.edu
>   >  > 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
>   >  > black_david@emc.com       Mobile: +1 (978) 394-7754
>   >  > ---------------------------------------------------
>   >  >
>