Subject: Re: iscsi : numerical negotiation wording is ambiguous

From: Santosh Rao <[email-masked]>
Date: Mon, 01 Oct 2001 12:06:48 -0700

Sanjeev,

I do not believe your example is in line with the discussion. I'd rather
you considered the case of an FC initiator that got back a PLOGI
response with parameters that are not acceptable for that initiator. Do
you expect the initiator to send a LS_RJT to the target ??? 

I would hope not :)

The FC initiator would give up on that Nx_Port and move onto another
one. Ditto for iSCSI. Either re-negotiate parameters, or close the TCP
connection. REJECTs are only sent from targets to initiators.

Regards,
Santosh

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> 
> Julian, Santosh,
> 
> Here is what i have to say
> 
> In either of the cases reject message is not needed if there is no double
> check required.
> 
> A reject is needed in both cases to allow some flexibility and i will give
> you an example for this
> 
> All SCSI devices today available have Sync options for more than 10MB/sec.
> 
> Consider a chip designed which works fine for sync negotiation rate of
> upto40MB/sec but misbehaves or behaves illegally for sync options less than
> 10 MB/sec. In such case a device driver for such a chip will start
> negotiating with the SCSI device for 40 MB/sec. If the SCSI device returns a
> value of 8MB/sec then in this case the device driver must send a reject
> message for sync negotiation. (although it is an illegal condition but it
> still allows room for slightly misbehaving devices to operate properly in
> Non-SYNC mode). This is my basis of saying that we must have a reject
> message in both cases although it is strictly not required.
> 
> Sanjeev
> -----Original Message-----
> From: Santosh Rao [mailto:[email-masked]]
> Sent: Monday, October 01, 2001 8:38 PM
> To: [email-masked]
> Cc: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Julian Satran'
> 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
> 

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
Date: Mon, 1 Oct 2001 20:47:44 +0200

Julian, Santosh,

Sanjeev
-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Monday, October 01, 2001 8:38 PM
To: [email-masked]
Cc: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Julian Satran'
Subject: Re: iscsi : numerical negotiation wording is ambiguous

Julian & Sanjeev,

Julian :

Thanks,
Santosh

> Thanks Julian, please find my further comments in the message
> 
>      From: Julian Satran [mailto:[email-masked]]
>      Sent: Sunday, September 30, 2001 6:07 PM
>      To: [email-masked]
>      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
>           message is needed in this case also.
> 
> 
>      Sanjeev
>       "Sanjeev Bhagat
>       (TRIPACE/Zoetermeer)"                    To:        "'Santosh Rao'"
>       <[email-masked]>            <[email-masked]>, Julian
>       Sent by: [email-masked]   Satran/Haifa/IBM@IBMIL
>                                                cc:        [email-masked]
>       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
> 
>      Sent: Friday, September 28, 2001 11:15 PM
>      To: Julian Satran
>      Cc: [email-masked]
>      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
>