RE: iSCSI: FirstBurstSize and unsolicited data

[pat_thaler@agilent.com]

While there is no need to reduce FirstBurstSize to MaxRecvDataSegmentLength (current name for MaxRecvPDULength below), 11.15 says:

"FirstBurstSize MUST NOT exceed MaxBurstSize."

and it doesn't moderate that with a statement such as "unless InitialR2T=yes" so it would probably be wise to reduce FirstBurstSize if needed to satisfy that condition in case your partner checks the relative values of the parameters even when FirstBurstSize isn't important.

Regards,
Pat

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Friday, June 14, 2002 1:43 PM
To: Bill Studenmund; Nandakumar Ramamurthy
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: FirstBurstSize and unsolicited data


The initiator should probably reduce FirstBurstSize to 8k.

Although the spec does not seem to mandate this.


Eddy

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Friday, June 14, 2002 1:22 PM
To: Nandakumar Ramamurthy
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: FirstBurstSize and unsolicited data


On Fri, 14 Jun 2002, Nandakumar Ramamurthy wrote:

> Hi All,
>
> Consider the case where InitialR2T=yes and ImmediateData=yes.
> All other values are the defaults.
>
> The expected data transfer length for a SCSI write
> operation is a value exceeding FirstBurstSize (64KB).
>
> In the above case, the initiator will send immediate
> unsolicited data (MaxRecvPDULength=8192 bytes).
> After that it has to wait for an R2T from the target.

That is correct.

> In this scenario, FirstBurstSize of data will not be sent
> to the target as unsolicited data-out's cannot be sent here.
>
> My understanding is that the remaining data can be
> sent only through solicited Data-out PDUs,
> and this is the expected way according to the draft.
>
> What does the following statement(in Section 9.4.6.2 Sense Data) mean in
> this context ?
>
> <quote>
>
> The target reports the "Not enough unsolicited data" condition only
> if it does not support output (write) operations in which the total
> data length is greater than FirstBurstSize, but the initiator sent
> less than FirstBurstSize amount of unsolicited data, and out-of-order
> R2Ts cannot be used.
>
> </quote>

I think what that's getting at is if you do a write command and send
unsolicited data-out PDUs, you've promised to send FirstBurstSize worth of
data. If you don't, to continue the operation, the target needs to send an
R2T for the missing data. But that would be an out-of-order R2T since by
sending unsolicited data, you are acting as if you received an R2T for
FirstBurstSize data; this error R2T would be going backwards.

Take care,

Bill