Re: iscsi: Text keys

[julian_satran@il.ibm.com]

Santosh,

I understand your concerns.   I am also looking for a decent solution that
will not break too much existing software.
Of of them would be stating that mode set commands, although not rejected,
will have no effect on the parameters (we can't limit them to login as
those are unaware of such states).

As for enquiry in text form - that could be introduced with some very
simple syntax - like a key followed by a question mark (?) and answered by
a key followed by an exclamation mark (!) but I wonder what will this new
thing buy you ?

Julo

Santosh Rao <santoshr@cup.hp.com> on 04-05-2001 02:55:21

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iscsi: Text keys




julian_satran@il.ibm.com wrote:
>
> 1) There are several text keys which have been specified
>    with Use=ALL.  Such keys can be negotiated during
>    full-feature phase, which raises interesting questions
>    about their effect on currently outstanding tasks.
>
>    For example,
>    a) maxOutstandingR2T : what is the effect on currently
>       outstanding R2Ts ?
>    b) LoginLogoutMaxTime : how does it affect connections
>        which just got dropped and need to be recovered ?
>    c) DataPDULength : effect on data PDUs in flight.
>
>    Similar questions need to be answered for practically
>    all the keys which have this behaviour.  For the sake of
>    simplicity, it may be better to forbid such usage and
>    allow these keys to be only negotiated in the connection
>    or session login phase.
>
> +++ some of the parameters you mentioned are SCSI mode-page parameters.
> Even if we
> restricted them to login they can be changed by a SCSI mode-set.  I agree
> that keeping them all
> restricted to login would simplify implementations but I am not convince
it
> would make them better. Evidently a negotiated change will apply to all
> packets that are sent after the negotiation ended (and a negotiation end
is
> known to both parties) and an initiator will avoid sending things in
> violation of its last offering.
> Except that we will have to find a way to reject mode set I am open to
> restrict those parameters to login if that is what the majority of
> implementors tells me.
> +++


Julian,

1) I would like to request that login/text key negotiation be restricted
to login time only and have been asking for this on the reflector
earlier as well. Implementations would be simpler with fewer options,
and we are better off without options like these that are prone to
side-effects when changed during full feature phase.

2) Regarding the mode select setting of these parameters, this issue
could not be discussed at the Nashua interim meeting for lack of time.
I'd like to once again suggest that iSCSI use only 1 scheme(text/login
keys) for setting these keys while allowing a query of these options
from both layers.

3) Speaking of querying for options, my understanding is that the
initiator sends all its options and the target responds with its chosen
one from that list during login/text negotiation.

Is there a mechanism by which an initiator could query the target for
its supported key capabilities ? (i.e. what is the equivalent of a mode
sense for these login keys ?).

4) Lastly, the login/text negotiation can comprise of several text
command/response exchanges with each being based on the same Initiator
Task Tag. The addition of a Target Task Tag field to the login response,
text command and text response PDUs would help targets to lookup the
negotiation state based on the Target Task Tag which is easier than
having to perform a lookup on (Initiator iSCSI Name + ISID).

Regards,
Santosh
 - santoshr.vcf