Re: iSCSI - Change Proposal X bit

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Your 2nd argument make sense..the first seems like a
issue of changing the cmdSN definition.   That said,
I'd rather have preventive measures to make the target
protect itself rather than assume the initiator sends
out certain periodic messages.

-Sandeep

"Mallikarjun C." wrote:
> 
> Sandeep,
> 
> >because we allow the maxCmdSN to increase
> > unbounded in the presence of unacked statSNs.
> 
> That's true!  Two concerns -
> 
> - We have been using CmdSN at the target only
>   for reordering of commands, and it becomes irrelevant
>   once a SCSI task is instantiated (section 2.2.2.1).
>   Your suggestion doesn't appear to conform to this
>   idea - in fact it seems to require CmdSN association
>   beyond the task conclusion.
> 
> - CmdSN credit management is an iSCSI session activity,
>   and tying session level credit management with StatSN
>   ACKs that happen at a connection level doesn't seem to
>   enable a clean "session manager" separation spanning
>   multiple NICs.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> Sandeep Joshi wrote:
> >
> > Mallikarjun,
> >
> > This problem can be solved _without_ introducing
> > any additional I/O activity.   Notice that it
> > occurs because we allow the maxCmdSN to increase
> > unbounded in the presence of unacked statSNs.
> >
> > The target can prevent this from happening.
> >
> > Imagine some connection A at the target :
> >
> > (1) Everytime the target sends a new statSN out, it
> >     records the cmdSN for that statSN
> >     (say Connection_A.cmdSN_of_last_statSN = 200)
> >
> > (2) While growing maxCmdSN at target, ensure that
> >     (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1)
> >
> >     This is stricter than current condition
> >     (maxCmdSN - expCmdSN) < 2^31-1
> >
> >     If there are N connections, use least value of
> >     cmdSN_of_last_statSN.
> >
> > (3) All retried commands will always fall outside
> >         the window.  They will be on the "dark side".
> >
> > (4) If the target cant grow maxCmdSN, it closes the
> >     offending connection, or sends out NOPs.
> >
> > Works ..?
> >
> > -Sandeep
> >
> > > In helping others walk through your scenario here in HP,
> > > we all realized that the core solution to the problem
> > > is to mandate a complete execution of a numbered command
> > > (some I/O activity that is trackable) on each connection
> > > once at least every (2^32 -1) commands.  It may be a NOP,
> > > or any regular command.  So, here is my suggestion -
> > >
> > >   An initiator MUST send at least one non-immediate command
> > >   on each of the connections participating in the session,
> > >   for every (2^31 -1) numbered commands.
> > >
> > > Comments?
> > > --
> > > Mallikarjun