Subject: iscsi : Fragmentation & Reassembly issues in iSCSI.

From: Santosh Rao <[email-masked]>
Date: Thu, 18 Jan 2001 16:47:05 -0800

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

---

From: Matt Wakeley <[email-masked]>
Date: Tue, 23 Jan 2001 13:34:55 -0800

Ok,

There is a DataPDULength which specifies max size of a *DATA* PDU, and a
PingMaxReplyLength field which indicates how much buffer space an
implementation is willing to dedicate to Ping messages.

Text strings that will not fit in a single Text command such that it's <=
DataPDULength can be sent as multiple text commands.

That leaves Login messages.  Since these maximum length fields are exchanged
during login, there really isn't a maximum (unless there is a default value)
to specify the maximum length of the login before the login.  So, the login
should just be sent as a single message, regardless of it's length.  Forget
all this F bit stuff.

-Matt

---

From: Santosh Rao <[email-masked]>
Date: Tue, 23 Jan 2001 14:28:32 -0800

Matt Wakeley wrote:

> Ok,
>
> There is a DataPDULength which specifies max size of a *DATA* PDU,

The DataPDULength is nebulous in its definition. It is'nt clear from its
definition if it is the size of only a [scsi] *DATA* PDU, or it  specifies the
max size of the data portion of all command and data PDUs. Also, what is the
exact definition of "data payload" of command PDUs ? Does this include or
exclude the additional header spanning beyond 48 bytes ?

> and a

> DataPDULength can be sent as multiple text commands.

If the login key negotiation can be performed as multiple text commands, how
does the target know the initiator has sent its last text command of login keys
to be negotiated ?

The login phase is negotiated as follows :
==============================
Initiator                                        Target
==============================
1) Login    ----------->
                  <---------- 1) Login response of "accept login"
                                                with F=0
2) Text    ------------>
              <-----------  2) Text Response
            :
            :
           <------------  3) Login Response of "accept login"
                                               with F=1

If the Text phase can consist of multiple text commands, how does a target know
when to send in the login accept response with F=1 ? The target needs an
indication that the initiator has sent in the last text command of the login
phase and the "F" bit in the login command can provide that.

>   Forget all this F bit stuff.

If the login phase can comprise multiple text commands, the target needs a way
to know the initiator has sent its final text command and the "F" bit provides
this.

OTOH, one could take the stance that the total number of login keys cannot
exceed DataPDULength (and TotalText shall be >= DataPDULength), in which case
the login phase cannot span beyond 1 text command.

Regards,
 Santosh