Subject: Re: iSCSI: large keys during login?

From: andy currid <[email-masked]>
Date: Tue, 30 Apr 2002 22:15:59 -0700 (PDT)

Julian

The sections you refer to describe Text Request and Text Response PDUs.
Unless I've misunderstood the spec, neither of those PDUs can be used
during login; the only PDUs that are valid for use during login are Login
Request and Login Response.

I was under the impression that login phase was a very simple
exchange; initiator sends a single Login Request PDU, target replies
with a single Login Response PDU, repeat until logged in or rejected.

How can you have a key value span multiple Login Request or Response
PDUs? Unlike the Text PDUs, the Login PDUs do not contain the fields
required to permit text to span PDUs (target tag, final bit, etc.). So
there's no defined way to determine a text payload is being continued
in a subsequent Login Request or Response PDU.

Regards

Andy

> Pat,
> 
> For spanning look at 9.10.4 and 9.11.4.
> 
> I assume that the text covers whatever does not fit.
> 
> 
> Regards,
> Julo
> 
> 
> 
> 
> "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
> 04/30/2002 02:24 AM
> Please respond to "THALER,PAT (A-Roseville,ex1)"
> 
>  
>         To:     Julian Satran/Haifa/IBM@IBMIL, Bill Studenmund 
> <[email-masked]>
>         cc:     andy currid <[email-masked]>, [email-masked], [email-masked]
>         Subject:        RE: iSCSI: large keys during login?
> 
>  
> 
> Julian,
>  
> I assume you mean that keys can span requests as well. I can't find 
> anything in the draft that says that they can though there also isn't 
> anything that says they can't. Does this only apply to key-value pairs too 
> long to fit in a single response or can a short key-value pair span a 
> request/response when multiple key-value pairs are packed into a PDU?
>  
> The draft should clarify.
>  
> -----Original Message-----
> From: Julian Satran [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 3:54 PM
> To: Bill Studenmund
> Cc: andy currid; [email-masked]; [email-masked]
> Subject: Re: iSCSI: large keys during login?
> 
> 
> Key can span responses. Bookmarking is for things that have multiple 
> answers - like the SendTargets - Julo 
> 
> 
> 
> Bill Studenmund <[email-masked]> 
> Sent by: [email-masked] 
> 04/30/2002 01:15 AM 
> Please respond to Bill Studenmund 
>         
>         To:        andy currid <[email-masked]> 
>         cc:        <[email-masked]> 
>         Subject:        Re: iSCSI: large keys during login? 
> 
>  
> 
> 
> On Mon, 29 Apr 2002, andy currid wrote:
> 
> >
> > Hi
> >
> > In iSCSI draft 12, chapter 10, the Kerberos and SPKM authentication
> > mechanisms specify a limit of 64k on their unencoded key values.
> >
> > Given that these keys are only used during login and, during login,
> > the PDU size in use is 8k and, unlike text commands, there is no
> > bookmarking, how can you send a key value of this size during login?
> 
> I thought that was covered. If you say you can do kerberos or SPKM, you
> are saying you can do 64k.
> 
> Take care,
> 
> Bill
> 

--
Andy Currid                                       [email-masked]
Server Products Group                       http://www.windriver.com
Wind River Networks                         Phone : (1) 510 749 2191
500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 1 May 2002 16:11:07 +0300

In fact itis there at 9.12.10. I will add the same to 9.13 Julo
----- Forwarded by Julian Satran/Haifa/IBM on 05/01/2002 04:08 PM -----

Julian Satran
05/01/2002 08:35 AM

        To:     andy currid <[email-masked]>
        cc:     [email-masked] (andy currid), [email-masked], [email-masked], 
[email-masked] ("THALER,PAT (A-Roseville,ex1)"), 
[email-masked] (Bill Studenmund)
        From:   Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: large keys during login?

Andy,

The data part is the same on both text and login.
I will make o note to say this again in chapter 9.

Julo

andy currid <[email-masked]>
05/01/2002 08:15 AM
Please respond to andy currid

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked] ("THALER,PAT (A-Roseville,ex1)"), 
[email-masked] (andy currid), [email-masked], [email-masked], 
[email-masked] (Bill Studenmund)
        Subject:        Re: iSCSI: large keys during login?

Julian

Regards

Andy

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 1 May 2002 21:16:35 +0300

The mechanism is uniform. Spanning and multiresponse PDUs are different 
issues though. Julo Spanning is not happening often at login (not many 
keys extend above 8k).
TTT is now the mechanism for target having more key=value for a single 
key=value query. Spanning is far simpler> We could colapse them and use 
TTT for both and if there is a bit needed it can't be F as F is the end of 
a sequence not a single negotiation. I think however that the simple 
string delimiter search that we have now is sufficient and the two 
mechanisms are sufficiently different to be kept separate.

Julo

Santosh Rao <[email-masked]>
Sent by: [email-masked]
05/01/2002 08:46 PM
Please respond to Santosh Rao

        To:     [email-masked]
        cc: 

Bill Studenmund wrote:
> 
> On Wed, 1 May 2002, Julian Satran wrote:
> 
> > I pointed to that earlier. TTT are needed only for multiple answers to 
one
> > query (like SendTargets).
> > Spanning responses  over several PDUs can be handled in different 
ways.
> > Here is a simple example:
> >
> > I->T Key=a
> > T-> Key=bbbbb (and does not end here i.e., no null in the PDU)

                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
Hello,

I don't know how the above would work. Every string (in this case, the
key=value string) is assumed to be NULL terminated. If this is not the
case, the usage of standard string routines like strlen(), strcpy(),
strstr(), etc will have problems in the iscsi login/text parsers.

I think the multi-pdu fragmentation and re-assembly mechanisms must be
uniform across both the login and text pdu's allowing the same code to
be re-used in both the login and text parsers.

Hence, it would be better to have the TTT and F bit in the login pdu.
The receiving side must not interpret any received keys, but simply
store them, send an empty login/login_rsp pdu back with the TTT set and
eventually perform re-assembly until the sending side sends a pdu with
the F bit set. When the 'F' bit PDU is received, the keys may be
interpreted, negotiations performed, and if necessary, another
login/login_rsp pdu be sent indicating the appropriate (CSG, NSG, T)
setting.

Regards,
Santosh

-- 
We have enough people who tell it like it is
Now we could use a few who tell it like it can be.

-  Robert Orben

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 1 May 2002 21:27:51 +0300

Both the F bit and the T bit have clear interpretation specified - they 
are similar but not identical. F bit is the end of the life of text 
request (and its ITT).
T bit does not have this implication for Login. That is also the reason 
for the name change :-)

Julo

Carlos Rimola <[email-masked]>
05/01/2002 09:04 PM
Please respond to Carlos Rimola

        To:     <[email-masked]>
        cc:     andy currid <[email-masked]>, "THALER,PAT (A-Roseville,ex1)" 
<[email-masked]>, Bill Studenmund <[email-masked]>, 
Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI: large keys during login?

Hello,

I believe the other point was the use of the F bit in Text 
requests/responses.  In Login Text requests/responses, the same bit 
position is known as the T bit and is defined as the "Transition" to next 
stage indicator.

Does this mean that the T bit in login request/responses should be 
interpreted in the same way as the F bit in text requests/responses?

If this is the case, is this dual meaning of the T bit desirable?  At the 
least, it would be useful for the spec to explicitly state the dual usage 
to remove any ambiguity.

Carlos Rimola
Silverback Systems

At 09:14 AM 5/1/2002 -0700, Bill Studenmund wrote:
>Julian, I think the grit of Andy's question still stands. At least I'm 
now
>puzzled by a question he raised. :-)
>
>I agree that the section you quote, 9.12.10, describes what keys can be
>used when & refers to the correct chapters.
>
>I think Andy's question, or the question I now have, is how do we do the
>equivalent of the multi-part exchange shown in section 9.10.3 (towards 
the
>bottom of page 156) with Login PDU's? We don't have a Target Transfer Tag
>field?
>
>Do we need to add one?
>
>Take care,
>
>Bill

---

From: Eddy Quicksall <[email-masked]>
Date: Sun, 5 May 2002 06:03:18 -0400

Yes, you are correct. I was trying to get away with small buffers and I
didn't notice a change in 4.1.

Eddy

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Friday, May 03, 2002 4:39 PM
To: Eddy Quicksall
Cc: 'Julian Satran'; THALER,PAT (A-Roseville,ex1); andy currid;
[email-masked]; [email-masked]
Subject: RE: iSCSI: large keys during login?

On Fri, 3 May 2002, Eddy Quicksall wrote:

> Regarding the following sentence in 9.10.4, can we say the key and equal
> sign most not be spanned? The reason I ask for this is because it makes
the
> parsing of the key much easier if you don't have it cut into two PDUs.

Wouldn't it just be easier to just read the whole extended text and then
parse? i.e.

	do {
		Read_packet(&empty part of buffer)
		if (packet doesn't end with a NUL) {
			send response asking for more
			make sure there's more space in buffer
		}
	} while (packet doesn't end with a NUL)

	parse while buffer

Why would you be parsing the text before it has all arrived? Or is it more
you were going to keep things in different buffers, and don't want to
fumble with the key spanning buffers?

Take care,

Bill