RE: iSCSI-Asynch event code

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

  >  -----Original Message-----
  >  From: Paul Koning [mailto:ni1d@arrl.net]
  >  Sent: Wednesday, June 12, 2002 4:03 PM
  >  To: rod.harrison@windriver.com
  >  Cc: santoshr@cup.hp.com; Julian_Satran@il.ibm.com;
  >  ips@ece.cmu.edu
  >  Subject: RE: iSCSI-Asynch event code
  >
  >
  >  Excerpt of message (sent 12 June 2002) by Rod Harrison:
  >  > Santosh,
  >  >
  >  > 	There is a slight difference where the new event
  >  gives us more than
  >  > we have. If a target requests a logout there is no
  >  guarantee the
  >  > initiator will ever log that connection back in again.
  >
  >  Why wouldn't it?
  >

Because it has been told to logout by the target so presumably the
target doesn't want that connection in place.

  >  > 	The reason I suggested we allow the initiator to
  >  bypass the login
  >  > timeouts if it logged out as a result of the new event
  >  was because the
  >  > target isn't asking for a logout to reduce resource
  >  commitments, so
  >  > there seems to be no need to wait for what may be a
  >  long time to
  >  > re-login.
  >
  >  I don't see any reason for the initiator to assume that
  >  a timeout is
  >  needed after a target logout request.  Guessing at "resource
  >  commitments" as the reason for the request sounds like a
  >  risky thing
  >  to do -- the reason might be something quite different and the
  >  conclusions you draw from this guess (i.e., "wait a
  >  while") may be
  >  entirely inappropriate.
  >

	I misread the DefaultTime2Wait key; I hadn't realised it referred
only to unexpected connection termination. Somehow I had gotten the
idea the initiator should wait this long before logging in again, and
it was that I was objecting to in the negotiation event case.

	My mistake, sorry!

	However, we can turn this logic around, if a target requests an
initiator logout a connection as a mechanism for instigating parameter
negotiation there is certainly no guarantee the initiator will login
again quickly, or indeed ever. You said "why wouldn't it", but why
would it? The initiator could assign the released connection resources
to another session and be unable to start another connection in the
first session. DNS might be down, there are all sorts of things that
can prevent a connection being established that don't effect an
established connection. Unless we include language stating otherwise a
target that requests a connection logout for any reason can't assume a
reconnect will happen.

	- Rod

  >  	 paul
  >
  >