Re: iSCSI: Negotiation clarifications still needed

["Mallikarjun C." <cbm@rose.hp.com>]

Martins,

Comments in the same order.

1. Julian may be adding wording for this.

2. Seems to me that we need to stipulate that only key values 
    may straddle PDU boundaries - key names (ideally inclusive 
    of "=") shall not.  That should avoid requiring blank PDUs.

3. I don't have a strong opinion on this.  I don't believe this can 
    cause interoperability problems; OTOH, I don't care if the responder
    isn't that liberal.

4. Julian and I discussed this scenario a while ago.  As you precisely
    described, only a non-stop dialogue can be reliable and we can't
    afford a non-stop dialogue.  I suppose one can recover the StatSN
    with a SNACK in FFP, or terminate the connection upon a timeout.
--
Mallikarjun

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


----- Original Message ----- 
From: "Martins Krikis" <mkrikis@yahoo.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, May 24, 2002 12:38 PM
Subject: 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
>