Re: iscsi: Text keys

[julian_satran@il.ibm.com]

comments/answers in text.

Thanks,
Julo

sandeepj@research.bell-labs.com (Sandeep Joshi) on 02-05-2001 06:49:53

Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)

To:   ips@ece.cmu.edu
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 +++