|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iscsi : numerical negotiation wording is ambiguous
Thanks
Julian, please find my further comments in the message
Sanjeev,
I am not sure
clear I made the tiny diference between what I say and what Santosh
said:
Santosh says:
- a requester sends A=valuex
- a responder sends B=valuey
- 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
- 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)" <sbhagat@tripace.com>
Sent by: owner-ips@ece.cmu.edu
30-09-01 16:32
Please respond to "Sanjeev Bhagat
(TRIPACE/Zoetermeer)"
|
To:
"'Santosh Rao'" <santoshr@cup.hp.com>, Julian
Satran/Haifa/IBM@IBMIL
cc:
ips@ece.cmu.edu
Subject: RE: iscsi :
numerical negotiation wording is 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
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
|
