RE: iSCSI: MaxCmdSN

["Ayman Ghanem" <aghanem@cisco.com>]

Julian,

The text in section 2.4.10 should make it clear that a response PDU from the
target with MaxCmdSN=ExpCmdSN-1 is permitted, to handle the case when the
target's window has reached 0. It is OK for the initiator to ignore the
MaxCmdSN but not the ExpCmdSN. Also, if the initiator has no other commands
pending at the target, the target MUST send a NOP-IN advancing the MaxCmdSN
to update the corresponding value at the initiator.

-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Ayman Ghanem
> Sent: Monday, June 11, 2001 2:11 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: MaxCmdSN
>
>
> Nick,
>
> Yes, it will be an error for MaxCmdSN to have a value < (ExpCmdSN
> - 1), and
> I agree that MaxCmdSN = (ExpCmdSN - 1) should be permitted. As for the
> target receiving a PDU with CmdSN > MaxCmdSN, it is stated in
> draft-06 (near
> the end of 1.2.2.1) that the target MUST silently ignore such a
> command. No
> reject PDU needs to be sent.
>
> -Ayman
>
>
> > -----Original Message-----
> > From: Martin, Nick [mailto:Nick.Martin@compaq.com]
> > Sent: Monday, June 11, 2001 12:00 PM
> > To: 'Ayman Ghanem'; ips@ece.cmu.edu
> > Subject: RE: iSCSI: MaxCmdSN
> >
> >
> > Ayman,
> >
> > I thought I understood this, and I had a great explanation
> supporting the
> > draft (06), but I now realize I was "off by one".  I believe you
> > are correct
> > that ExpCmdSN will be one greater than MaxCmdSN if-and-only-if an
> > acknowledgement is to be sent while the window is closed.
> >
> > The purpose of ExpCmdSN and MaxCmdSN transmitted by the target, is to
> > advance values with the same names maintained in the initiator.
>  ExpCmdSN
> > acknowledges receipt of all CmdSN values < ExpCmdSN.  MaxCmdSN is the
> > largest CmdSN the target promises to accept, and conversely the largest
> > CmdSN the initiator is permitted to send.
> >
> > The target can not regress these numbers in the initiator.  When
> > the target
> > transmits (and the initiator accepts) N as the MaxCmdSN, the
> initiator is
> > allowed to transmit CmdSN values through N.  Then it must stop.
> > Any number
> > of additional PDUs may carry the same MaxCmdSN value.  None of
> these will
> > cause the initiator's value to advance.  A response carrying a
> > MaxCmdSN less
> > than the initiator's current MaxCmdSN value is presumed to have arrived
> > late.  It does not advance nor regress the initiator's present value.
> >
> > After the initiator sends CmdSN of MaxCmdSN (still N), it can
> not send any
> > more until MaxCmdSN advances.  It should be permitted for the target to
> > acknowledge the receipt of all commands received through this
> > CmdSN which is
> > N.  In this case ExpCmdSN would be N + 1 and MaxCmdSN is still
> N.  We know
> > that no commands are in flight.  When the target is able to
> accept another
> > command, it must advance MaxCmdSN (value > N in serial
> arithmetic), and it
> > will send the new value to the initiator in the next inbound PDU (i.e.
> > data-in, SCSI response, or nop-in).
> >
> > Yes, I believe it would be a protocol error for MaxCmdSN to have a value
> > less than ExpCmdSN - 1.  This would be an acknowledgement for a
> > CmdSN which
> > the initiator was not yet permitted to send.  I think MaxCmdSN equal to
> > ExpCmdSN - 1 should be permitted.
> >
> > Note however that nothing will break if this acknowledgement is not
> > immediately sent or, having been sent, does not advance the initiator's
> > values.  The window is already closed and remains so.  While
> the window is
> > closed, the initiator will be holding the last PDU sent as
> unacknowledged,
> > when the target has in fact received it.  The PDU will be successfully
> > acknowledged when MaxCmdSN advances, because ExpCmdSN in the
> > target will not
> > advance simultaneously while the window is closed.
> >
> > Was this done intentionally to delay the last acknowledgement when the
> > window is closed, or is it an "off by one" issue in  draft 06?
> >
> > This made me think about a related issue:
> > It think it would be permitted for the target to reject or drop
> a PDU with
> > CmdSN greater than MaxCmdSN, but I am not sure if it is
> required to do so.
> > I do not see a response code the target could send that would tell the
> > initiator what it did wrong.
> >
> > Thanks,
> > Nick
> >
> > -----Original Message-----
> > From: Ayman Ghanem [mailto:aghanem@cisco.com]
> > Sent: Monday, June 11, 2001 9:18 AM
> > To: ips@ece.cmu.edu
> > Subject: iSCSI: MaxCmdSN
> >
> >
> > In section 2.4.10, "if the PDU MaxCmdSN is less than the PDU
> > ExpCmdSN ....,
> > they are both ignored". Is this considered an invalid response from the
> > target?. What happens when the target queuing capacity reaches 0. For
> > example: target received and processed cmdsn N, but can not
> receive cmdsn
> > N+1 yet. In the response for N, target puts N+1 for
> > expectedCmdSN. How does
> > it inform the initiator that its window is closed?. Setting
> MaxCmdSN to N
> > will be ignored if I understand the above paragraph correctly.
> >
> > -Ayman
> >
> >
>
>