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

["Martin, Nick" <Nick.Martin@compaq.com>]

Eddy,

Regarding your example exchange below.

First, I would have parsed the incoming buffer from left to right so I
would have constructed my response for FirstBurstSize before recognizing
that it would not be used.  Second, I am confident that
FirstBurstSize=512 is a sensible response, even given that the initiator
will not be allowed to send a first burst due to the other settings
(soon to be in effect), and also presuming that FirstBurstSize=512 had
been listed last in the buffer.  The target and initiator would each
have a new value for FirstBurstSize.  

However, I suppose I must admit that this may not be an invalid
response.  The originator must treat the response as negotiation failure
for FirstBurstSize.  The value previously in effect (probably the
default) is unchanged for both originator and responder.
If the initiator is parsing from left to right (as I presume it should),
it will not yet know why the value Irrelevant was returned by the
target.  (It might over-react and close the connection.)

I think the value Irrelevant should be used sparingly.  In this case,
the values 512, Irrelevant, and Reject will have the same effect on
subsequent packets on the wire unless and until ImmediateData or
InitialR2T are negotiated again.  At that time the current value of
FirstBurstSize again becomes useful.  There is some rule about least
surprise which I can not quote at the moment, but given that these three
possible return values produce the same result, I would send the 512
since that will be least surprising to the initiator.

Remember that Irrelevant does not mean forgotten.  There is still a
current value in effect, even if the target chooses not to re-negotiate
it at this time.  I would not choose to refuse to accept the new value
for FirstBurstSize.  However if I wanted to so choose, I think I would
use Reject.

If the target does not support unsolicited nor immediate data and will
never use the value FirstBurstSize, it could still keep a current value
for the field.  In doing so it will be less likely to force an initiator
down a seldom trodden path.  

Thanks,
Nick

> -----Original Message-----
> From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
> Sent: Thursday, February 07, 2002 6:34 AM
> To: Martin, Nick
> Cc: Santosh Rao; IPS Reflector
> Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?
> 
> 
> 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
> > ##################################
> >
>