Re: iscsi : numerical negotiation wording is ambiguous

[Santosh Rao <santoshr@cup.hp.com>]

Julian,

It does appear that we are getting nowhere with this discussion :<. I
would like to re-iterate the advantages of the "responder computes
negotiation result" model vs. the "both sides compute negotiation
result" model again :

1) Only one side picks the result of the negotiaton. Hence, the 2 sides
cannot go out of sync on the value picked.
 
2) The originator knows the negotiated result at the the responder since
the responder sends back the result of the negotiation.
 
3) This model is easier to debug because of (1) & (2).
 
4) Less code since only 1 party (responder) needs to perform the
computation to pick the result of the negotiation. The originator only
needs to only check that the response it got back is acceptable.
Standard parsing technique in mass storage. (ex : FC PLOGI, FC PRLI,
SCSI Mode Sense parsing by initiator uses the same scheme.)
 
5) This scheme leaves less room for interop problems and
mis-interpretation since it is the more familiar negotiation technique
that is in use in most other mass storage protocols. (ex : FC PLOGI, FC
PRLI, etc). From a first reading of the current negotiation scheme, it
is'nt readily apparent that the currently defined model is different
from the above and requires both sides to be picking the result of the
negotiation, instead of 
just the responder.

6) Less protocol rules to be enforced. No need to call out the rules for
each side explicitly. The responder picks the result & sends it back to
originator.

Clearly, at least 3 developers read the draft to imply the negotiation
scheme in use is "responder picks the negotiation result". So, there is
room for mis-interpretation here. Based on the above advantages, I feel
it is a safer model, with no room for mis-interpretations. In addition,
it aids debugging & involves less code.

Lastly, I suggest that the draft call out explicitly that the initiator
is ALWAYS the originating party and the target is ALWAYS the responding
party for ALL security and operational keys. This is due to each key
having either a default value(in case initiator chose to use the default
and not send the key), or the key is mandated to be sent by initiator.

Thanks,
Santosh


Julian Satran wrote:
> 
> Santosh,
> 
> We are getting nowhere. Even if requester is doing it's stuff - the
> requester will have to check and be prepared for a mistake. The coding
> will require a reject.
> 
> Julo
> 
>   Santosh Rao
>   <santoshr@cup.hp.com>                 To:        ips@ece.cmu.edu
>   Sent by: santoshr@cup.hp.com          cc:        "Sanjeev Bhagat
>                                 (TRIPACE/Zoetermeer)"
>   01-10-01 20:37                <sbhagat@tripace.com>, Julian
>   Please respond to Santosh Rao Satran/Haifa/IBM@IBMIL
>                                         Subject:        Re: iscsi :
>                                 numerical negotiation wording is
>                                 ambiguous
> 
> 
> 
> Julian & Sanjeev,
> 
> Responding to both your mails......
> 
> Julian :
> 
> I think you may have mis-interpreted my comments. I believe Sanjeev
> has
> clarified the intent of my suggestions.
> 
> I am *not* suggesting that the responder send back its values and
> these
> be blindly imposed on the originator. On the contrary, my suggestion
> is
> that the computation of the result of the negotiation (higher or lower
> of the 2 values) be only performed by the responder and sent back to
> the
> originator.
> 
> The result of the negotiation is the same in both cases and there is
> no
> REJECT required in my case nor yours. The difference is the advantages
> I've stated in my model.
> 
> Sanjeev, in response to your comment :
> 
> " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> >  no reject , but it can be a problem in future .
> >  Consider your example of DataPDULength in your own
> >  message. Suppose offering party sends a value of 16,384
> >  (this is also lowest value it can send) and responding
> >  party responds with 8,192. In this case the offering
> >  party will have to reject the negotiation. So a reject
> >  message is needed in this case also. "
> 
> There is NO need for any REJECT in the above case. If the initiator
> is'nt satisfied with the value returned by the originator and cannot
> function with the negotiated values, it can simply close the TCP
> connection. There is no need to send any REJECT.
> 
> Thanks,
> Santosh
> 
> > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> >
> > Thanks Julian, please find my further comments in the message
> >
> >      -----Original Message-----
> >      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >      Sent: Sunday, September 30, 2001 6:07 PM
> >      To: ips@ece.cmu.edu
> >      Subject: RE: iscsi : numerical negotiation wording is
> >      ambiguous
> >
> >      Sanjeev,
> >
> >      I am not sure clear I made the tiny diference between what I
> >      say and what Santosh said:
> >
> >      Santosh says:
> >
> >        1. a requester sends A=valuex
> >        2. a responder sends B=valuey
> >        3. the responder assumes that the value y is the correct
> >           value and so does an external observer
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather
> >           say it this way the responder computes the value with
> >           its own supported values and responds with a value y
> >           which the responder thinks is correct and so does an
> >           external observer
> >        4. the requester checks that valuey is conformant (he will
> >           not believe it) and will reject it if not conformant
> >           else it will accept it
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct,
> >           but it is highly unlikely for the responder to reject
> >           the final result because the rule states that (lower or
> >           higher of two will be the result) and so the offering
> >           party should be able to accept the lower or higher
> >           range as defined by rule. In case the key is dependent
> >           upon some range of fixed values then the negotiation
> >           should be performed as list negotiation and not
> >           numerical negotiation.
> >
> >           This might be what you "conventionally" do - I don't
> >           and that shows that convention like morals are a matter
> >           of geography :-)
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)
> >
> >           The advantage of this set of rules is that it allows an
> >           external observer to know what was selected without
> >           knowing the rules
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this
> >           case, I guess that the external observer has to know
> >           the rules to double check the value is correct or not
> >           The disadvantage is that messages have to be "built",
> >           an additional reject states exists and MOST IMPORTANT
> >           you need both messages
> >
> >           In what I said:
> >
> >           1. The requester sends A=valuex
> >           2. The Responder has to send either nothing (if valuex
> >           is enough on both sides to compute the result like in
> >           the case in which the function is a Boolean AND and the
> >           value is NO) or valuey
> >           3. Both the requestor and responder have to compute the
> >           value (they have to know the rules anyhow) and so does
> >           the external observer
> >
> >           The disadvantage is that the external observer has to
> >           know the rules
> >           The advantage is that there is no reject, in binary
> >           negotiations you can go away with shorter negotiations
> >           and you can set strings at fixed values.
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> >           no reject , but it can be a problem in future .
> >           Consider your example of DataPDULength in your own
> >           message. Suppose offering party sends a value of 16,384
> >           (this is also lowest value it can send) and responding
> >           party responds with 8,192. In this case the offering
> >           party will have to reject the negotiation. So a reject
> >           message is needed in this case also.
> >
> >
> >      Sanjeev
> >       "Sanjeev Bhagat
> >       (TRIPACE/Zoetermeer)"                    To:        "'Santosh
> Rao'"
> >       <sbhagat@tripace.com>            <santoshr@cup.hp.com>, Julian
> >       Sent by: owner-ips@ece.cmu.edu   Satran/Haifa/IBM@IBMIL
> >                                                cc:
>  ips@ece.cmu.edu
> >       30-09-01 16:32                           Subject:        RE:
> iscsi :
> >       Please respond to "Sanjeev       numerical negotiation wording
> is
> >       Bhagat (TRIPACE/Zoetermeer)"     ambiguous
> >
> >
> >
> >      All,
> >
> >      I agree with Santosh that the responding party must respond
> >      the result of
> >      the negotiation as compared with the value from offering
> >      party. All
> >      negotiations in SCSI like (sync, disconnect etc) are also
> >      done the same way.
> >      I also object to Julian's reason of a simple minded target
> >      which wants to
> >      send certain fixed values only. In case a simple minded
> >      target identifies a
> >      value which it cannot support or is less than the value a
> >      target can
> >      support, then there should be a method for target to reject
> >      such a
> >      negotiation and the default values be accepted on both side
> >      as a result of
> >      negotiation.
> >
> >      1 Because even if simple minded target sends its fixed value
> >      which is
> >      greater than the value sent by offering party then the final
> >      result of
> >      negotiation will be taken as ( lesser of the two) and in
> >      this case target
> >      which which cannot support the lower value will produce some
> >      illegal
> >      results.
> >
> >      2. if simple minded target wants to send its own value and
> >      wants it to be
> >      accpeted then the responding party is not negotiating but
> >      forcing the result
> >      on initiator(this method should not be allowed unless
> >      explicitly mentioned).
> >
> >      however if there is another proposal of numeric negotiation
> >      in which the
> >      responding party can force its result to be over ridden by
> >      the offering
> >      party's result then it is acceptable for offering party and
> >      responding party
> >      to send there own supported key-value result and it can then
> >      be computed at
> >      offering party's end.
> >
> >      IMP: (May be I am missing something here) I do not see how a
> >      numeric
> >      negotiation can be rejected. Is it possible to reject such
> >      kind of
> >      negotiaion?
> >
> >      Sanjeev
> >
> >      -----Original Message-----
> >      From: Santosh Rao [mailto:santoshr@cup.hp.com]
> >      Sent: Friday, September 28, 2001 11:15 PM
> >      To: Julian Satran
> >      Cc: ips@ece.cmu.edu
> >      Subject: Re: iscsi : numerical negotiation wording is
> >      ambiguous
> >
> >      Julian & All,
> >
> >      I request the group to take a close look at this negotiation
> >      process
> >      again and [re-]evaluate the alternative being proposed.
> >
> >      Further, it appears that the login stage negotiation  is
> >      also following
> >      the same algorithm as the login key negotiation, wherein
> >      originator &
> >      responder offer their respective values and both sides need
> >      to determine
> >      the result of the negotiation. i.e. both initiator and
> >      target need to
> >      compare their NSG with the other party's NSG and pick the
> >      lower of the
> >      2.
> >
> >      I suggest that both the login key negotiation and the login
> >      stage
> >      negotiation follow the policy that the originator offers a
> >      value and the
> >      responder picks the result of the negotiation based on (the
> >      offered
> >      value & its own value). The value picked by the responder is
> >      sent back
> >      to the originator.
> >
> >      This model has the following advantages :
> >
> >      1) Only one side picks the result of the negotiaton. Hence,
> >      the 2 sides
> >      cannot go out of sync on the value picked.
> >
> >      2) The originator knows the negotiated result at the the
> >      responder since
> >      the responder sends back the result of the negotiation.
> >
> >      3) This model is easier to debug because of (1) & (2).
> >
> >      4) Less code since only 1 party (responder) needs to perform
> >      the
> >      computation to pick the result of the negotiation.
> >
> >      5) This scheme leaves less room for interop problems and
> >      mis-interpretation since it is the more familiar negotiation
> >      technique
> >      that is in use in most other mass storage protocols. (ex :
> >      FC PLOGI, FC
> >      PRLI, etc). From a first reading of the current negotiation
> >      scheme, it
> >      is'nt readily apparent that the currently defined model is
> >      different
> >      from the above and requires both sides to be picking the
> >      result of the
> >      negotiation, instead of just the responder.
> >
> >      Comments ?
> >
> >      Thanks,
> >      Santosh
> >
> 
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################