Subject: Re: [Ips] Updated text for MaxOutstandingUnexpectedPDUs for iSER

From: Mike Ko <[email-masked]>
Date: Fri, 12 Nov 2004 12:46:03 -0800

William,

You wrote "Just to make sure I'm understanding things, 
MaxOutstandUnexpectedPDUs limits the total number of un-ack'd PDUs 
(NOP-OUTs in this case), not the number per any specific CmdSN. Correct?"

For the target, MaxOutstandingUnexpectedPDUs limits the unregulated and 
unexpected PDUs from the initiator.  This is described in the Unregulated 
and Unexpected Category in the added text.  It includes PDUs with the 
immediate flag set and the SNACK PDU.  A unidirectional NOP-out PDU (where 
ITT = TTT = 0xffffffff) has the immediate flag set and so is included with 
the PDUs with the immediate flag set.  The limit is not restricted to a 
specific CmdSN.

For the initiator, MaxOutstandingUnexpectedPDUs limits all PDUs originated 
from the target which are not sent as a response to a request from the 
initiator.  They do not carry CmdSN by definition.

You wrote "Why 2**64-1? All the other counting in iSCSI uses 32-bit ints.
Including the numbers we want to use for status acknowledgement. Thus I
really don't see how we could need more than 2**32."

I just want to pick a large number for the upper limit, and I can live 
with 32 bits.  I can change the spec to reflect 32 bits if there are no 
objections.

Mike
To:     Mike Ko <[email-masked]>
cc:     [email-masked] 
Subject:        Re: [Ips] Updated text for MaxOutstandingUnexpectedPDUs 
for iSER

On Nov 11, 2004, at 9:25 PM, Mike Ko wrote:

> After thinking through the potential problem with overuse of the
> unidirectional NOP-out PDUs, I concluded that the situation where the
> initiator can send twice MaxOutstandUnexpectedPDUs cannot happen.
> Even if
> the initiator abuses the use of the unidirectional NOP-out PDUs, it can
> only send MaxOutstandUnexpectedPDUs, but not twice the number.  The
> reasoning is as follows:
>
> For the unidirectional NOP-out, the CmdSN used is the next CmdSN and
> the
> variable is not advanced when the PDU is sent, and neither is
> ExpCmdSN. So
> for the target to respond with a PDU where ExpCmdSN is x+1 where x is
> CmdSN of the NOP-out PDU, it must be acknowledging a non-immediate PDU
> also with CmdSN = x.  This must be sent after all the NOP-outs with
> CmdSN
> = x have been sent, since this non-immediate PDU will advance CmdSN.
> Assuming the target has processed all the NOP-outs with the immediate
> flag
> set before the non-immediate PDU that follows, the receive buffers
> should
> be replenished.  So even if the initiator sends a huge number of
> NOP-outs
> later after receiving a PDU from the target with ExpCmdSN = x+1, it
> will
> be using CmdSN = x+1 for those NOP-outs and there is no ambiguity on
> the
> CmdSN that the ExpCmdSN is acknowledging.  So if the target has
> provisions
> for MaxOutstandUnexpectedPDUs number of receive buffers available, it
> should be able to handle the unexpected NOP-out PDUs.

Just to make sure I'm understanding things, MaxOutstandUnexpectedPDUs
limits the total number of un-ack'd PDUs (NOP-OUTs in this case), not
the number per any specific CmdSN. Correct?

> For StatSN, the reasoning is similar since StatSN in the NOP-In is
> interpreted as the next StatSN.
>
> The following is the updated text for the new key,
> MaxOutstandingUnexpectedPDUs.  Note that the default for the key is
> TBD as
> David Black has suggested in the 61st IETF meeting.  The argument for
> the
> default being "None" is that it is the preferred value if the
> implementation uses Shared RQ, supports graceful handling, or can
> replenish receive buffers at wire speed.  Please respond if you have a
> suggestion for a different default value.
>
> Mike
> --------------  start of new key definition ---------------
> Use: LO (leading only), Declarative
>
> Senders: Initiator and Target
>
> Scope: SW (session-wide)
>
> Irrelevant when: RDMAExtensions=No
>
> MaxOutstandingUnexpectedPDUs=<numerical-value-from-0-to-(2**64-1) |
> None>

Why 2**64-1? All the other counting in iSCSI uses 32-bit ints.
Including the numbers we want to use for status acknowledgement. Thus I
really don't see how we could need more than 2**32.

Take care,

Bill

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips