RE: iSCSI: NOPs should not have a CmdSN

[Black_David@emc.com]

> 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:sandeepj@research.bell-labs.com]
> Sent:	Friday, July 13, 2001 6:33 PM
> To:	Black_David@emc.com
> Cc:	matt_wakeley@agilent.com; ips@ece.cmu.edu
> 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
> 
> Black_David@emc.com 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:matt_wakeley@agilent.com]
> > > 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