Re: [Fwd: iSCSI - revised 2.2.4]

["Mallikarjun C." <cbm@rose.hp.com>]

Julian and Santosh,

It appears to me that there are a couple of questions 
to address, to arrive at a resolution to this change 
request -

	1)Should all operational keys be sent in one
          text command PDU?  (Can they, given that 
          the max PDU size may be a constraint?  Or,
          did the constraint go away with the recent
          set of changes that allow one key=value to
          span multiple PDUs?)
        2)Can keys be renegotiated to different values 
          (after they were negotiated once) in the same 
          negotiation sequence?


If I understood Santosh right, he is implicitly assuming
"yes" to (1) above - so anything that the initiator 
does not offer tantamounts to an explicit default.  If
that's the case, I agree with this view.  [ Julian, please
comment how the new key-spanning is differentiated from 
the multi-command sequence in the PDU header. ]

If the answer to (2) above "yes" (which Santosh thinks
is the case, and suggests as the answer to Julian's 
scenario), I would first of all like to understand the
practical usage of it.  As a first reaction, it appears
to me to open the door for endless exchanges.  But there
may be other safeguards in the draft that I haven't 
closely looked at.

Thanks.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


Santosh Rao wrote:
> 
> Julian Satran wrote:
> >
> > Santosh,
> >
> > The reason I am hesitant on accepting this change proposal as is that it
> > might makes the negotiation very much state dependent and different for
> > keys that have a default and keys that don't have one.
> 
> I don't see why. An initiator that receives a login response needs to
> know whether to respond to a received key anyway. It does this by some
> mechanism like maintaining a list of keys that it sent in its login
> command. All that is required is that the initiator include those
> operational keys that it sent as defaults in this list. (it needs to do
> this anyway, since usage of defaults implies the initiator is offering
> those key values.)
> 
> Also, when the target responds to a default offering, it is actually
> sending back the result of the negotiation. What benefit exists in
> having the initiator again echo this value back to the target in a
> redundant round-trip ?
> 
> > In addition it may
> > change login behavior for different versions of the protocol that may have
> > different defaults.
> 
> Again, I don't see why. The default values accepted by both sides are
> the defaults of the "version active" returned in the login response.
> 
> >  I admit that it has appeal for the login (where the
> > defaults are relevant) by shortening some negotiations.
> >
> > However the issues it raises are multiple. Assume that you have the
> > following sequence:
> >
> > I->T key1=x
> > T->I key1=z,key2=a
> > I->T key2=b
> > ....
> >
> > Observe that the initiator designer was very conservative and probably
> > intended to negotiate the keys one at a time
> > while the target is aggressive and wants to set everything as soon as
> > possible.
> 
> I don't understand how the above scenario is correct. If key2 was an
> operational parameter, it already has a default defined for it, and the
> initiator cannot negotiate it one at a time, since it has already made
> the offer (of the default) by not sending the key explicitly.
> 
> In any case, the initiator can always re-negotiate a key by re-sending
> the key again. I don't understand how the above example justifies the
> need for your current model.
> 
> >
> > With the defaults rule the results are harder to define.
> >
> > With the rules we have now the results are hardly dependent on sequence.
> >
> > Add to this that with the new rules about PDULength exchanges are hardly
> > "self contained" - i.e. key=value pairs can span sequences (that was
> > another reasons I did not like this but framing at high speeds has
> > precedence!).
> >
> > However we might perhaps want to consider the following loose rule for
> > defaults in the context of operational parameter negotiation at login only
> > (leaving the negotiation rules as they are):
> >
> > If the initiator issues a login request with the F bit set to 1 is assumed
> > to have an imaginary content including all the operational keys that have a
> > default value and where not sent yet by the initiator during login and
> > their values set to the default value.
> 
> Julian, the login rules are already complex enough. Why do we need to
> special case them further and increase the complexity ? I think login
> behaviour is quite simple to understand/follow when the initiator is
> considered as the originator of a key if it uses default values for that
> key.
> 
> Thanks,
> Santosh
> 
> >
> > Comments?
> >
> > Julo
> >
> > PS - and a procedural thing - nagging me repeatedly on a subject is
> > annoying and quoting the number of agreements before attempting different
> > scenarios is even more so
> 
> It is unfortunate that you consider my polite requests to attempt to
> resolve an open issue as nagging. I don't know how much more polite I
> could possibly get. [and I am trying to discuss specific scenarios to
> understand the issues you have with this].
> 
> >
> >
> >                     Santosh Rao
> >                     <santoshr@cup.       To:     IPS Reflector <ips@ece.cmu.edu>
> >                     hp.com>              cc:
> >                     Sent by:             Subject:     [Fwd: iSCSI - revised 2.2.4]
> >                     owner-ips@ece.
> >                     cmu.edu
> >
> >
> >                     11-10-01 01:36
> >                     Please respond
> >                     to Santosh Rao
> >
> >
> >
> > Julian,
> >
> > What is the resolution on this issue ?
> >
> > - Santosh
> >
> > Santosh Rao wrote:
> > >
> > > Julian,
> > >
> > > I apologize upfront for being so persistent on this.
> > >
> > > However, it would really help if you could give some clear example of a
> > > scenario as to why the initiator cannot be considered the originator of
> > > a negotiation, when it offers a key value implicitly, through the use of
> > > a default.
> > >
> > > Several people on this list (Paul Konning, Sanjeev, Deva, myself, and
> > > perhaps others, that I cannot recall at the moment) have asked that the
> > > spec must not differentiate login behaviour when the initiator offers a
> > > key explicitly vs. when it offers a key implicitly thru the use of the
> > > default.
> > >
> > > Please help us understand the need for iscsi to distingush the login
> > > behaviour in the above case. [through some tangible scenarios and
> > > examples].
> > >
> > > Thanks,
> > > Santosh
> > >
> > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> > > >
> > > > Julian,
> > > >
> > > > I would also request an explicit definition of offering party and
> > > > responding party. The current text still leaves ambiguity when target
> > > > sends a key in response to implicit default key of the Intiator. In
> > > > this case who is the offering party and who is the responding party
> > > >
> > > > Sanjeev
> > > >
> > > >      -----Original Message-----
> > > >      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > > >      Sent: Friday, October 05, 2001 2:06 PM
> > > >      To: ips@ece.cmu.edu
> > > >      Subject: iSCSI - revised 2.2.4
> > > >
> > > >      Here is a revised (complete) part 2.2.4 based on recent
> > > >      agreed changes:
> > > >
> > > >      1.1.1        Text Mode Negotiation
> > > >
> > > >      During login and thereafter some session or connection
> > > >      parameters are negotiated through an exchange of textual
> > > >      information.
> > > >
> > > >      All negotiations are stateless - i.e. the result MUST be
> > > >      based only on newly exchanged values.
> > > >
> > > >      The general format of text negotiation is:
> > > >
> > > >      Originator-> <key>=<valuex>
> > > >      Responder-> <key>=<valuey>|reject|NotUnderstood
> > > >
> > > >      The value can be a number, a single literal constant a
> > > >      Boolean value (yes or no) or a list of comma separated
> > > >      literal constant values.
> > > >
> > > >      In literal list negotiation, the originator sends for each
> > > >      key a list of options (literal constants which may include
> > > >      "none") in its order of preference.
> > > >
> > > >      The responding party answers with the first value from the
> > > >      list it supports and is allowed to use for the specific
> > > >      originator.
> > > >
> > > >      The constant "none" MUST always be used to indicate a
> > > >      missing function. However, none is a valid selection only if
> > > >      it is explicitly offered.
> > > >
> > > >      If a target is not supporting, or not allowed to use with a
> > > >      specific originator, any of the offered options, it may use
> > > >      the constant "reject".  The constants "none" and "reject"
> > > >      are reserved and must be used only as described here.  Any
> > > >      key not understood is answered with "NotUnderstood".
> > > >
> > > >      For numerical and single literal negotiations, the
> > > >      responding party MUST respond with the required key and the
> > > >      value it selects, based on the selection rule specific to
> > > >      the key, becomes the negotiation result.  Selection of a
> > > >      value not admissible under the selection rules is considered
> > > >      a protocol error and handled accordingly.
> > > >
> > > >      For Boolean negotiations (keys taking the values yes or no),
> > > >      the responding party MUST respond with the required key and
> > > >      the result of the negotiation when the received value does
> > > >      not determine that result by itself.  The last value
> > > >      transmitted becomes the negotiation result.  The rules for
> > > >      selecting the value to respond with are expressed as Boolean
> > > >      functions of the value received and the value that the
> > > >      responding party would select in the absence of knowledge of
> > > >      the received value.
> > > >
> > > >      Specifically, the two cases in which responses are OPTIONAL
> > > >      are:
> > > >
> > > >      - The Boolean function is "AND" and the value "no" is
> > > >      received. The outcome of the negotiation is "no".
> > > >      - The Boolean function is "OR" and the value "yes" is
> > > >      received. The outcome of the negotiation is "yes".
> > > >
> > > >      Responses are REQUIRED in all other cases, and the value
> > > >      chosen and sent by the responder becomes the outcome of the
> > > >      negotiation.
> > > >
> > > >      The value "?" with any key has the meaning of enquiry and
> > > >      should be answered with the current value or
> > > >      "NotUnderstood".
> > > >
> > > >      The target may offer key=value pairs of its own. Target
> > > >      requests are not limited to matching key=value pairs as
> > > >      offered by the initiator.  However, only the initiator can
> > > >      initiate the negotiation start (through the first Text
> > > >      request) and completion (by setting to 1 and keeping to 1
> > > >      the F bit in a Text request).
> > > >
> > > >      Comments ?
> > > >
> > > >      Julo
> > >
> 
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################