Re: iSCSI: keys/parameter dependence

[Martins Krikis <mkrikis@yahoo.com>]

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

> However, there ARE dependencies between operational
> parameters that cannot be ignored, such as the one
> Mike mentioned

I should have been more precise. I meant "order
imposing dependencies". You might say "is there
any other kind?", and I would say "yes" and be very
sorry for not CC-ing you on my previous post sent
to the list. I'm sorry already.

> -- FirstBurstSize and MaxBurstSize are dependent
> because of the
> requirement in section 11.15: "FirstBurstSize MUST
> NOT exceed
> MaxBurstSize."  See my e-mail response to Mike for
> details
> on that dependence. 

I saw it. I consider it unbelievably ugly to have to
look at the values in order to figure out ordering
requirements. I prefer ignoring ordering completely
and check for overall consistency before commit.

> > "(sent) after" isn't defined. It is unclear
> > whether "in higher numbered bytes within the
> > same PDU" qualifies as "after" or whether only
> > "in a PDU sent at a later time" would.
> 
> I don't see this, and I agree with John Hufferd's
> response
> to this that "previous" is obviously "previous",
> whether in
> the previous PDUs (because the current PDU was
> delivered
> after them) or in the same PDU 

Just because your interpretation matches John's
doesn't mean that it has been unambiguously defined
and that everybody will see it that way. The
suspicion that may be, just may be, "after" meant
"in a later PDU" was made stronger by the sentence
that talked about keys sent in the same "command"
(i.e., PDU).

> (because key=value
> pairs
> are naturally scanned from the beginning of a PDU's
> data segment,

Not if we don't have a C-bit and have to start
from the end to see if the last pair is split or full.

And natural to one might be unnatural to another.

> and if nothing else, pairs had to be put into the
> data segment
> in that order, 

What order? Previous coming before after?
That order only appears once I've put something
in the data-segment, and I could put pairs
in there in any way I want...

> This is a non-issue.

It's a good thing we got it clear what "after"
means, now I'll just ask why is it important...

> I don't see this either.  Nowhere does the newly
> added text
> describing the C-bit say anything about doing away
> with the
> specific order of the key=value pairs within the
> "batch".

Nowhere does it say anything about the order.
I may prefer to process all booleans first, for
example. I may even find each pair going backwards
in the PDU...

> Why should it -- even if you don't process PDU by
> PDU you still
> have to process batch by batch,

batch by batch, yes, absolutely.

> a batch still has to
> be scanned
> to find key=value pairs, and the natural way to scan
> is from the
> beginning of the batch, 

not necessarily.

> since the next key starts
> after the
> delimiter of the previous key in the batch.

or the previous value (or pair) ends 
before the delimiter of the next key...

> This is also a non-issue.

As long as somebody doesn't impose processing
order on my implementation.

> > Therefore, the text about them being sent in
> > "the same command" is likely irrelevant, too,
> > since many implementation simply won't check that.
> 
> "command" should simply be replaced by "batch" or,
> to be more consistent with the rest of the wording
> in the
> standard, with "set of key=value pairs".

Why does it even matter whether a key has been
sent in the same "batch" or even the same PDU as
another one? Either the value of one may imply
the value of another, or not. But why does this
sentence single out keys sent in the same "command"
("batch", whatever)? 

> However, see my earlier e-mail to Julian stating my
> concerns over the use of the C-bit for "batching".

I've seen it and still think that batching of keys
is a great way to simplify their processing.

> > But what's really dangerous here is that an
> > implementation that perceives some parameters
> > as dependent may take the "might imply" text
> > as an endorsement for sending back less key=value
> > pairs than was received, which could make the
> > other side never commit due to missing responses.
> > We certainly don't want to allow for such a
> > non-interoperability in the specification.
> 
> 
> Certainly not, and nowhere can I find anything in
> the standard
> that implies responses can ever be omitted.

Alright. Then let's just get rid of this sentence
because it does make it sound like may be, just may
be, responses can be omitted when they are already
implied.

> This is also a non-issue.

I hope so, but the sentence worries me.

> I do not see how we can get rid of this paragraph.
> However, perhaps it could be worded better to make
> it clearer
> without changing its intent.

But what is the intent? That ordering of keys
matters? I don't see it as a good feature, if so.

Or that the values of some keys "imply" the
values of others? They may be putting restrictions
on them, but why only if in the same "command"
("batch", whatever)? Why not always? Why have this
observation here and in the form that makes one
doubt whether responses are always mandatory?

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