Re: iSCSI - negotiating against defaults/renegotiation the same key

["Julian Satran" <Julian_Satran@il.ibm.com>]

Mallilkarjun,

David only suggested that whoever desires to be certain about values has 
to negotiate them.
This a reasonably conservative option and does not exclude defaults but 
excludes negotiating "against defaults"
that I find also excessively complicated.

Also negotiation can be originated at target and initiator.

I think also that A (negotiate by making the full exchange) is the 
preferred alternative.

As for the ugly text - if we get to have a "universal" PDU length 
(including text) we might end up having text requests (and/or responses) 
that are so short that most of the key=value pairs are not finished in one 
exchange (and then we have empty PDU's in the opposite direction).  I 
would rather see a 4k text block and key=value not spanning PDU's.
But this has its own drawbacks (framing, not uniform etc.).

Julo






"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu
17-10-01 04:05
Please respond to cbm

 
        To:     ips <ips@ece.cmu.edu>
        cc: 
        Subject:        Re: iSCSI - negotiating against defaults/renegotiation the same key

 

Julian,

As I see it, there are at least two options in 
negotiating for defaults -
                 A) As David implied in an earlier message,
           mandate every defined key to be negotiated.
           That leaves target to originate only 
           vendor-unique keys, to be responded in
           vendor-unique ways.
        B) Leave the defaults in, and rely on the T-bit 
           to prompt target to originate non-default key 
           values.  We would then have to specify that
           an initiator MUST explicitly state "can 
           accept any value" when it really is the 
           case (to prevent the case you're concerned
           about).  IOW, non-mention of a text key 
           should have the exact semantics of an 
           explicit offering of the default.

I am mildly partial towards A.

Regarding re-negotiating the same key, I guess I 
would prefer (b) - mandating a connection to be
dropped. [ BTW, I am not sure (c) is correct -
both parties should know when a negotiation 
started, to potentially discard the results of
a partial negotiation on a failure. ]

On the topic of differentiating text exchanges from
that of others, I would vote no - so I guess I support
your option (a).   Please comment how it does make
the negotiation more complicated.

Regards.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668          Hewlett-Packard, Roseville.
cbm@rose.hp.com


Julian Satran wrote:
> 
> Dear colleagues,
> 
> I think that my previous proposal about negotiating against defaults is
> flawed.
> I was based on the simple-minded assumption that after the initiator has
> said all he had to say (as evidenced by the T=1) the target may assume 
that
> the values the target puts forward are against default. I even prepared 
a
> text in
> 5.3 that read:
> 
>    When the initiator issues a login request with the T bit set to 1 the
>    target MUST assume that this request includes also an "imaginary
>    content".  The "imaginary content" consists of key=value pairs 
including
>    all the operational keys that have a default value and where not sent
>    yet by the initiator during the operational parameter negotiation. 
The
>    values in the "imaginary content" are the key default values.  This
>    enables an initiator to avoid sending all the defaults while the 
target
>    may negotiate as if they where sent.
> 
>  But that was wrong. Here is a simple example:
> 
>  A simple initiator may issue a first login entering the operational
>  negotiation and having T=1 and nothing beyond the 2 names:
> 
>  I->T Iname... Tname
> 
>  This means only that he does not care about things like MaxBurst and is
>  content with defaults.
> 
>  The target (in my proposal prompted by Santosh's request) can't do
>  anything but lower the value while under our simple rule of self 
contained
>  negotiations he could ask for a burst increase and the negotiation 
could
>  have proceeded.
> 
>  For this (and a several other scenarios that  you can easily build) I
>  suggest we stick with our "old" rule that a negotiation must be 
completely
>  "self contained".
> 
>  Now about the other two subjects:
> 
>  1-Multiple negotiations on one key - we may choose one of the following
>  ways out:
> 
>    a)say that both initiator and target MAY drop the login if that 
happens
>    (and close the connection)
>    b)say that both initiator and target MUST drop the login if that 
happens
>    (and close the connection)
>    c)say that this is legitimate (a negotiated parameter change due to a
>    later change not know when the negotiation started)
>    d)say that the whole sequence of Login request/responses is a a 
"single
>    single virtual exchange" and the last value is the single one that
>    counts in every direction - this one is somewhat related to the 
length
>    question but does not allow branching decisions
> 
>  I am would favor a)
> 
>  2. Text block length - we gave away (for a while) on our 4k text 
messages.
>  That makes negotiation difficult and might somehow help some of the
>  framing schemes:
> 
>  I think we may want to do one of the following:
> 
>    a) mandate that the default 8k is valid during login and change only 
at
>    end of login
>    b) get back to a separate length for text and fix it at 4 or 8k (not
>    ideal for framing)
> 
>  Option a may solve the login issue but leaves us with an ugly text
>  negotiation.
> 
>  Option b will require the framing folks to come up with a solution 
(works
>  with markers though).
> 
>  I am in favor of b (a different and predefined length for text buffers)
>  and return to the "complete" negotiation buffers
>  that raise far less logical problems that the concatenation scheme we 
are
>  (temporarily in).
> 
>  Julo