RE: iSCSI: Flow Control

[Black_David@emc.com]

> Sorry for not being more explicit. The window can close as C2+D2 (but
> mainly D2) are not consumed as they are processed after C1.
> 
> The scenario holds and the blocking results from a "order reversal" of the
data in the stream
> caused by enabling both immediate data and R2T.

In which case, this target should forbid immediate data if its buffer
resources
are that slim; I think we're in violent agreement on that.

Putting my WG co-chair hat back on:

The open question to the list is whether there's value in allowing
some amount of immediate data (e.g., for targets that need fast startup on
long latency connections, and are prepared to deploy the buffering required
to make it work reliably), or whether we ought to follow FCP-2 and forbid
immediate data, which will impose a round trip delay (command out, R2T
back) before data starts to flow.  I think I've seen a couple of comments
in favor of this, but more discussion is in order.

--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
---------------------------------------------------