RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

Nick,

Given your last paragraph below, do you agree this would be correct (draft
10) (InitialR2T=yes and ImmediateData=no make FirstBurstSize meaningless):

I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no
T->I FirstBurstSize=Irrelevant, InitialR2T=yes, ImmediateData=no

Eddy

-----Original Message-----
From: Martin, Nick [mailto:Nick.Martin@compaq.com]
Sent: Wednesday, February 06, 2002 5:06 PM
To: Santosh Rao; IPS Reflector
Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?

Santosh,

One clarification is that MaxRecvPDULength (formerly DataPDULength),
FirstBurstSize, and MaxBurstSize limit the size of the data segment or
payload portion of the PDU.  The header and digests are not counted
within these lengths.  (Also note that these are now in bytes now all
512 byte chunks.)  Their ranges are 512 to (2**24)-1.  The upper bound
corresponding to the max value which can be expressed in the 24-bit
field DataSegmentLength.  If the value is 1024, it means 1024 bytes of
data, not 1024 minus 48-byte header, minus up to two 4-byte digests. 

Compute your own overhead before negotiating the value.  One may want to
make sure all iSCSI PDUs fit within MTU.  If the MTU, the overhead of
the protocols below iSCSI, and the overhead of iSCSI are known, the
number of iSCSI data bytes that will fit in a MTU size packet can be
computed and negotiated.  It does not need to be a power of 2 nor a
multiple of 512.  A multiple of 4 is expected.

As has been pointed out some values may become unused or meaningless due
to the setting of other values.  The responder may reply with
key=irrelevant.  However I see no harm in accepting a numeric value,
although it may not be used.  The intention of the initiator may be to
replace the default value in case part or all of the negotiation for
no-unsolicited data is rejected.

It is not invalid to have FirstBurstSize less than MaxRecvPDULength and
ImmediateData=yes and InitialR2T=no.  In this case InitialR2T=no cause
no different behavior from InitialR2T=yes, since the FirstBurstSize will
always be satisfied with immediate data.  I do not think it would be
appropriate to reply InitialR2T=Irrelevant.

I think key=Irrelevant should be used when the responder is required to
reply, but can not construct a reply that makes sense.  This could be
due to something else making the key meaningless.  Examples might be a
prior FMarker=no making RFMarkInt=Irrelevant, or a prior AuthMethod=SRP
causing CHAP_A=Irrelevant.  Key=Reject may fit such cases as well or
better, if the other end should already know the prior result.

Thanks,
Nick

> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Tuesday, February 05, 2002 1:56 PM
> To: IPS Reflector
> Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ?
>
>
> Hello,
>
> Can someone clarify if the login key FirstBurstSize is valid when :
> InitialR2T=yes  and ImmediateData=yes ?
>
> i.e. if immediate data is enabled and un-solicited data is disabled
> during login negotiation, is the value of FirstBurstSize
> received in the
> login response to be interpreted ?
>
> My current understanding is that FirstBurstSize is inclusive of the
> immediate data portion, and so, if immediate data is enabled, but
> un-solicited data is disabled, then, FirstBurstSize *must* be
> valid and
> must be <= DataPDULength. (after rev 09, it would be <=
> (MaxRecvPDULength - the header components size)).
>
> For example, a target implementation may offer a FirstBurstSize <
> DataPDULength, in which case, the immediate data size is the
> MIN(DataPDULength, FirstBurstSize, bytes_to_send).
>
> Can someone clarify if this is a correct interpretation or
> set me right
> on this ?
>
> Thanks,
> Santosh
>
>
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################
>