|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iscsi : numerical negotiation wording is ambiguousSanjeev, You are just missreading my text. In your example there is no need for a reject. Both parties will KNOW that the value selected is the lower of the 2 i.e. 8192. There is no reject. Julo
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
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 Julian Satran wrote: > > Santosh, > > I understood what you wording means but I am not sure that we want all the > side-effects. > The negotiation as defined now allows both parties requester or responder > to state their wishes and the LAW > insatiate the result in both. > > Your wording means that the responder selects the value according to the > rule. What if the responder is either a rogue or > just a simple minded target. Let me give an example: > > I am building a simple minded target that has an 8K buffer and says always > (has it wired) DataPDULength=8192 > in its first Login response (that is his buffer). > > If an initiator sends him as a "offer" or as a "responder" 16192 then with > the current wording things are fine and both will > have settled to 8192. > > If the initiator sends an offer of 4096 and the target gives his (only > thing he knows) 8192 it is still fine - both select 4096. > > With your wording some of the negotiations will fail since you assume that > the rule should be expressed in building the answer and not in selecting > the result. > > In the end in both case you have to do selections at both target and > initiator but the current rule enables simple-minded prewired messages > while your does not (the responder message defines the selection and the > offerer has to check it). > > Sorry for this long message for such a simple question. > > Julo > > > Santosh Rao > <santoshr@cup. To: ips@ece.cmu.edu > hp.com> cc: > Sent by: Subject: Re: iscsi : numerical negotiation wording > owner-ips@ece. is ambiguous > cmu.edu > > > 26-09-01 23:16 > Please respond > to Santosh Rao > > > > Julian, > > What is the responding party supposed to offer ? Is it supposed to > determine the result of the > negotiation (higher or lower value, as the case may be) and send that as > its response ? > > Or, is it supposed to send in its numerical value and the initiator picks > the higher or lower of > the 2 ? > > This does'nt come across clear enough in the definition and is open to > mis-interpretation. Please > see the suggested re-word in its place. > > Thanks, > Santosh > > Julian Satran wrote: > > > Santosh, > > > > I am missing something. The rule states what value both parties should > have > > after both have seen the two values. > > Obviously we assume that no error occurs and the responder value is seen > y > > the offering party or the negotiation fails. > > > > What exactly is ambiguous about it? > > > > Julo > > > > > > Santosh Rao > > <santoshr@cup. To: ips@ece.cmu.edu (ips) > > hp.com> cc: > > Sent by: Subject: iscsi : numerical > negotiation wording is > > owner-ips@ece. ambiguous > > cmu.edu > > > > > > 26-09-01 19:59 > > Please respond > > to Santosh Rao > > > > > > > > Julian & All, > > > > The definition of numerical negotiation in Section 2.2.4 of Rev 7.97 > > reads : > > > > "In numerical negotiations, the offering and responding party state > > a numerical value. The result of the negotiation is key dependent; > > frequently the lower or the higher of the two values is used." > > > > The above definition is ambiguous, since it does not specify whether it > is > > the originator or the responder that computes the result of the > > negotiation. > > > > i.e. Is it the responsibility of the target to pick the higher or lower > of > > the 2 values and respond with the result of the negotiation ? > > > > OR : > > Is it the originator that has to pick the result of the negotiation > > based on the key it sent and the key it got back ? > > > > I would suggest that the wording be clarified to indicate that the > > responder picks the result of the negotiation and sends this result back > > in its response for this key. > > > > Perhaps, some re-wording along the following lines may be in order : > > > > "In numerical negotiations, the offering party states a numerical > > value, and the responding party states the result (operational value) > > after the negotiation. The result of the negotiation is key > > dependent; responder determines it based on the lower or the higher > > of the two values - offering party's value, and what the responder > > can support." > > > > Comments ? > > > > Regards, > > Santosh > > > > -- > > ################################# > > Santosh Rao > > Software Design Engineer, > > HP, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################# > > #### santoshr.vcf has been removed from this note on September 27 2001 by > Julian Satran -- ################################## 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: Mon Oct 01 15:17:21 2001 6933 messages in chronological order |