Subject: re: iSCSI minimum PDU length

From: Dave Sheehy <[email-masked]>
Date: Wed, 24 Oct 2001 15:11:22 PDT

> 
> With no votes against we have settled (again) on single PDU length (per 
> connection, per direction) for all types of PDUs.
> But I think we erred on the low side by suggesting 64 as a minimum. It is 
> low (it was mentioned) and bad for text request/response.
> 
> How about settling for 1024?

Too big (since the MSS can be smaller than 1024). 512 is a better number.

Dave Sheehy

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 25 Oct 2001 08:51:40 +0300

Santosh,

The restriction applies to NOP (every PDU) too.
The Ping response will be the Ping data or a ping data cut to the length 
of the reverse direction PDU.
The curent 4k was also for responses.

Julo

Santosh Rao <[email-masked]>
Sent by: [email-masked]
24-10-01 20:04
Please respond to Santosh Rao

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        Re: iSCSI minimum PDU length

Julian,

Does the below imply that the length retriction of 4K on text & nop
operations is also removed and we now need to handle multi-sequence nop
operations ?

I suggest that maximum nop operation length be restricted to the minimum
PDU length that the draft will require. This will avoid adding multi-pdu
sequence complexity for the nop-out/nop-in pdu's.

The current login & text pdu's do allow for multi-sequence operations
based on the T/F bit. This should be sufficient if the login/text
payload exceeds 1K , as long as "key=value" operations are not going to
span pdu's. Is that correct ?

- Santosh

Julian Satran wrote:
> Julo

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 25 Oct 2001 09:07:16 +0300

Santosh,

About the login issue - during login the default of 8k holds 
(MaxRecvPDULength is not negotiated yet).  This should make login swift.

Julo

Julian,

- Santosh

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 25 Oct 2001 09:26:51 +0300

no - the minimum mentioned includes only the data segment.  Julo

24-10-01 22:52

        To:     "Martin, Nick" <[email-masked]>
        cc:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        Subject:        Re: iSCSI minimum PDU length

Does the MaxRecvPDULength include the AHS length ? 

- Santosh

"Martin, Nick" wrote:
> 
> Julian,
> 
> This is for the data after the PDU header right?
> This will be the guaranteed lowest value anyone will be forced to deal
> with.
> Implementations may negotiate for any value greater than or equal to
> this value.
> 
> This is acceptable and it is a good choice because it is the largest
> power of 2 that will fit within minimum Ethernet MTU of ~1500 and leaves
> plenty of room for iSCSI and LLP headers.
> 
> Thanks,
> Nick
> 
> -----Original Message-----
> From: Julian Satran [mailto:[email-masked]]
> Sent: Wednesday, October 24, 2001 12:35 PM
> To: [email-masked]
> Subject: iSCSI minimum PDU length
>

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 25 Oct 2001 02:35:38 -0700

If you are only talking about Data PDUs, then at least I understand.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]
---------------------- Forwarded by John Hufferd/San Jose/IBM on 10/25/2001
02:34 AM ---------------------------

John Hufferd/San Jose/IBM@[email-masked] on 10/25/2001 02:12:07 AM

Sent by:  [email-masked]

Julian,
Perhaps I do not understand what you are getting at here, but since there
will be implementations with only R2T type Sessions, then there should be a
lot of PDUs that just carry the Command (48 bytes + digest) it seems that a
1024 is kind of big.  What am I missing?
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 10/24/2001 10:34:38 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Julo

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 25 Oct 2001 02:12:07 -0700

Julian,

To:   [email-masked]
cc:

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 25 Oct 2001 15:20:25 +0300

John,

We are talking about the payload (i.e. DataSegment Length) maximum length 
that a receiver will accept and I suggested
1024 as the minimum value for it.

Julo

John Hufferd@IBMUS
25-10-01 11:12

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        From:   John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: iSCSI minimum PDU length

Julian,
Perhaps I do not understand what you are getting at here, but since there 
will be implementations with only R2T type Sessions, then there should be 
a lot of PDUs that just carry the Command (48 bytes + digest) it seems 
that a 1024 is kind of big.  What am I missing?
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 25 Oct 2001 15:22:50 +0300

We are attempting to make it a uniform limit for the DataSegment for all 
PDUs (Data, Login, Text, NOP etc.).

Julo

John Hufferd@IBMUS
25-10-01 11:35

        To:     Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:     [email-masked]
        From:   John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: iSCSI minimum PDU length

.
.
.
John L. Hufferd
---------------------- Forwarded by John Hufferd/San Jose/IBM on 10/25/2001 02:34 AM ---------------------------

Julian,
a
lot of PDUs that just carry the Command (48 bytes + digest) it seems that 
a

To:   [email-masked]
cc:

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 27 Oct 2001 19:57:01 +0300

Steph,

512 is a good number for full feature phase if we stay with the current 8k 
during login (you have no framing anyhow during login - don't you?). The 
large binaries used by the security negotiation can become an issue 
otherwise.

Julo

Stephen Bailey <[email-masked]>
Sent by: [email-masked]
25-10-01 17:33
Please respond to Stephen Bailey

        To:     [email-masked]
        cc: 

> The minimum MSS is under 300 bytes.

As I understand it, the minimum MSS is 8 bytes.  Yes, this is a
pathological case.

What you really seem to be talking about here is the minimum allowable
maximum PDU length, NOT, as the subject indicates, and JohnH points
out, the true `minimum PDU length'.

One number relevant to this discussion is the one below which you
would not expect (or desire) good performance anyway.  When MSS
shrinks below this performance limit you may have to fall back to a
slow path (e.g. reassembly & copying instead of on-the-fly direct
placement) in your implementation, but you won't feel bad because you
know there's no way performance could be good at that MSS under ANY
circumstances.

The minimum allowable maximum PDU length should be NO LARGER than this
number.

I personally think that you will want to maintain performance at an
EMSS smaller than 1024.  I agree with Dave that 512 is certainly
headed in the right direction.

Looking at it from the other direction, the minimum allowable maximum
PDU could definitely be smaller than this performance target number.

The lower limit is a result of the protocol design---what is the
smallest limit larger than fixed sized PDUs which also allows variable
sized PDUs to carry a minimum amount of data.  There's no reason why
the minimum allowable maximum PDU size could not be chosen to exactly
fit the current iSCSI PDUs (or, within a power-of-two stones throw).

Just because the protocol allows you to scale PDUs down to a minimum
of xxx bytes and still operate does not mean that implementations
won't chose a larger value for the limit of their performance design
point.  Implementations care about bounding the maximum PDU size.
They must handle the smallest PDUs the protocol can create already
anyway.

In other words, nobody is going to say `ok, you mean I can make all
the PDUs I send carry only 1 byte of data, GREAT! I'm going to do
that'.

Where you're headed, it really comes down to ensuring that all
variably sized data can be chunked, which means you have to solve the
chunking problem for text in one way or another.

Steph