Subject: RE: iSCSI-Asynch event code

From: [email-masked]
Date: Wed, 12 Jun 2002 15:54:54 -0600

Paul and Santosh,

If this isn't needed, then I don't see why FFP negotiation is needed at all (other than to support discovery with SendTargets but that isn't really a negotiation). The initiator could also close and reopen the connection to change PDU size. If we support renegotiation of some keys during FFP for the initiator, then we should do it for the target as well. Otherwise we shouldn't support renegotiation at all.

Pat

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 1:54 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: iSCSI-Asynch event code

Excerpt of message (sent 12 June 2002) by Santosh Rao:
> 
> 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.

I agree.

    paul

---

From: Santosh Rao <[email-masked]>
Date: Wed, 12 Jun 2002 15:47:28 -0700

I don't see a need to allow key re-negotiation during FFP. The only key
that is really required to be used in FFP is SendTargets.

The keys that are permitted during FFP are :

- SendTargets
- TargetAlias
- InitiatorAlias
- TargetAddress
- MaxRecvDataPDUSize (or whatever its latest name is)
- Vendor Specific keys

Of the above, the only real negotiation involves the MaxRecvPDUSize. I
don't see any use of attempting to modify/negotiate/communicate the
remaining keys during FFP (with the exception of SendTargets).

I see no problem in forbidding key re-negotiation during FFP and
handling PMTU changes by dropping the connection and allowing it to be
re-established.

There needs to be a conscious effort to simplify this login negotiation
process and bound the complexity that's being heaped upon it. If we
don't make the attempt to keep it simple, we are going to be bitten by a
bunch of bugs in this area due to its complexity.

This is one such area where we can choose not to increase the complexity
of login negotiation.

There have been some concerns raised about the initiator not logging
back in upon a target driven logout. Such an initiator driver is a poor
design. As long as an upper layer in the O.S. has an open pending on
some LUN of that target port, it is the duty of the initiator driver to
attempt to keep the I-T nexus established, and if there's a transient
glitch in the I-T nexus, the initiator must attempt to re-login.

An initiator that does not do this gets what it deserves. There's no
need to add complexity to the spec in an attempt to deal with poor
initiator implementations. The target need not care if the initiator
does not log back, in this case.

- Santosh

-- 
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 21:55:04 -0500

Santosh,

	If there were only one connection per session I would agree, but I
think you are overlooking the multiple connection case.

	If an initiator has say 10 connections in a session and the target
requests a logout of one of them what motivation does the initiator
have to reopen that connection in a timely manner? And as I mentioned,
the initiator may be unable to connect to the target for many reasons.
The spec doesn't mandate an initiator re-login in a connection and any
target design that assumes it will is a bad one.

	- Rod

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Santosh Rao
Sent: Wednesday, June 12, 2002 5:47 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: iSCSI-Asynch event code

I don't see a need to allow key re-negotiation during FFP. The only
key
that is really required to be used in FFP is SendTargets.

- SendTargets
- TargetAlias
- InitiatorAlias
- TargetAddress

There needs to be a conscious effort to simplify this login
negotiation
process and bound the complexity that's being heaped upon it. If we
don't make the attempt to keep it simple, we are going to be bitten by
a
bunch of bugs in this area due to its complexity.

This is one such area where we can choose not to increase the
complexity
of login negotiation.

There have been some concerns raised about the initiator not logging
back in upon a target driven logout. Such an initiator driver is a
poor
design. As long as an upper layer in the O.S. has an open pending on
some LUN of that target port, it is the duty of the initiator driver
to
attempt to keep the I-T nexus established, and if there's a transient
glitch in the I-T nexus, the initiator must attempt to re-login.

- Santosh

[email-masked] wrote:
>
> Paul and Santosh,
>
> If this isn't needed, then I don't see why FFP negotiation is needed
at all (other than to support discovery with SendTargets but that
isn't really a negotiation). The initiator could also close and reopen
the connection to change PDU size. If we support renegotiation of some
keys during FFP for the initiator, then we should do it for the target
as well. Otherwise we shouldn't support renegotiation at all.

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 13 Jun 2002 11:12:38 -0700

Pat:
Even if the feature is not added, FFP negotiation still can be carried out
when the initiator/both want(s) to renegotiate/redeclare certain keys.
The new feature is needed only for one case - when the target wants
to redeclare some key, and the initiator doesn't care so doesn't initiate
a text request.  There is such a theoretical possibility for Max... key.

Santosh:
This is not Login negotiation as you seem to suggest.

The comment about initiator not being able to log back in after a connection
drop may not be due to initiator implementation problems, as you think.  I
think the reference was to multi-initiator environments, with the connection
resource on the target being taken away by a different initiator.

I personally think there's some value in FFP negotiations.  I have come around
to the position that I'm mildly in favor of this feature - for the reason I described
above to Pat.  I still however tend to think that it's more useful for the future.

Julian:
I think you also need to state what the target may do if a negotiation
prompt is not received within the expected time - similar to the logout
request event.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
[email-masked]

----- Original Message -----
From: "Santosh Rao" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 12, 2002 3:47 PM
Subject: Re: iSCSI-Asynch event code

> > If this isn't needed, then I don't see why FFP negotiation is needed at all (other than to support
discovery with SendTargets but that isn't really a negotiation). The initiator could also close and reopen the
connection to change PDU size. If we support renegotiation of some keys during FFP for the initiator, then we
should do it for the target as well. Otherwise we shouldn't support renegotiation at all.