RE: iSCSI:flow control, acknowledgement, and a deterministic reco very

[Black_David@emc.com]

> The main reason for selecting 0 and not a flag for immediate delivery was
> to enable immediate delivery even when the command window is closed.
> 
> However we can achieve the same effect by using an immediate flag and
> using the current CmdSN without advancing it.  With this we get a
> reference to where in the stream the command where supposed to act if the
> stream order is important.

I think this causes resource management complications on the target
because reusing the CmdSN for an immediate command requires a new
command buffer, unless we allow the target to arbitrarily reject/abort some
command to make room, which seems wrong (the immediate command
may not be a task management command, and even then arbitrary
rejects/aborts may not be desirable). 

How is this better than requiring the Initiator to not permit the command
window to close (i.e., the Initiator always keeps one slot in the window
open for one immediate command, or N slots for N immediate commands,
or no slots if it wants to live dangerously)?  I think existing (SCSI and
FC)
Initiators have to do this sort of resource management anyway, as I don't
believe immediate commands are exempt from TASK_SET_FULL.

There appears to be a "no free lunch" principle here in that some piece
of the iSCSI Initiator-Target system somewhere has to be cognizant
of the fact that resources for immediate commands are being 
reserved on the target, and Initiator control of the command window
(coupled with a requirement that MaxCmdSN never decrease) seems
to be the easiest way to get there. 

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------