RE: iSCSI: ISIDs

[Black_David@emc.com]

John,

> Your reply is not clear.  Please explain how the TSID would be formed in
> the parallel session mode on the initiator (with a Wedge Driver in use)?

Reserved TSID value of 0 (meaning "Please allocate a TSID") is sent on
each leading login.  Target allocates different TSIDs to the different
parallel sessions.  Wedge driver continues to work as it always has.
A separate reply is coming to Jim's concern about how to map the
"SCSI Initiator Port" concept, and will address the concern that the
wrong mapping could limit the number of parallel sessions.

> Then how would the session be cleaned up on reboot?

A login with a non-zero TSID references the existing session with that
TSID.  A login with a zero TSID always creates a new session.  If the
Initiator has forgotten the TSID, the Target garbage collects that
session using the same sort of timeout approach that it uses to recover
from Initiators who have crashed and gone away.  As noted earlier, if
there are session resources like a Persistent Reserve on a session for
which the Initiator has forgotten the TSID, the Initiator has a problem
no matter what (same thing happens with current spec if it forgets the
ISID).  If we want the "Option A" functionality to aggressively
blow away the old session, we'd probably have to add a bit to login
saying "destroy the old session with this TSID (after checking that the
authentication matches)" in order to distinguish the "error recovery"
vs. "expedited destruction of old session" scenarios.

Target implementers probably need to be strongly advised that they
SHOULD NOT aggressively reuse session identifiers (e.g., TSIDs
can be allocated off of a counter that rolls over back to 1 from
its maximum value, along with a check for duplicates) to reduce
problems that could arise from "expedited destruction" if the
Target has reused the TSID value for a different session to the
same iSCSI Initiator.

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: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Friday, September 07, 2001 12:23 PM
> To: Black_David@emc.com
> Cc: Jim Hafner; ips@ece.cmu.edu
> Subject: RE: iSCSI: ISIDs
> 
> 
> 
> David,
> Your reply is not clear.  Please explain how the TSID would 
> be formed in
> the parallel session mode on the initiator (with a Wedge 
> Driver in use)?
> Then how would the session be cleaned up on reboot?
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: hufferd@us.ibm.com
> 
> 
> Black_David@emc.com on 09/07/2001 06:29:46 AM
> 
> To:   John Hufferd/San Jose/IBM@IBMUS, Black_David@emc.com, Jim
>       Hafner/Almaden/IBM@IBMUS
> cc:   ips@ece.cmu.edu
> Subject:  RE: iSCSI: ISIDs
> 
> 
> 
> > "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."
> >
> > Jim, & David, please correct me  but I think this means 
> that only one
> > Session could be started from any iSCSI Initiator Node to a 
> Given Target.
> 
> No, multiple sessions are still possible - they'd be distinguished by
> different TSIDs.  If different portal groups are in use, that'd have
> to be encoded in the TSID.
> 
> --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
> ---------------------------------------------------
> 
> 
>