RE: iSCSI - long key values

["Wheat, Stephen R" <stephen.r.wheat@intel.com>]

Julian,

As Robert so clearly pointed out, this is  storage.  My observation is that
text messages are simply data PDUs that are processed by the iSCSI protocol
engine.  If we could work towards such an abstraction, we could remove the
special handling processing at the protocol package level.  I.e., if we
segregate the interpretation of the message from the packaging/passing of
the message, the protocol would increase in consistency.

As such, I'd like to see some consideration where we would revisit this
special handling processing and review an approach where we indeed segregate
the packaging from the processing of messages that are essentially data
exchanges between the engines, rather than the SCSI end points.  For
example, have a data PDU sequence whose target is a "logical unit" within
the iSCSI engine itself.  These messages would look identical to Read/Write
processing, which is allowed even in pre-FFP because the messages are
between the engines, not the SCSI end points.

Either my observation is erroneous, or we've missed an opportunity to
capitalize on the abstraction, not seeing the forest for the trees.

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, September 19, 2001 11:33 AM
To: Wheat, Stephen R
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI - long key values




Stephen,

We don't want regular values to extend beyond 255 bytes (no good reason to
allow this).
As such we have 2 limits a) the value length limit AND b) the text block
limit.
I am not sure that we have to worry about the text block limit except if we
are forced into shorter blocks by the framing mechanism.  The block
spanning mechanism enables us to avoid the first limit (and even here we
don't have a good mechanism as bookmarks are target driven and we have to
invent another mechanism for initiator driven bookmarks.

It looks like the second solution I've suggested works in both directions
and is "scalable" while the first needs an additional mechanism to scale
beyond a block.

Julo


 

                    "Wheat, Stephen

                    R"                      To:     Julian
Satran/Haifa/IBM@IBMIL,             
                    <stephen.r.wheat@        ips@ece.cmu.edu

                    intel.com>              cc:

                                            Subject:     RE: iSCSI - long
key values           
                    19-09-01 18:06

                    Please respond to

                    "Wheat, Stephen

                    R"

 

 





Julian,

Maybe I'm missing something, but I think the new "value extension"
discussion is around how to send very long "values" in a list of key=value
pairs.  IF we may have key=value pairs arbitrarily span PDUs, then the
sending of a long value is done simply by sending one text response PDU
after another, some may have nothing but a 4KB "value" component of a
key=value pair.  The concatenation of the individual "value" components is
then done on the Initiator side, through the process of concatenating the
text responses (in order, of course).

So, am I missing something here?

Stephen

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, September 18, 2001 9:31 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - long key values


Stephen,

It is still on the "to consider list".

How would that affect the individula value "extension" that we are
considering now?

Julo

"Wheat, Stephen R" <stephen.r.wheat@intel.com> on 18-09-2001 17:57:36

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI - long key values



Julian,

Almost a month ago, we had a thread on values spanning PDU boundaries.

See: "Re: Target record not to span PDUs?"

Anyway, that thread discussion ended without conclusion.  I believe Robert
Snively's and my proposal to allow records to span PDUs is still valid;
I'll
let Robert speak for himself.

Furthermore, I believe that the proposal would thus avoid this problem you
are now addressing, with far less complexity.

Please reconsider this proposal.

Stephen


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, September 17, 2001 11:26 PM
To: ips@ece.cmu.edu
Subject: iSCSI - long key values


Dear colleagues,

Ofer brought recently to my attention that some security key values are
likely to exceed our stated limit
of 255 bytes for a value.  A good example may be a certificate (or chained
certificate).

We have to enable those to be in the Login phase.

To handle this we might want to consider the following options (but not
only those):

   enable a "long hexadecimal coding" that should indicate a "long" value
   (e.g. use 0L instead of 0x) and raise the limit for those keys to
   something longer (say 3072 bytes?)
   enable "concatenated" values and indicate them through a "coding scheme"
   as follows:
     the value "0sxx" indicates a name suffix (as in "key = 0s08" means
     that the keys "key00" , "key01" etc) have to be concatenated
     use the "suffixed keys" to "build the value"
   use a named key coding (as in "0Nname" in a value means that you have to
   use later get=value to get a "binary response" containing the whole
   binary object)


I  think that option 2 (limited to a 3 digit prefix?) covers well what we
need and offers some extension space and option 1 is probably good enough
for certificates.

Comments?

Julo