Re: iSCSI: frame formats

[Stephen Bailey <steph@cs.uchicago.edu>]

> No one felt that a max data size of 16 megs in an iSCSI PDU was an
> issue

I did, I was just exhausted.  Furthermore, the size the PDU could
handle shrank (from 64M to 16M) right there before our ears in a split
second.

The `question' was also not asked in a form which I could effectively
answer or discuss.  There were two proposals presented, and they had
very different characteristics.  I figured I would refrain from
comment until I a) understood the proposals better b) got a sense of
which way we might be going.

I have a hard time swallowing a PDU that won't accomodate the data
from even a READ10 or WRITE10.

If people expect to tile each TCP segment with an iSCSI PDU, I think
that's a mistake.  The headers are too bulky for that.  If they think
they're going to gain something meaningful in hardware implementation
complexity (e.g. bounding the amount of reassembly buffering) by
assuming small multiples of segment size PDUs, I think that's a
mistake too.  I'd like to see a show of hands of people who have
actually implemented this approach in hardware.  Anybody?

If you (eventually) accept this, then you're back to the model that
there's a lower layer which is providing your data steering on a
per-segment basis, and your iSCSI PDU is the granularity at which the
iSCSI implementation delivers data to this layer.  It is clearly a
granularity at which software (transfer scheduling) occurs. 

At 10 Gbit/s, a 16 MB PDU is only 16 MS worth of data.

Steph