Subject: Re: iscsi : Fragmentation & Reassembly issues in iSCSI.

From: [email-masked]
Date: Sun, 21 Jan 2001 09:45:07 +0200

Santosh,

The intent was to enable lower limits for ping and text.  I would be
reluctant to use the same limit as in some contexts the PDU limit could be
practically very large. PDU will be limited at first by 2 factors - the CRC
and the need to limit loss-of-framing temporary memory.
If and when the underlying transport will have a good RDMA mechanism and we
will have a decent CRC-64 or we are using IPsec the PDU limit could be
extremely large.
We don't want the same to hold for Ping, Text etc.

However we would like to have the PDU limit to hold for all as it is mainly
meant for framing and CRC.

For all those reasons I suggest limiting the text length also to the lower
of the two.

Julo

Santosh Rao <[email-masked]> on 19/01/2001 23:59:49

Please respond to Santosh Rao <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  Re: iscsi : Fragmentation & Reassembly issues in iSCSI.

[email-masked] wrote:

> <js> I will introduce in 04 a statement saying that that
PingMaxRelayLength
> will be limited by the lowest of the two </js>

Julian,

The fragmentation issue as explained in the above example is also
applicable
for the Login and Text Commands. (TotalText > DataPDULength).

In the case of these commands, a "F" bit is required in bit 7 of byte 1 of
the
command & response PDUs to indicate the last command or response PDU due to
the fragmentation issues that arise from TotalText & DataPDULength.

> 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.
>
> <js> What would be those? Text commands? Login? Nops? Having a single
limit
> seemms simpler </js>

On the lines of your above solution, (based on a single limit), removal of
PingMaxReplyLength should be considered and implicitly use DataPDULength as
the PingMaxReplyLength. This ensures only 1 limit for NOP-OUT/NOP-IN.

Regards,
Santosh

---

From: Santosh Rao <[email-masked]>
Date: Sun, 21 Jan 2001 11:29:12 -0800 (PST)

> reluctant to use the same limit as in some contexts the PDU limit 
> could be practically very large. PDU will be limited at first 
> by 2 factors - the CRC and the need to limit loss-of-framing 
> temporary memory.If and when the underlying transport will have a good 
> RDMA mechanism and we will have a decent CRC-64 or we are using 
> IPsec the PDU limit could be extremely large.
> However we would like to have the PDU limit to hold for all as it is 
> mainly meant for framing and CRC.
> 
> For all those reasons I suggest limiting the text length also to the 
> lower of the two.

Julian,

Agreed. However, it could be the case that the number of login keys being
negotiated exceeds TotalText requiring the use of multiple Text Commands
and Text Responses. An "F" bit is required in bit 7 of byte 1 of the text
and login commands and responses to indicate the last command or response
PDU of the login or text operations to deal with this condition.

Regards,
Santosh
> applicable for the Login and Text Commands. (TotalText > DataPDULength).
> 
> In the case of these commands, a "F" bit is required in bit 7 of byte 
> 1 of the command & response PDUs to indicate the last command or 
> response PDU due to the fragmentation issues that arise from 
> TotalText & DataPDULength.

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################