RE: iSCSI: ISIDs

["Rod Harrison" <rod.harrison@windriver.com>]

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
  >  > ---------------------------------------------------
  >  >