Re: iscsi : numerical negotiation wording is ambiguous

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

The first & third example below seem illogical. 

The responder should not be sending 24K if the initial
sender has chosen a value of 16K, since there is no
possibility of that 24K being accepted (unless we want
three way exchanges for every negotiation??)   

The problem of a Reject message does not arise since the 
responder should only be choosing something less than 16K.
So I guess this puts me in the "responder selects logic" 
camp.

-Sandeep


Julian Satran wrote:
> 
> An example:
>  08.txt logic
> i->t DataPDULength=16k
> t->i DataPDULength= 24k
> 
> Selected value is 16k
> 
> i->t DataPDULength=16k
> t->i DataPDULength= 8k
> 
> Selected value is 8k
> 
> t->i DataPDULength=16k
> i->t DataPDULength= 24k
> 
> Selected value is 16k
> 
> t->i DataPDULength=16k
> i->t DataPDULength= 8k
> 
> Selected value is 8k
> 
> -----
> 
> Responder selects logic
> 
> i->t DataPDULength=16k
> t->i DataPDULength= 24k
> 
> Error - Initiator Reject - Closes connection
> 
> i->t DataPDULength=16k
> t->i DataPDULength= 8k
> 
> Selected value is 8k
> 
> t->i DataPDULength=16k
> i->t DataPDULength= 24k
> 
> Error Target has to terminate with parameter error
> 
> t->i DataPDULength=16k
> i->t DataPDULength= 8k
> 
> Selected value is 8k
> 
>   "Dev - Platys"
>   <deva@platys.com>                To:        "Julian Satran"
>                            <Julian_Satran@il.ibm.com>,
>   01-10-01 23:46           <ips@ece.cmu.edu>
>   Please respond to "Dev -         cc:
>   Platys"                          Subject:        RE: iscsi :
>                            numerical negotiation wording is ambiguous
> 
> 
> 
> Julian,
> 
> I am not sure why a 'REJECT' is required.
> Can you please explain why is this required?
> 
> I am with Santosh in this.
> 
> >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
> 
> Deva
> Adaptec
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Monday, October 01, 2001 1:28 PM
> To: ips@ece.cmu.edu
> Subject: Re: iscsi : numerical negotiation wording is ambiguous
> 
> 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:                     cc:        "Sanjeev Bhagat
>   santoshr@cup.hp.com   (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>,
>                         Julian Satran/Haifa/IBM@IBMIL
>   01-10-01 20:37               Subject:        Re: iscsi : numerical
>   Please respond to     negotiation wording is ambiguous
>   Santosh Rao
> 
> 
> 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
> ##################################