Subject: Re: iscsi: Text keys

From: [email-masked]
Date: Wed, 2 May 2001 18:29:58 +0300

comments/answers in text.

Thanks,
Julo

[email-masked] (Sandeep Joshi) on 02-05-2001 06:49:53

Please respond to [email-masked] (Sandeep Joshi)

To:   [email-masked]
cc:
Subject:  iscsi: Text keys

Julian,

Some comments on the text keys defined in Appendix E.

thanks,
-Sandeep

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

2) The paragraph on TargetAddress seems to indicate that one
   or more text responses could be sent to satisfy a SendTargets
   command.
      "If the list cant be delivered as a single text
      response PDU, ..several text response PDUs can
      be sent..logical merge of the individual lists".

   How does the initiator know more than one TextResponse PDUs
   are expected for that TextCommand PDU ?  If the final bit is
   to be used, does it imply that the initiator should keep
   sending the sendTargets TextCommand with f=1 until it
   receives the last TextResponse PDU ?

   Could you please clarify...

+++ the value 0 in the F bit of a text commands tells you that there is
more to come.
I addition I think that the naming and discovery folks are looking at a
"list syntax"
++++

3) SendTargets again.  The ordering within the text response
   currently is implied and needs to be specified so that
   the initiator can correlate the target alias with the
   target addresses.

   Something along these lines may help
     "The order within a text response should be
       (targetName, targetAlias(if any), list of addresses)"

+++ I have to coordinate this with the Naming and discovery team.  +++

4) The section on InitiatorName seems to imply that the
   target can also propose the value for this key ??
   I presume this is a typo.
      See "Who: Initiator and Target"
+++ it is a typo thanks +++

---

From: Santosh Rao <[email-masked]>
Date: Thu, 03 May 2001 16:55:21 -0700

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