SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iscsi : numerical negotiation wording is ambiguous




    Well - even I got fed-up with this long thread.

    Here the new text I am suggesting for the negotiations ("vox populi"):

    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.

    For numerical negotiations, the responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result.  Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly.

    For Boolean negotiations (keys taking the values yes or no), the result is a key dependent Boolean function of the two inputs. The negotiation MAY proceed only up to the point where both parties can unequivocally compute the result; continuing beyond this point is OPTIONAL (e.g., if the function is AND and one of the parties says "no" then this may end the negotiation). Both requestor and responder MUST to compute the negotiated value based on the new value(s) exchanged

    The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood".

    The target may offer key=value pairs of its own. Target requests are not limited to matching key=value pairs as offered by the initiator.  However, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request).

    Unless specified otherwise the negotiation process is stateless (based only on newly presented values).


    Comments?
    Julo


    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    Paul Koning <pkoning@jlc.net>

    03-10-01 16:43
    Please respond to Paul Koning

           
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        RE: iscsi : numerical negotiation wording is ambiguous

           


    Excerpt of message (sent 3 October 2001) by Julian Satran:
    > 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

    In most protocols, "responder selects" is used.  And the rule is that
    the responder MUST respond with a value acceptable to both sides.

    Therefore, if the negotiation rule for DataPDULength is to pick the
    smaller of the two values preferred by the two sides, your first and
    third examples would be defective implementations.  Often, protocol
    specs don't say what to do with defective implementations; a typical
    answer is to terminate the conversation, which is a sensible answer.
    Sending rejects is not that useful for defective implementations,
    since there is no reason to assume that they will all of a sudden
    start to act correctly.  Also, it is useful to build in protocol
    mechanisms for bit errors, memory errors, dropped packets, etc. -- but
    it is generally NOT useful to build mechanisms that apply only when
    the other side has a software bug.  I agree with Deva that the
    appropriate response to a protocol violation is to terminate the
    conversation.

    So for "responder selects" examples 1 and 3 should have read like
    this:

    i->t DataPDULength=16k
    t->i DataPDULength= 16k                                  (t wants 24 but 16 is the agreed value)

    ...

    t->i DataPDULength=16k
    i->t DataPDULength= 16k                                  (i wants 24 but 16 is the agreed value)

        paul


    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    Paul Koning <pkoning@jlc.net>
    Sent by: owner-ips@ece.cmu.edu

    03-10-01 16:43
    Please respond to Paul Koning

           
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        RE: iscsi : numerical negotiation wording is ambiguous

           


    Excerpt of message (sent 3 October 2001) by Julian Satran:
    > 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

    In most protocols, "responder selects" is used.  And the rule is that
    the responder MUST respond with a value acceptable to both sides.

    Therefore, if the negotiation rule for DataPDULength is to pick the
    smaller of the two values preferred by the two sides, your first and
    third examples would be defective implementations.  Often, protocol
    specs don't say what to do with defective implementations; a typical
    answer is to terminate the conversation, which is a sensible answer.
    Sending rejects is not that useful for defective implementations,
    since there is no reason to assume that they will all of a sudden
    start to act correctly.  Also, it is useful to build in protocol
    mechanisms for bit errors, memory errors, dropped packets, etc. -- but
    it is generally NOT useful to build mechanisms that apply only when
    the other side has a software bug.  I agree with Deva that the
    appropriate response to a protocol violation is to terminate the
    conversation.

    So for "responder selects" examples 1 and 3 should have read like
    this:

    i->t DataPDULength=16k
    t->i DataPDULength= 16k                                  (t wants 24 but 16 is the agreed value)

    ...

    t->i DataPDULength=16k
    i->t DataPDULength= 16k                                  (i wants 24 but 16 is the agreed value)

        paul

    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    Santosh Rao <santoshr@cup.hp.com>
    Sent by: santoshr@cup.hp.com

    03-10-01 18:26
    Please respond to Santosh Rao

           
            To:        Sandeep Joshi <sandeepj@research.bell-labs.com>, Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        Re: iscsi : numerical negotiation wording is ambiguous

           


    Julian,

    Another value-add of the "responder picks the negotiation result model"
    is that the initiator can use the following "query based" negotiation
    model to always use the values the target is capable of offering :

    I -> T : DataPDULength=?
    T -> I : DataPDULength=64K

    Both sides agree to use a DataPDULength of 64K.

    In the "both sides pick negotiation result" model, the above cannot be
    achieved, since the initiator has to always offer a value.

    Thus, in the "both sides pick negotiation result" model , the above
    example would be :
    I -> T : DataPDULength=8K
    T -> I : DataPDULength=64K
    I -> T : DataPDULength=64K
    T -> I : DataPDULength=64K

    Both sides settle at 64K.

    I suggest that we allow the above "query based model", since this is
    more efficient to use when an initiator has no key limitations and would
    like to use the value a target can offer. In order to allow the "query
    based model", you would need to state in the draft that a key value of
    "?" over-rides the default, implying the target offered value would be
    the result of the negotiation.

    In particular, the "query based model" is quite useful when an initiator
    wishes to function with the target's maximal supported values for keys
    like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T,
    LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any
    limitations on its own key value.

    Comments ?

    Thanks,
    Santosh



    Sandeep Joshi wrote:
    >
    > 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
    > > ##################################

    --
    ##################################
    Santosh Rao
    Software Design Engineer,
    HP-UX iSCSI Driver Team,
    Hewlett Packard, Cupertino.
    email : santoshr@cup.hp.com
    Phone : 408-447-3751
    ##################################

    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    Santosh Rao <santoshr@cup.hp.com>
    Sent by: owner-ips@ece.cmu.edu

    03-10-01 18:26
    Please respond to Santosh Rao

           
            To:        Sandeep Joshi <sandeepj@research.bell-labs.com>, Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        Re: iscsi : numerical negotiation wording is ambiguous

           


    Julian,

    Another value-add of the "responder picks the negotiation result model"
    is that the initiator can use the following "query based" negotiation
    model to always use the values the target is capable of offering :

    I -> T : DataPDULength=?
    T -> I : DataPDULength=64K

    Both sides agree to use a DataPDULength of 64K.

    In the "both sides pick negotiation result" model, the above cannot be
    achieved, since the initiator has to always offer a value.

    Thus, in the "both sides pick negotiation result" model , the above
    example would be :
    I -> T : DataPDULength=8K
    T -> I : DataPDULength=64K
    I -> T : DataPDULength=64K
    T -> I : DataPDULength=64K

    Both sides settle at 64K.

    I suggest that we allow the above "query based model", since this is
    more efficient to use when an initiator has no key limitations and would
    like to use the value a target can offer. In order to allow the "query
    based model", you would need to state in the draft that a key value of
    "?" over-rides the default, implying the target offered value would be
    the result of the negotiation.

    In particular, the "query based model" is quite useful when an initiator
    wishes to function with the target's maximal supported values for keys
    like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T,
    LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any
    limitations on its own key value.

    Comments ?

    Thanks,
    Santosh



    Sandeep Joshi wrote:
    >
    > 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
    > > ##################################

    --
    ##################################
    Santosh Rao
    Software Design Engineer,
    HP-UX iSCSI Driver Team,
    Hewlett Packard, Cupertino.
    email : santoshr@cup.hp.com
    Phone : 408-447-3751
    ##################################

    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>
    Sent by: owner-ips@ece.cmu.edu

    04-10-01 00:27
    Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"

           
            To:        "'Dev - Platys'" <deva@platys.com>, Sandeep Joshi <sandeepj@research.bell-labs.com>, ips@ece.cmu.edu
            cc:        
            Subject:        RE: iscsi : numerical negotiation offering party based computaion         vs  responder based

           


    All,

    Sorry for those who cannot view Excel sheet. you can view the file at the
    link
    http://www.radhekrishna.org/iSCSI/numeric_nego_comparison.htm

    Please dont blame me for my ugly site. It was a very half hearted attempt
    from me long ago. And I am sorry I cant put it on the company website now
    because our system guy has left for the day.

    Sanjeev

    -----Original Message-----
    From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com]
    Sent: Wednesday, October 03, 2001 10:44 PM
    To: 'Dev - Platys'; Sandeep Joshi; ips@ece.cmu.edu
    Subject: iscsi : numerical negotiation offering party based computaion
    vs responder based


    Hello all,

    i just changed the name of the thread, because the thread is now taking
    different directions.

    I am attaching an excel file here in which i have taken 7 different cases to
    show how there could be some mis interpretation when offering party computes
    the individual results. I have taken the example of dataPDuSize because i
    started making my table with this although there is a different thread going
    on to it whether it should be kept in numerical negotiation or not.

    In the table I have tried to take cases where the initiator and target may
    not support some PDU sizes which are lower than the maximum PDU size they
    support.

    Deva: it also tells when a reject might be needed.

    Regards,
    Sanjeev

    -----Original Message-----
    From: Dev - Platys [mailto:deva@platys.com]
    Sent: Wednesday, October 03, 2001 6:14 PM
    To: Sandeep Joshi; ips@ece.cmu.edu
    Subject: RE: iscsi : numerical negotiation wording is ambiguous


    Santosh,

    The point is, if the target is not capable of supporting 16K (it is just an
    example that is being discussed), then it indicates that is what it wants.
    Initiator can close the connection. (No reject is necessary though).

    However, if the target knows it can support the initiator negotiated value,
    it could return it.

    Again, Yes, implicitly it becomes the responder selects logic.

    Deva
    Adaptec


    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Sandeep Joshi
    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
    > ##################################


    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    "ERICKSON,SHAWN (HP-Roseville,ex1)" <shawn_erickson@hp.com>
    Sent by: owner-ips@ece.cmu.edu

    04-10-01 01:48
    Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)"

           
            To:        "'Santosh Rao'" <santoshr@cup.hp.com>, Sandeep Joshi <sandeepj@research.bell-labs.com>, Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        RE: iscsi : numerical negotiation wording is ambiguous

           


    > Another value-add of the "responder picks the negotiation
    > result model"
    > is that the initiator can use the following "query based" negotiation
    > model to always use the values the target is capable of offering :
    >
    > I -> T : DataPDULength=?
    > T -> I : DataPDULength=64K
    >
    > Both sides agree to use a DataPDULength of 64K.

    I like the idea!


    -------------------------------------------------------
    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>
    -------------------------------------------------------

    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    "ERICKSON,SHAWN (HP-Roseville,ex1)" <shawn_erickson@hp.com>
    Sent by: owner-ips@ece.cmu.edu

    04-10-01 01:46
    Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)"

           
            To:        ips@ece.cmu.edu
            cc:        
            Subject:        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
    > > ##################################
    >

    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    "ERICKSON,SHAWN (HP-Roseville,ex1)" <shawn_erickson@hp.com>

    04-10-01 01:48
    Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)"

           
            To:        "'Santosh Rao'" <santoshr@cup.hp.com>, Sandeep Joshi <sandeepj@research.bell-labs.com>, Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        RE: iscsi : numerical negotiation wording is ambiguous

           


    > Another value-add of the "responder picks the negotiation
    > result model"
    > is that the initiator can use the following "query based" negotiation
    > model to always use the values the target is capable of offering :
    >
    > I -> T : DataPDULength=?
    > T -> I : DataPDULength=64K
    >
    > Both sides agree to use a DataPDULength of 64K.

    I like the idea!


    -------------------------------------------------------
    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>
    -------------------------------------------------------

    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    John Hufferd/San Jose/IBM@IBMUS
    Sent by: owner-ips@ece.cmu.edu

    04-10-01 07:57
    Please respond to John Hufferd

           
            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            Subject:        RE: iscsi : numerical negotiation wording is ambiguous

           



    Julian,
    I find your response troubling, perhaps I did not understand what you
    intended to say.  Comments below.


    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136
    Internet address: hufferd@us.ibm.com


    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/03/2001 05:26:58 AM

    Sent by:  owner-ips@ece.cmu.edu


    To:   ips@ece.cmu.edu
    cc:
    Subject:  RE: iscsi : numerical negotiation wording is ambiguous




    An example:
     08.txt logic
    i->t DataPDULength=16k
    t->i DataPDULength= 24k

    Selected value is 16k

    [Huff] If target knows that the Initiator wants 16k, and therefore that its
    24k is not going to be accepted, why did the Target send 24K? [/Huff]

    i->t DataPDULength=16k
    t->i DataPDULength= 8k

    Selected value is 8k

    t->i DataPDULength=16k
    i->t DataPDULength= 24k

    Selected value is 16k

    [Huff] If Initiator knows that the target wants 16k, and therefore that its
    24k is not going to be accepted, why did the Initiator send 24K? [/Huff]


    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"      
                                01-10-01 23:46           <Julian_Satran@il.ibm
                                Please respond to        .com>,                
                                "Dev - Platys"           <ips@ece.cmu.edu>    
                                                                 cc:          
                                                                 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.c              To:        ips@ece.cmu.edu          
         om>                             cc:        "Sanjeev Bhagat          
         Sent by:                 (TRIPACE/Zoetermeer)"                      
         santoshr@cup.hp.co       <sbhagat@tripace.com>, Julian              
         m                        Satran/Haifa/IBM@IBMIL                      
                                         Subject:        Re: iscsi :          
         01-10-01 20:37           numerical negotiation wording is ambiguous  
         Please respond to                                                    
         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
    ##################################








    ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 -----
    John Hufferd@IBMUS

    04-10-01 07:57


            To:        Julian Satran/Haifa/IBM@IBMIL
            cc:        ips@ece.cmu.edu
            From:        John Hufferd/San Jose/IBM@IBMUS
            Subject:        RE: iscsi : numerical negotiation wording is ambiguousLink
     





    Julian,
    I find your response troubling, perhaps I did not understand what you intended to say.  Comments below.


    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136
    Internet address: hufferd@us.ibm.com

    Sent by:        owner-ips@ece.cmu.edu

    To:        ips@ece.cmu.edu
    cc:        
    Subject:        RE: iscsi : numerical negotiation wording is ambiguous




    An example:
     08.txt logic
    i->t DataPDULength=16k
    t->i DataPDULength= 24k

    Selected value is 16k

    [Huff] If target knows that the Initiator wants 16k, and therefore that its 24k is not going to be accepted, why did the Target send 24K? [/Huff]

    i->t DataPDULength=16k
    t->i DataPDULength= 8k

    Selected value is 8k

    t->i DataPDULength=16k
    i->t DataPDULength= 24k

    Selected value is 16k

    [Huff] If Initiator knows that the target wants 16k, and therefore that its 24k is not going to be accepted, why did the Initiator send 24K? [/Huff]


    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>

    01-10-01 23:46
    Please respond to "Dev - Platys"
           
            To:        "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
            cc:        
            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>
    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: Thu Oct 04 20:17:24 2001
7051 messages in chronological order