RE: iSCSI: reusing ISID for recovery

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

Thanks John.  I'm not concerned about the amount of code.  The sticking
point for option B is the delay in initiator boot time for what I feel is
unnecessary protection against software defects (IOTW, adds delay to boot to
inform initiator of existing session, which initiator wants cleaned up
anyway).  I recall very ugly boot times in FC testing because of delay in
target response to initiator login that would cause some OS (MS!) to give up
and time out the target device at great expense to total SAN recovery times.

Marj 

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Thursday, August 30, 2001 12:48 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> Folks,
> Following your notes, I think  that if an initiator does not 
> know what it
> is doing, rather then having a new semantic on Login, why not 
> just Logout,
> then re-Login.
> Since this should only happen like "Never", if you have coded 
> things well,
> and the infrequency should mean that the extra hand shake is 
> not a problem.
> 
> However,  if you do not know what your session's TSID is, you 
> probably are
> two screwed up to make even the above Logout work, so I think 
> this is what
> you are all trying to address.  That is,  we  need to have a 
> method to blow
> everything away and start again when the initiator has lost 
> the TSID of its
> Session.  This is why we have option A, and Option B.
> 
> So I think the issue here is do we add additional responses at boot up
> time, or not.  (Quit frankly I do not think this is an 
> important issue,
> either way.) However, it is a consideration.  If mode B is 
> used, the clean
> up bit is available, and initiators that use it all the time, 
> will usually
> cause the Extra interaction to occur at boot, because the 
> normal case would
> be that things come up clean.  (Since I think we said that if 
> things are
> clean, an error response would be issued. Therefore, most of 
> the time, the
> extra response is going to happen).  If, as some have 
> suggested, the right
> way to code this is to use  the Clean up bit only when there 
> is a rejection
> of the Login, because of existing sessions, and require that 
> the initiator
> should come back with the Login again but this time with the 
> Clean up bit
> set. The argument is made that there will not normally  be any extra
> interaction.  Just extra interactions when clean-up is needed. (This
> approach has been called Option B.)  The other approach is 
> known as Option
> A.  It will implicitly start the Login and clear out any 
> existing session
> when the Login is issued.   There will never be extra 
> responses with Option
> A, and there will only be extra responses in option B when the Target
> rejects the Login because of a existing session. The Option B clean-up
> action will not happen often, and the code is not hard, but 
> there is more
> code, perhaps 100 lines.
> 
> Now the folks that support option A say that they will not have to do
> anything special since they want the Login to always succeed 
> and blow away
> any other thing that might be going on.  It is clear that 
> this has less
> code and interaction at boot/Startup. (However 100 lines of 
> code is not a
> big deal anyway.)
> It also seem to me that there is probably less code on the 
> target since
> they do not have to do inspection of whether or not sessions 
> are active or
> not, etc. They just blow them away if they exist.
> 
> So all this flapping has to do with whether we need to add 
> (on either side)
> some (perhaps small) amount of code so that we use to protect 
> from a buggy
> Initiator.
> 
> I think this is a Nit in the Draft and is needlessly 
> divisive, over a small
> amount of code.
> 
> There has also been stated the opinion that option B is 
> needed when their
> is more then one OS sharing the Link.  I do not think this 
> applies since
> there should be another iSCSI Initiator Name for each OS, and 
> therefore it
> is a different session and has nothing to do with the 
> discussion at hand.
> 
> Therefore, since the simplification (less code) is on the 
> side of option A,
> and since this is really not important anyway, I suggest that 
> all the B
> folks roll over since you will not be able to convince the A 
> folks anyway,
> and since they do have a valid (small) argument that Option B 
> requires more
> complexity and lines of code.
> 
> So I recommend Option A, and lets move on.  This does not 
> deserver the list
> space, or the emotion  it has been given.
> 
> .
> .
> .
> 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
>