Subject: iSCSI-Asynch event code

From: "Julian Satran" <[email-masked]>
Date: Wed, 12 Jun 2002 19:58:03 +0300

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

---

From: Santosh Rao <[email-masked]>
Date: Wed, 12 Jun 2002 11:41:23 -0700

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

---

From: "Rod Harrison" <[email-masked]>
Date: Wed, 12 Jun 2002 14:45:57 -0500

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Santosh Rao
Sent: Wednesday, June 12, 2002 1:41 PM
To: Julian Satran
Cc: [email-masked]
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.

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

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 12 Jun 2002 12:55:37 -0700 (PDT)

> re-established allowing for new negotiation.

Isn't that a bit severe? That strikes me as kinda like saying you don't
need an off switch on your car radio because you can just go out and
unplug the car battery.

> be used to achieve the same effect.

Then why do we permit any parameter renegotiation at all? Why not just
always require connection logout/drop to renegotiate?

> change, but instead, use the async cxn/ssn logout/drop mechanisms.

I think the point is that if we don't do this, then all the effort put
into being able to renegotiate parameters (MaxRecvPDUDataSize in
particular) only works half way - how can the target initiate such a
negotiation?

If we do as you suggest (which we certainly can choose to do), then why
support any FFP renegotiations?

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Wed, 12 Jun 2002 13:41:06 -0700 (PDT)

I don't mind this code being added for completeness
sake, nor will I be overly disappointed if it isn't.

If it is added, however, perhaps we should go half
a step farther and demand that the Text Request coming
from the initiator MUST be empty? That way the target
is
really "in charge" and may _originate_ any key
negotiable
in FFP. Just my $.02. Comments?

Martins Krikis, Intel Corp.

Disclaimer: These are my opinions and
            may not be my employer's.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 Jun 2002 16:54:19 -0400

> be used to achieve the same effect.

I agree.

    paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 Jun 2002 17:03:19 -0400

> initiator will ever log that connection back in again.

Why wouldn't it?

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

	 paul

---

From: "Rod Harrison" <[email-masked]>
Date: Wed, 12 Jun 2002 17:04:28 -0500

>  From: Paul Koning [mailto:[email-masked]]
  >  Sent: Wednesday, June 12, 2002 4:03 PM
  >  To: [email-masked]
  >  Cc: [email-masked]; [email-masked];
  >  [email-masked]
  >  Subject: RE: iSCSI-Asynch event code
  >
  >

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

  >  conclusions you draw from this guess (i.e., "wait a

	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

---

From: "Randy Jennings" <[email-masked]>
Date: Wed, 12 Jun 2002 15:18:25 -0700

> in FFP. Just my $.02. Comments?

I would say no.

If the Initiator has a Text Negotiation in the queue, it should not have to
clear it.

Sincerely,
Randy

Data Transit