Subject: Re: iSCSI: keys/parameter dependence

From: "Robert D. Russell" <[email-masked]>
Date: Sun, 2 Jun 2002 15:12:08 -0400 (EDT)

Hi Pat:

Comments in text below.

> The part that might cause interoperability problems is different
> interpretations of which parameters action or acceptance is dependent on
> others.

I agree -- see below.

> For instance, does the sentence mean that InitialR2T should be sent
> before FirstBurstSize and that FirstBurstSize doesn't need a response when
> the response to InitialR2T was Yes?

See my responses to Mike Donahoe and Martins Krikis.  In particular,
an offered key ALWAYs requires a response (unless this happens during
login, in which case the responder can also just close the connection).
The response can be Reject or NotUnderstood or Irrelevant in certain
defined circumstances, but there must always be a response.

> If the sentence is left in, then it should be clarified by adding something
> such as:
> "The definition of a key specifies whether the key is dependent on any other
> keys."

I believe the sentence should be left in and its intent remain unchanged.
However, clarification would certainly be desirable, and would probably
remove a lot of the current uncertainty.

> and if any of our current keys are dependent, add to those keys
> "This key is dependent on <key names>."
> If none are currently dependent, it would be reasonable to add to 11
> "Currently,
> no Login/Text Operational keys are dependent."

There are dependencies, so such a statement cannot be added to section 11.

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.

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."
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"."

Besides these two dependencies just mentioned,
I am aware of two other dependencies, and it would certainly would not
hurt to have all these made explicit in the appropriate sections of the
standard.  If anyone else has other dependencies to add, we should
all know about these now! :)

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).

2. Since the default value of OFMarker (IFMarker) is No, an offer
of OFMarkInt (IFMarkInt) without a previous explicit offer of
OFMarker=Yes (IFMarker=Yes) MAY generate the reply
OFMarkInt=Irrelevant (IFMarkInt=Irrelevant) -- it can, of course,
also reply with a valid value or with "Reject", as specified in
section A.3.2.
A similar reply of OFMarkInt=Irrelevant (IFMarkInt=Irrelevant) MAY
also be generated if the previous explicit offer of OFMarker=Yes
(IFMarker=YES) was refused by a reply of OFMarker=No (IFMarker=NO).

Best,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

---

From: Martins Krikis <[email-masked]>
Date: Mon, 3 Jun 2002 14:44:29 -0700 (PDT)

> 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.)

> 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.

> corresponding OFMarker (IFMarker) key value to

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.

> (alternatively, a valid value can also be given in

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