|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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> Sent by: santoshr@cup.hp.com
01-10-01 20:37 Please respond to Santosh Rao
| To:
ips@ece.cmu.edu cc:
"Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>,
Julian Satran/Haifa/IBM@IBMIL 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
> "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: Mon Oct 01 18:17:15 2001
6949 messages in chronological order
|