ISCSI: flow control

["Matt Wakeley" <matt_wakeley@agilent.com>]

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.



-Matt Wakeley
Agilent Technologies