RE: iSCSI: Flow Control

[Jim McGrath <Jim.McGrath@quantum.com>]

I agree with Peter.

We should allow immediate data, but only up to a limit previously set by the
target (so we have a chance that it is received).  But the target has to be
given the ability to dynamically change (in Peter's terms, advertise) the
resources available, and be able to do it selectively (i.e. to one initiator
and not another).  This inability to change the resources deployed for this
purpose over time is why current schemes are not implemented (no target
wants to get "caught" and so drastically underadvertizes the actual
resources it has available).

Jim




-----Original Message-----
From: Peter Johansson [mailto:PJohansson@ACM.org]
Sent: Friday, September 29, 2000 2:57 PM
To: IP Storage
Subject: RE: iSCSI: Flow Control


At 04:39 PM 9/29/00, Black_David@emc.com wrote:

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

I suggest that you split the question:

1) Is immediate data desirable when the initiator has certain knowledge 
that the LU is idle (with respect to the initiator)?

2) Is immediate data desirable when the LU may be busy.

I think the answer to 1) is "Yes", make provision for the initiator to send 
immediate data---but also make provision for the initiator to obtain some a 
priori knowledge as to the quantity of data the LU will accept in the idle 
state. There need not be a negotiation between initiator and LU; it could 
be sufficient for the LU to advertise its capabilities.

In the case of 2), the answer might vary dependent upon whether or not 
those LU resources used to obtain data from the initiator are fully 
occupied when the LU is other than idle.

If most of the optimization is realized in case 1), it might obviate the 
need for complicated schemes needed to make immediate data in case 2)
useful.




Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson@ACM.org