Subject: re: iSCSI minimum PDU length

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

Dave,

The minimum MSS is under 300 bytes. 512 is as bad as 1024.  Framing will 
have to be adjusted to deal with it.

Julo

Dave Sheehy <[email-masked]>
Sent by: [email-masked]
25-10-01 00:11
Please respond to Dave Sheehy

        To:     [email-masked] (IETF IP SAN Reflector)
        cc: 
        Subject:        re: iSCSI minimum PDU length

> 
> 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: Stephen Bailey <[email-masked]>
Date: Thu, 25 Oct 2001 11:33:27 -0400

> 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

---

From: Paul Koning <[email-masked]>
Date: Thu, 25 Oct 2001 13:21:18 -0400 (EDT)

>>>>> "Stephen" == Stephen Bailey <[email-masked]> writes:

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

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

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

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

Nice analysis.

I don't see any need to maintain performance at MSS values that
small.  MTU values below 1480 are ancient history at this point, and
sensible MSS values are surely not way below MTU.

So, given the design center of what we're building, 1024 is the
logical value.

The one argument I can see for picking 512 is that it is the value
that was in the spec before.

     paul