|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iscsi : numerical negotiation wording is ambiguous
> The first & third example below seem illogical.
I agree.
> So I guess this puts me in the "responder selects logic"
> camp.
Same here.
-Shawn
-------------------------------------------------------
Shawn Carl Erickson (805) 883-4319 [Telnet]
Hewlett Packard Company OV NSSO Joint Venture
Storage Resource Management R&D Lab (Santa Barbara)
-------------------------------------------------------
<http://ecardfile.com/id/shawnce>
-------------------------------------------------------
> -----Original Message-----
> From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com]
> Sent: Wednesday, October 03, 2001 7:29 AM
> To: ips@ece.cmu.edu
> Subject: Re: iscsi : numerical negotiation wording is ambiguous
>
>
>
> 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
> > ##################################
>
Home Last updated: Wed Oct 03 20:17:20 2001 7022 messages in chronological order |