RE: iSCSI: Negotiation clarifications still needed

[pat_thaler@agilent.com]

Martins,

One doesn't have to have a more complex value for key state 
because one isn't required to initiate keys while one has a 
partial key-value. If one wishes to have a simpler implementation, 
then one could have a flag for whether the last received PDU ended 
with a complete key-value. If it did, one can send key responses 
and originate keys. If it didn't, one could send key responses. 

Even an implementation that does originate key-value pairs 
doesn't need to change its key state because we know there 
is never more than one key-value in an incomplete state. 
Therefore, one could check any key that one would like to 
originate against a partially received key-value before 
originating it.

Pat

-----Original Message-----
From: Martins Krikis [mailto:mkrikis@yahoo.com]
Sent: Friday, May 24, 2002 5:45 PM
To: Mallikarjun C.; Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: Negotiation clarifications still needed


Mallikarjun wrote:

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

Definitely inclusive of "=". Otherwise there are
no strict guarantees that the whole key has been
received (we may have keys that are prefixes to
other keys in future, and vendor keys may be like
that).

I can implement it and live with it if that's what
people decide on. I just want people to understand
that it is conceptually a more complex aproach than
requiring strictly blank PDUs and having a data-end
flag. (Even if we don't add a new flag and decide
data-end by looking for NUL-s at the end, we get
a cleaner scheme.) Allowing non-blank PDUs  gives 
better bandwith utilization under
presumably rare circumstances (all pairs not fitting),
but introduces more complexity for your everyday case.

If we only stipulate that no key ever gets broken,
then there is the following "clumsiness" required.
When "originating" a key=value pair, it has to be
checked whether the key will fit fully in the PDU
or not, and if not, then "originating" must be
postponed. We also need either a more elaborate
state for the key (to mark key as received but
value as not; so it is not processable yet, nor
originatable anymore), or for each key=value pair
being originated, key has to be checked against
the buffer that would hold the "leftover stuff"
from the just received PDU, otherwise we may
illegally originate it. Doable, but not clean.

I still think that letting the whole set-of-pairs
go through (no matter over how many PDUs spread)
before the other side is allowed to process them
is cleanest. 

Martins Krikis, Intel Corp.

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