Re: [iSCSI]: Key negotiation procedure proposal

[Martins Krikis <mkrikis@yahoo.com>]

--- Luben Tuikov <luben@splentec.com> wrote:
> > > If a Responder replies with Reject, then the
> Originator
> > > SHOULD NOT renegotiate the rejected key.
> > 
> > Does it mean it should not send or does it mean
> "should not send
> > with a non-reserved value"?
> 
> It means that the Originator SHOULD NOT send any
> more offers. (key=another-value(s))

I knew. I should stop putting requests for more
precision in the form of questions to which I know
the answers. My fault.

> > There is the problem that it may not fit.
> 
> Yes, Randy mentioned this already and gave an
> excellent
> example.
> 
> Well, this is an open question. Anyone?

We can mandate that if the DataSegment does not 
end with a \0 (which would mean that all included
key=value pairs are complete and terminated),
then it should not be processed yet, but the
next piece waited for to be concatenated with.
And we'd drop the need to send PDUs in the other
direction. This would be even better achieved
with a flag in the header.

I.e., if a (new) flag is set in the header of a
Text/Login Request/Response PDU, then it means
that more such PDUs are coming and their data
is to be concatenated together (once the flag
is unset in the last one) before processing.
This would in fact allow a nice separation of
the negotiation logic from the en/de-capsulator.
(For example, if willing to send lots of values,
the sender just dumps them to the encapsulator
instead of worrying how many will fit and how
many will need their state adjusted to be sent
next (can't just mark them sent yet, because
there may be surprises if they arrive)).

In general the possibility of split data is a
pain and any way to alleviate this pain would
be very welcome by many, I suspect.

> > > If an Originator finds the response to an
> offered key=value
> > > pair to be unacceptable, it SHOULD send Reject
> and close the
> > > connection.
> > 
> > But then the Responder (who both Reject-ed and
> responded to the key)
> > must remember that it not only sent the key but
> also rejected the
> > key, i.e., sent a value that does not necessarily
> fit in the selection
> 
> NO! it must only remember the value of the key it
> sent!

You don't have to object yet, it gets clearer at
the end of my paragraph.

> The Originator will 1) close the connection with
> Reject,
> 2) accept the value quetly. (I can know, implied
> rule 1,
> but we have to STOP somewhere or we'll never get to 
> FF phase :-))

Stopping is not a problem. There is no renegotiation.
Anyway, I've lost track here a little of what you're
saying.

> > rules and which is not guaranteed to be liked by
> the Originator,
> > because if it is not liked, this Originator most
> likely will
> > send a Reject, which is not to be treated as a
> no-renegotionation
> > violation but just as a harmless little Reject.
> 
> key=Reject is never considered renegotiation, since
> there is no
> valid value being offered!

For me seeing a key twice raises big red alarms.
I look at the key first, IMHO, naturally.
key=Reject is also wrong as an offer, so in order
to allow for receiving it (w/o big red alarms either
due to renegotion or due to "Reject in offer"), we
have to prepare first. So we need more state than
currently (for the ultra-fine implementations
at least). And yes, connection will have to be
closed, yet I'd like to know precisely the reason
why.

> Oh, well, there is the ``simple implementation''
> rule.
> 
> Please remember that there is always the ``simple
> implementation''
> rule (compatible with ``regular implementation'').

And it is compatible with the current state of
affairs as well. In fact, it is subsumed by the
current protocol. It already allows Reject-ing a
key and then closing the connection. Wait, there
might be nuances for text vs. login. Anyway, very
minor differences if any between your "simple 
implemention" and what would be currently already
allowed.

> If the people feel comfortable with the logic then,
> some
> may implement ``simple'' others may implement
> ``regular'',
> both will interoperate and will get the job done.

Yes, but "regular" could, IMO, stay as it is.
I now hold the view that there are no renegotiations
possible. If other people don't, we have to keep
asking Julian to clarify yet again and put it in a
very visible place in the draft. 

> > O: k=u,v,w                   (I want (in order of
> preference) u, v or w)
> > R: k=Reject                  (But I hate all of
> those)
> > O: k=?                       (What do you like
> then?)
> > R: k=x,y,z                   (I like (in order of
> preference) x, y and z)
> 
> This will never work since  ``k(R) Intersection k(O)
> = Empty''.
> If it did, then O: cheated in its offer! (and should
> be banned
> from operating ;-))

I didn't say it would work. I know the intersection
is empty. I tried to show that learning what values
the other side may like is more naturally done with
inquiries than with forced depositions. The only
improvement that I see from your proposal is that in
case a value gets Reject-ed, the sender knows what
values the other side would have liked. (Because
most other things have been taken care of, I think.)
But that effect can be achieved by an inquiry, not
by protocol changes that require more state.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer




__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com