Re: ISCSI: flow control

[Michael Krause <krause@cup.hp.com>]

At 02:28 AM 9/20/00 -0700, Matt Wakeley wrote:
>Well, David thinks there's consensus on flow control, but I just wanted to
>make sure some issues are clear:
>
>
> > (1) An iSCSI session containing a single TCP connection
> >         should not be required to use the currently specified
> >         iSCSI command reference numbers and sliding window
> >         mechanism because TCP will deliver commands in order.
> >
>
>The iSCSI spec originally implemented command reference numbers to "order"
>commands that are delivered across multiple TCP connections.  The sliding
>window was added so that if a tcp connection dies, the remaining tcp
>connections don't flood the target with (now potentially) out of order
>commands.
>
>It's true that an iSCSI session containing a single TCP connection, or an
>iSCSI session containing a multiple TCP connections but using the
>"asynchronous" model does not require command re-ordering or the sliding
>window.  Only the "synchronous" model with multiple TCP connections requires
>both.
>
>However, some have wanted to use the sliding window to solve a different
>problem.  They want to enable the target to advertise to the initiator how
>many commands the target is able to receive.  This apparently is not specified
>in SAM-2, and SAM-2 deals with overflowing the command queue in an ugly way -
>throw the commands away and enter an error state.
>
>The question here is whether iSCSI should attempt to solve the command queue
>overflow problem, or allow T10 to deal with it.  Other protocols (fibre
>channel) already deal with it in the "ugly" fashion - perhaps so should
>iSCSI.  What we need consensus on is whether or not iSCSI is going to deal
>with this.

The "ugly" mechanism is undesirable for a variety of reasons including fast 
convergence / recovery upon data loss.  A credit system is simple to 
implement and provides a way to bound this problem and the implementation 
complexity (whether in software or hardware or if operating across a set of 
adapters).   With a single connection implementation, this is trivial to 
accommodate and future multi-port or multi-adapter solutions can take 
advantage of it as you note with minimal effort.  Given this does not 
really impact a single connection solution, what compelling reason is there 
for removing its definition / requirement within the spec at this point?

Note: I believe there are also other advantages to always having this 
present beyond the stated problem.

Mike