iscsi : Fragmentation & Reassembly issues in iSCSI.

[Santosh Rao <santoshr@cup.hp.com>]

Julian,

Issue :
=====
DataPDULength, PingMaxReplyLength, Fragmentation/Reassembly issues.

Problem :
=======
1) What is the relationship b/n DataPDULength and PingMaxReplyLength ?

If a simple iSCSI test program decided to use the NOP-OUT as a form of
basic testing and began issuing increasing sizes of NOP-OUT, at some
point, it will cross the DataPDULength  PDU size (provided it was able
to negotiate PingMaxReplyLength > DataPDULength, which such a test
program would attempt, in the interests of large I/O testing).

The DataPDULength introduces fragmentation and reassembly issues at the
iSCSI layer for the NOP-OUT, NOP-IN and Login commands.

(For the SCSI Data PDUs, reassembly is possible based on the Buffer
Offset contained in the data PDU header.)

Question :
========
What drives the fundamental requirement for the DataPDULength ? I see no
benefit for this other than trying to ensure a small data payload in
order to have an effective CRC. Are there any other benefits ?

Is there a need to impose an upper bound (MTU) on the size of PDUs other
than the SCSI Command PDU (containing immediate data) and SCSI Data PDU
?

Solution :
=======
Specify explicitly in Appendix C that DataPDULength is only applicable
for SCSI Command PDU and SCSI Data PDU. The current definition is open
to being mis-interpreted as a form of iSCSI MTU, something that can
result in the iSCSI layer having to deal with fragmentation and
re-assembly issues for non-SCSI PDUs.

Regards,
Santosh
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard