Re: iSCSI-Asynch event code

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Wed, 12 Jun 2002, Santosh Rao wrote:

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

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.

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

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

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

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