Subject: [storm] iSER update request from Alex Nezhinsky on NOP-out data length

From: Mike Ko <[email-masked]>
Date: Thu, 20 Aug 2009 16:47:32 -0700

Alex sent me the following iSER update request:

> ISCSI spec, in 10.19:
> "When a target receives the NOP-Out with a valid Initiator Task Tag
> (not the reserved value 0xffffffff), it MUST respond with a NOP-In
> with the same Initiator Task Tag that
> was provided in the NOP-Out request.
> *** It MUST also duplicate up to the first
> *** MaxRecvDataSegmentLength bytes of the
> *** initiator provided Ping Data.
> For such a response, the Target Transfer Tag MUST be 0xffffffff."
>
> But in ISER there is no MaxRecvDataSegmentLength common to initiator
> and target so InitiatorMaxRecvDataSegmentLength may be smaller (it
> typically is much smaller) than
> TargetMaxRecvDataSegmentLength, so this kind of data duplication may
> prove impossible, unless the length of data sent with NOP-Out is
> ALWAYS less than
> InitiatorMaxRecvDataSegmentLength.
>
> It may be argued that such requirement is implicit in determining the
> value of InitiatorMaxRecvDataSegmentLength.
>
> Suggested solution: to add a clause explicitly requiring the initiator
> NOT to send more than InitiatorMaxRecvDataSegmentLength worth of data
> with NOP-Out.

RFC 3720 did not explicitly require that the initiator not send more than MaxRecvDataSegmentLength worth of data with NOP-out under similar conditions.  RFC 5046 stated that "In the Full Feature Phase, the initiator MUST consider the value of its local MaxRecvDataSegmentLength (that it would have declared to the target) as having the value of InitiatorRecvDataSegmentLength".  So an initiator sending such an NOP-out PDU would expect to receive up to the first MaxRecvDataSegmentLength worth of data and this value is equal to InitiatorRecvDataSegmentLength that it has declared to the target.  This seems clear to me.  But if others on the reflector think otherwise, please voice your concern here.

Mike