Subject: RE: iSCSI: NOPs should not have a CmdSN

From: [email-masked]
Date: Fri, 13 Jul 2001 19:39:58 -0400

> As for flow control, shouldn't we make the assumption that 
> immediate commands are executed synchronously (at sender
> and receiver) and hence there can be only 1 outstanding
> immediate command ?

I think this recreates Matt's problem because it requires
contacting the session manager to get permission to send
the only immediate command - Matt would need at least an
immediate command per connection to avoid having to
ask permission in this fashion.  I suspect this increases
the importance of a flow control solution for immediate
commands.

> Currently this is achieved by assigning
> "maxCmdSN+1" but given the problem Matt pointed out, maybe we 
> should explicitly say cmdSN must be ignored when immediate flag
> is set.

There's another reason why that might be a good thing
to do.  In Section 1.2.2.1, near the bottom of
page 12, the -06 draft says:

   For immediate commands, 
   the CmdSN field can take any value from ExpCmdSN to MaxCmdSN+1.
   The target MUST silently ignore any command outside this range 

The CmdSN in an immediate command will be used by a
non-immediate command, so suppose that CmdSN is 6.
Receipt of non-immediate command whose CmdSN is 6
(e.g., via a different connection) sets ExpCmdSN at
the Target to a larger value, 7 in this example,
causing the immediate command to be ignored because
its CmdSN (6) is smaller than ExpCmdSN (7).  That
doesn't strike me as the right result.  What is
that "MUST silently ignore" protecting us from?

Comments?
--David

> -----Original Message-----
> From:	Sandeep Joshi [SMTP:[email-masked]]
> Sent:	Friday, July 13, 2001 6:33 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: iSCSI: NOPs should not have a CmdSN
> 
> 
> This (cmdSN allocation) was *not* a problem in previous versions (e.g. 
> see NopOut PDU in draft 4), since CmdSN=0 was used to indicate 
> immediate delivery.
> 
> With the introduction of the immediate flag, we now require an
> explicit cmdSN to be allocated.
> 
> As for flow control, shouldn't we make the assumption that 
> immediate commands are executed synchronously (at sender
> and receiver) and hence there can be only 1 outstanding
> immediate command ?   Currently this is achieved by assigning
> "maxCmdSN+1" but given the problem Matt pointed out, maybe we 
> should explicitly say cmdSN must be ignored when immediate flag
> is set.
> 
> -Sandeep
> 
> [email-masked] wrote:
> > 
> > What about flow control of commands arriving at the
> > Target and associated Target resource management?
> > 
> > This sounds like yet another use for "immediate"
> > delivery, which I don't recall being
> > resolved to everyone's satisfaction in prior
> > discussion.
> > 
> > --David
> > 
> > > -----Original Message-----
> > > From: Matt Wakeley [SMTP:[email-masked]]
> > > Sent: Friday, July 13, 2001 5:45 PM
> > > To:   IPS Reflector
> > > Subject:      iSCSI: NOPs should not have a CmdSN
> > >
> > > Normally on an active connection, when a command response is received,
> the
> > > initiator can acknowledge the response by setting ExpStatSN in the
> next
> > > command sent.
> > >
> > > However, on a relative inactive connection, it may be some time before
> the
> > > next command is sent.  But the initiator should acknowledge the
> command
> > > response in a timely fashion so the target can de-allocate the
> "replay"
> > > resources for the command.  The initiator does this by sending NOP.
> > >
> > > However, the NOP requires a CmdSN.  CmdSN is managed on a session wide
> > > basis.
> > > StatSN is managed on a connection basis.  In the case where there are
> > > multiple
> > > connections active in the session on different iSCSI NICs, the session
> > > manager
> > > that resides in the host manages the CmdSN.  Therefore, if the
> connection
> > > manager on an iSCSI NIC wants to send a NOP to acknowledge StatSN on
> an
> > > idle
> > > connection, it must ask the session manager to do so, since it doesn't
> > > have
> > > visibility to the next CmdSN.
> > >
> > > To resolve this complexity, I propose removing CmdSN from the NOP.  I
> see
> > > no
> > > reason why NOPs need to be processed "in order" across the session.
> > >
> > > -Matt Wakeley
> > > Agilent Technologies

---

From: Sandeep Joshi <[email-masked]>
Date: Fri, 13 Jul 2001 20:28:58 -0400

David,

Right!..there is still a synchronization problem 
to get hold of that immediate command slot at the session level.  

As regards this statement..
>    The target MUST silently ignore any command outside this range

This was introduced to enable the initiator to send an immediate
command even when the queue is full (max+1 is allowed)
This was required for abort tasks.

One more thing to note in all this is (i believe) Abort Task
management PDUs now have a refCmdSN field (cmdSN of original task)

If we could explicitly state the requirements under which immediate
commands will be used, maybe we can solve this problem better
instead of imposing general constraints on how to deal with
the immediate commands, cmdSNs and flow control problems.

Are these the only possible cases ?
a) Ping commands - can we allow one immediate command per connection
   and ignore cmdSN field (and solve the problem David pointed out)
b) Abort Task commands - do not allocate a cmdSN to only allow one
   outstanding command OR allow a prenegotiated number (ugh..one
   more queue to manage!)

-Sandeep