SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: Negotiation clarifications still needed



    The previous thread went on too long, but since it
    has now quieted down, I'll conjecture that the
    following are the aspects that still need to be
    addressed.
    
    1. Not everybody seemed to have noticed that it is
       NOT legal to send the same key again, if it
       has once been negotiated (including negotiations
       that end with a reserved value (Reject, 
       Irrelevant or NotUnderstood).
    
    I think it would benefit the draft to add the
    sentence that Pat proposed to paragraph 5 or page
    72 in 12-92: "Sending the key again would be a
    re-negotiation". That I think would make it crystal
    clear.
    
    2. When the key=value pairs that Originator is
       sending are broken across multiple PDUs, it
       is not clear whether the Responder may start
       responding to the keys as soon as it receives
       them or whether it should send blank PDUs back
       (as in the example on page 164 of 12-92) until
       it gets a PDU, the data part of which ends in
       a NUL byte (thus signaling that there are no
       broken key=value pairs at the end of it).
    
    I am proposing that the draft should make it explicit
    that only blank PDUs are to be sent. This allows
    decoupling of key=value generation from
    their encapsulation in PDUs (i.e., the generating
    logic need not worry about whether a key=value
    pair will fit and go out in this PDU or has to
    be retained to go out in the next). I can explain
    in detail why this is important (it has to do
    with teh possibility of receiving the "just-about
    outgoing" keys) but I'm keeping this "brief".
    
    Furthermore, it is my feeling that instead of
    checking the last bytes of a PDU for NUL, it
    would be better if the end-of-data was marked by
    a flag in the header. This way encapsulation will
    be simpler---just put as much data in the PDU as
    fits there and raise the flag if it isn't all,
    instead of checking whether it ends in a NUL and
    possibly shortening data to make it not end like
    that.
    
    3. There is an opinion that on page 73 of 12-92,
       the phrase that says "or the responder may
       select an admissible value" is in contradiction
       to the very next sentence. There is also an
       opinion that this phrase is entirely unnecessary
       and detrimental to achieving broad 
       interoperability (I call it "cutting slack to
       misbehaving or incompatible originators").
    
    I don't have a suggestion since I consider the
    "feature" that this phrase allows of little 
    importance to a properly built iSCSI node.
    
    4. This is new. When doing Text Request/Response
    negotiations (i.e., in FFP), it seems 
    that the Initiator commits to the new values
    when it receives a response from the Target with
    the F bit set. It is unclear when the Target should
    commit. Should it switch to using the new values
    as soon as it sends its response with the F-bit
    set, or should it do so only when it knows that
    the Initiator received its response? 
    
    Commiting right away is simpler and since responses
    with F-bits set have TTT=0xffffffff and thus
    may not be reset, sounds plausible. If the
    values have importance on the next reception,
    it may also be important to commit timely. However,
    what if the Initiator doesn't get this response? 
    Target now has committed, Initiator hasn't. Committing
    later puts the burden on Initiator to send something
    effectively telling "I've received your final
    response". Otherwise the Target will time out and
    not commit. This response can get lost too.
    
    Basically, it is beginning to look a bit like
    (what was it called?) "distributed consensus problem"?
    I think it goes like this:
    
    Two generals that are on oposite sides of the
    enemy want to synchronize their attack, and
    start sending messengers through with messages
    like 
      "attack at dawn->", 
      "<-ok, attack at dawn",
      "I know you know we attack at dawn->",
      "<-, I know you know I know we attack at dawn",
      etc., etc., ...
    But at no point can they commit yet...
    
    Is anybody else worried about this?
    Anyway, so when should a target commit? Page 83
    of 12-92 is the relevant reference.
    
    Thanks,
    
      Martins Krikis
    
    Disclaimer: these opinions are my own and may
                not be those of my employer.
    
    
    __________________________________________________
    Do You Yahoo!?
    LAUNCH - Your Yahoo! Music Experience
    http://launch.yahoo.com
    


Home

Last updated: Fri May 24 20:18:35 2002
10315 messages in chronological order