Subject: RE: iSCSI - long key values

From: "Wheat, Stephen R" <[email-masked]>
Date: Tue, 18 Sep 2001 07:57:36 -0700

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:[email-masked]]
Sent: Monday, September 17, 2001 11:26 PM
To: [email-masked]
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

---

From: Robert Snively <[email-masked]>
Date: Tue, 18 Sep 2001 12:14:21 -0700

I agree with Stephen.

> From: Wheat, Stephen R [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2001 7:58 AM
> To: 'Julian Satran'; [email-masked]
> Subject: RE: iSCSI - long key values
> 
> 
> Julian,
>

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 19 Sep 2001 07:30:50 +0300

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" <[email-masked]> on 18-09-2001 17:57:36

Please respond to "Wheat, Stephen R" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: iSCSI - long key values

Julian,

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.

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Monday, September 17, 2001 11:26 PM
To: [email-masked]
Subject: iSCSI - long key values

Dear colleagues,

Comments?

Julo

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Wed, 19 Sep 2001 14:09:11 -0700

I don't know if like that idea or not.  But, if we did want to do this, then
I propose a syntax variation so as to indicate when the length field would
be there and when it would not.

Something akin to:

   key=value[,value]*

or

   key>=length,value[,value]*
      ^---- pick some character not allowed in a "key" name.

Stephen

-----Original Message-----
From: Dev [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 12:26 PM
To: Wheat, Stephen R; 'Julian Satran'; [email-masked]
Subject: RE: iSCSI - long key values

If a value could span mutliple PDUs (a jumbo string, if you want these
strings to be called so..)
then it will be helpful to have the value length as below
key = length, "value"

Thanks

Deva
Adaptec

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Wheat, Stephen R
Sent: Wednesday, September 19, 2001 8:06 AM
To: 'Julian Satran'; [email-masked]
Subject: RE: iSCSI - long key values

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:[email-masked]]
Sent: Tuesday, September 18, 2001 9:31 PM
To: [email-masked]
Subject: RE: iSCSI - long key values

Stephen,

Julo

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Monday, September 17, 2001 11:26 PM
To: [email-masked]
Subject: iSCSI - long key values

Dear colleagues,

Comments?

Julo

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Wed, 19 Sep 2001 15:39:14 -0700

Good point, Marjorie, I hadn't considered that. I just wanted to avoid
having "length" always being provided.

Julian, I know it is a small thing in the grand scheme of things, but can we
pursue closure (consensus) on key=value pairs spanning PDUs, which would
also facilitate the "jumbo" strings?

Stephen

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)
[mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 3:12 PM
To: [email-masked]
Subject: RE: iSCSI - long key values

You should know by the key which values will be allowed to be long.  So no
special character is necessary, when you see "key", expect length, value?

Marjorie 

> Sent: Wednesday, September 19, 2001 2:09 PM
> To: [email-masked]'; [email-masked]

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 19 Sep 2001 15:12:18 -0700

Marjorie

---

From: Dave Sheehy <[email-masked]>
Date: Wed, 19 Sep 2001 15:58:39 PDT

> So, am I missing something here?

How do you avoid overflowing either side? Right now, each side only has to
buffer one PDU worth of data (per connection). Your proposal increases that
requirement to at least 2 PDUs.

Dave Sheehy

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Wed, 19 Sep 2001 16:24:33 -0700

I don't know why that is any different than receiving a long list of
key=value pairs that you want to hold onto until you have them all, prior to
operating on any of them, given you don't know that they'll arrive in any
given order that will yield one's ability to process them "on-the-fly"
without possibly having to undo actions.

At the very least, the text has to go somewhere anyway.  To "remember" where
to keep copying incoming text shouldn't be overly burdensome for the
Initiator.

Stephen

-----Original Message-----
From: Dave Sheehy [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 3:59 PM
To: [email-masked]
Subject: RE: iSCSI - long key values

Dave Sheehy

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 19 Sep 2001 21:32:55 +0300

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@        [email-masked]                                   
                    intel.com>              cc:                                                
                                            Subject:     RE: iSCSI - long key values           
                    19-09-01 18:06                                                             
                    Please respond to                                                          
                    "Wheat, Stephen                                                            
                    R"                                                                         

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, September 18, 2001 9:31 PM
To: [email-masked]
Subject: RE: iSCSI - long key values

Stephen,

Julo

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Monday, September 17, 2001 11:26 PM
To: [email-masked]
Subject: iSCSI - long key values

Dear colleagues,

Comments?

Julo

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Thu, 20 Sep 2001 07:40:32 -0700

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:[email-masked]]
Sent: Wednesday, September 19, 2001 11:33 AM
To: Wheat, Stephen R
Cc: [email-masked]
Subject: RE: iSCSI - long key values

Stephen,

Julo

                    "Wheat, Stephen

                    R"                      To:     Julian
Satran/Haifa/IBM@IBMIL,             

                    intel.com>              cc:

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

                    Please respond to

                    "Wheat, Stephen

                    R"

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, September 18, 2001 9:31 PM
To: [email-masked]
Subject: RE: iSCSI - long key values

Stephen,

Julo

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Monday, September 17, 2001 11:26 PM
To: [email-masked]
Subject: iSCSI - long key values

Dear colleagues,

Comments?

Julo