RE: iSCSI-Asynch event code

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

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.

	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 think that would still be a worthy addition, perhaps with
a parameter in the negotiation request that allows an immediate login
if the logout option is taken.

	The target would never have to drop the connection because the
initiator MUST either negotiate or logout.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Santosh Rao
Sent: Wednesday, June 12, 2002 1:41 PM
To: Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI-Asynch event code



Why is this needed ? The target can just send an async event to drop
the
connection or request a connection logout, and the connection can be
re-established allowing for new negotiation.

I don't see the point of making this change so late in the game. There
exist mechanisms such as target driven connection logout/drop which
can
be used to achieve the same effect.

In any case, what do you do if the initiator does not respond with a
text message ? The target would end up dropping the cxn with an async
message in this case, causing a re-login and thus, re-negotiation.

To summarize, I don't see a need for this change, since there are
simpler mechanisms to achieve the same effect. In particular, given
that
we are so close to the finish line, I suggest that we not make this
change, but instead, use the async cxn/ssn logout/drop mechanisms.

Rgds,
Santosh


Julian Satran wrote:
>
> Dear colleagues,
>
> I plan to add to the text in 9.9.1 an additional event code as
> follows. It is needed for completeness.
>
> 4 - target requests parameter negotiation on this connection. The
> initiator MUST honor this request by issuing a Text Request (that
can
> be empty) on the same connection as early as possible unless a Text
> Request is already pending on the connection or by issuing a Logout
> Request.
> Julo

--
The world is so fast that there are days when the person who says
it can't be done is interrupted by the person who is doing it.
	~ Anon