SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Negotiation clarifications still needed



    On Sat, 25 May 2002, Julian Satran wrote:
    
    > I agree with Mallikarjun on all but one point - requiring a key not to
    > straddle PDU boundaries.
    > This list had a long debate on the subject. We thought (initially) that
    > not having any pair straddle PD boundaries is the best thing to do and we
    > had it untill it became obvious that we have to support very short PDUs.
    > The we went for allowing spanning and the scheme we had in  mind was a
    > sender preparing its strings and chopping them into PDUs without any
    > parsing and state. What you suggest now is parsing at send and that may
    > add unnecessary complexity - and I really don't see why.
    
    I'm going to try and explain why; to answer the question in the end of the
    above paragraph.
    
    It's to avoid corner cases while doing what you say above, "preparing its
    strings and chopping them into PDUs."
    
    The simplest thing in my mind is to:
    
    1) read the other side's offers into a buffer
    
    2) parse that buffer generating responses to another buffer
    
    3) send the output buffer
    
    Does that make sense? You don't have to agree, just does it make sense?
    
    The problem I see with what Pat described is that if you are in
    operational negotiation and have more than 1 PDU worth of data, you will
    be receiving input while you're in step 3. You have to be able to re-enter
    steps 1 & 2 before you can finish step 3.
    
    The bit about sending empty PDUs is an effort to avoid that. We are either
    in a sending-negotiation-text mode, or a parsing mode. We don't have to
    worry about strings being partially there, since we don't process until
    they are. We also don't have to worry about if our key/value pairs
    cross a PDU. The parser/negotiatior is MUCH simpler; it doesn't have to
    deal with all of that.
    
    Letting the target answer while the initiator is trying to send an
    extended PDU adds the following complications (AFAICT):
    
    1) initiator has to make sure a key and the '=' don't get split on a PDU
    boundry.
    
    2) if an initiator fills up a PDU, it has to stop processing & wait for
    the response. It also has to remember where it is so that it can finish
    sending that key/value next time.
    
    3) The target has to detect a split key/value pair on in-bound, and a)
    store the received text, and b) remember not to offer said key or any
    others.
    
    4) The target ALSO has to make sure ITS response doesn't fill up a PDU. If
    it does, it has to remember where IT is and that it has more to send.
    
    That's a lot of complexity and saved state. At least in my mind.
    
    That's the advantage I see of blank PDUs; we avoid all of the above
    complications.
    
    Truth be told, the corner cases probably don't apply at present. What we
    have (and are talking about) will work for security negotiation (we have
    to wait for the key to make it across) and for operational negotiation
    (since I don't think we have 8k worth of negotiation data). So for now the
    common case (no large vendor extentions) isn't going to tickle this set of
    problems.
    
    Does the statement of the perceived problem make sense, even if the
    opinion of the WG is to not use the empty PDUs? I would feel much
    comfortable with deciding to not use empty PDUs if folks said they
    understand the above point and they choose to address the problems
    differently.
    
    Thoughts?
    
    Take care,
    
    Bill
    
    


Home

Last updated: Tue May 28 16:18:41 2002
10353 messages in chronological order