Re: iSCSI: keys/parameter dependence

[Martins Krikis <mkrikis@yahoo.com>]

--- "Robert D. Russell" <rdr@io.iol.unh.edu> wrote:

> The existence of a dependency between FirstBurstSize
> and
> MaxBurstSize is already clear from the statement in
> section 11.15:
> "FirstBurstSize MUST NOT exceed MaxBurstSize."  My
> earlier e-mail to Mike
> Donahoe details this dependency.

I've already said that looking at values to determine
the order is very, very ugly. I don't think we need
order at all. Check for consistency before commit,
that's when you have to look at all keys anyways,
to see which ones are lacking responses or haven't
been negotiated, etc. Let's not put extra burden
of checking dependencies at key processing time.
It's simplest to be able to decide on the value
of each key without having to look at the others.
(I'm not talking about security stage though.)

> The existence of a dependency between OFMarker and
> OFMarkInt, and between
> IFMarker and IFMarkInt, is implied by the statements
> in section A.3.2:
> "When the interval is unacceptable the responder
> answers with
> "Reject".  Reject is resetting the marker function
> in the spcified
> direction (Output or Input) to No."

No it isn't. IMO, it is resetting the marker interval
to its previous value, which is likely the default
value. I believe it's perfectly legal to negotiate
the marker interval but to not turn on marker use,
or to turn on the use but stay with current (default)
values for the interval. If one side can't  tolerate
the other's  Reject (i.e., can't live with the
default value), it is welcome to bail and try next
time w/o markers. BTW, we could use 0 here as a 
special value, meaning that markers are not in use,
then we wouldn't need the boolean keys for
markers.

> This last sentence should probably be reworded to
> say:
> "A response value of "Reject" to an OFMarkInt
> (IFMarkInt) key resets the
> corresponding OFMarker (IFMarker) key value to
> "No"."

No, thank you. I would prefer if Reject meant the
same as with the other keys, i.e., negotiation
failed for this key, let's stick with the old
value, or bail if we must.

> 1. The table in section 11.12 describes the action
> taken on the four
> combinations of InitialR2T = Yes/No and
> ImmediateData = Yes/No.
> The combination InitialR2T=Yes and ImmediateData=No
> means "Unsolicited
> data disallowed".  Therefore, FirstBurstSize becomes
> "Irrelevant" for
> this combination.  This means that if FirstBurstSize
> is offered after
> an offer of ImmediateData=No which is accepted, and
> either an explicit
> offer of InitialR2T=Yes which is accepted or no
> explicit offer of
> InitialR2T (in which case the applicable default
> value is Yes),
> then a reply of FirstBurstSize=Irrelevant MAY be
> returned
> (alternatively, a valid value can also be given in
> the reply).

OK, a dependency. Not of the simplest kind, of course.
Does it impose order? What's the harm if I send
FirstBurstSize before those other two keys?
Isn't it simpler to negotiate a variable that
ends up unused than to worry about whether
it should or should not be sent after some other keys?

Martins Krikis, Intel Corp.

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


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com