SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: keys/parameter dependence



    Julian:
    
    The following paragraph from an e-mail from Martins Krikis
    made me realize that the definition of the new C bit
    is not correct, because it goes much further
    than is necessary to solve the "split key" problem,
    and as a result, it opens up a whole new set of problems,
    complicates what was previously a simple situation, and
    breaks a lot of already running and tested code.
    
    
    > "(sent) after" isn't defined. It is unclear
    > whether "in higher numbered bytes within the
    > same PDU" qualifies as "after" or whether only
    > "in a PDU sent at a later time" would. It's
    > probably irrelevant, since due to the introduction
    > of the C-bit, parameters can be accumulated and
    > processed one "batch" at a time, without any
    > specific order within the "batch" and they will
    > quite likely not be processed PDU by PDU.
    > Therefore, the text about them being sent in
    > "the same command" is likely irrelevant, too,
    > since many implementation simply won't check that.
    >
    
    I don't believe the intention of the recent discussion
    that led to the introduction of the C bit was, in fact,
    to allow "batching" or to throw out "ordering" of the
    sending of keys.  However, the definition in Draft 12-95
    sections 9.10.2  and 9.11.2 seems to now allow batching:
    (I agree with John Huffered that Martins' comments about
    "ordering" are not correct in any case.)
    
    Section 9.10.2 C (Complete) Bit:
    "When set to 1, indicates that the text (set of key=value pairs) in
    this Text Request is not complete (it will be continued on a
    subsequent Text Request); otherwise, it indicates that this
    Text Request ends a set of key=value pairs."
    
    (Section 9.11.2 is the same, but with Response substituted for Request.)
    
    The problem I see with this definition of the C bit is that
    the sending side can force the receiving NOT to process
    a PDU containing key=value pairs, even if all those key=value
    pairs are complete within the PDU.  Therefore, the receiver
    is forced to save this PDU (and any number of following PDUs)
    until the sender finally sends C = 0.  In the worst case, the
    sender could send one key=value pair per PDU with the C bit set
    to 0 and the receiver could not reply to any of these until it
    got one with C bit set to 1.
    As the e-mail from Martins indicates, some people are already
    taking this to mean that parameter negotiations will "normally"
    be batched.  Up until the introduction of the C bit, PDUs and keys
    in them were always processed as received, and most code already does
    this, since it is the most logical and efficient way to do it.
    We should still encourage this as the "normal" way of negotiating.
    
    I believe the problem we were trying to solve by introducing
    the C bit was the one where a key was split over a PDU boundary
    -- we were not trying to redesign the negotiation mechanism,
    which was discussed on the mailing list long ago and has been
    working in a lot of running code for the past two plugfests.
    
    Could we therefore please change the definition of the C bit in
    section 9.10.2 to read:
    "When set to 1, indicates that the text in this Text Request
    contains a single key=value pair, and that pair is incomplete
    within this PDU."
    
    (Section 9.11.2 should have the same change, but with Response
    instead of Request)
    
    I believe this corresponds more closely with the description
    in section 4.2 Text Mode Negotiation, where the C bit (flag) is
    clearly tied to the idea of split keys only:
    "Key=value" pairs may span PDU boundaries.  An initiator or target
    having sent partial key=value text within a PDU indicates that more
    text follows by setting the C flag bit in the Text Request or
    Text Response to 1."
    
    Perhaps an additional sentence could also be added to this:
    "The following PDUs should only contain text that completes
    the partial key=value text until after a PDU with C set to 1
    has been sent, at which time new key=value pairs can be sent
    in the next PDU."
    
    I'm not happy about seeing such a major change (C flag bit)
    introduced so late in the process to solve an "almost" non-existant
    problem (split keys).  It is "almost" non-existand because of
    the following considerations (some of which were already
    mentioned on the list and are just summarized here):
    During the login process, the PDU size is 8192 bytes.
    Therefore, except for the long keys during negotiation
    that follows a chosen AuthMethod, there is never a need to split
    keys across pdu boundaries during login --
    even if you negotiate every possible login key
    (except those special keys that occur in security protocols)
    to its maximum length, you do not reach the total of 8192 bytes.
    It is not even close!  Therefore, there is no need for any
    implication that the C bit should appear during this process.
    When those long security keys are needed, the negotiation process is
    in a 1 key over, 1 key back exchange mode, so there is no "batching"
    possible and the split key should in fact be the only key in the pdu.
    Finally, during text exchanges, there only 6 keys that can be
    legally sent (plus the X-extension key): SendTargets, TargetName,
    TargetAlias, TargetAddress, InitiatorAlias, and MaxRecvPDULength.
    None of these can legally have a value greater than 255 bytes,
    which is well less than the minimum PDU size (512 bytes).
    So there is no need to split keys over boundaries during text
    negotiation, except perhaps for the X-extension keys.
    My proposed definition of the C bit as applying only to split keys
    therefore only applies to X-extension keys during text negotiation.
    Since we have had no experience with X- keys, and cannot forsee their
    use, anything we introduce only for them should be the minimum possible.
    
    In summary, I would like to see as little disruption as possible
    to the key negotiation scheme which has been stable for a long time,
    especially since anything we introduce will be needed only in very
    limited circumstances.  I believe my modification to the definition of
    the C flag accomplishes that, without introducing any new, false
    perceptions about "batching" and "ordering".
    
    Thank you for your consideration.
    
    Bob Russell
    InterOperability Lab
    University of New Hampshire
    rdr@iol.unh.edu
    603-862-3774
    
    


Home

Last updated: Mon Jun 03 17:18:37 2002
10471 messages in chronological order