RE: iSCSI: Flow Control

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

See my responses below.

> -----Original Message-----
> From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
> Sent: Friday, October 06, 2000 9:38 AM
> To: IPS@ece.cmu.edu
> Subject: RE: iSCSI: Flow Control
> 
> 
> Pierre,
> I am not sure that I agree.  I do not understand how a credit 
> process to an
> initiator, solves the problem (if it is a problem) with 100s 
> of initiators
> some of which can be dormant for long periods of time and 
> very active at
> others.  I believe that the current command window meets all the real
> problems.  You did put your finger on the key solution, that is the
> management of the Target Buffers, by the target.
> 
> 
> .
> .
> .
> John L. Hufferd
> 
> 
> Pierre Labat <pierre_labat@hp.com>@ece.cmu.edu on 10/06/2000 
> 09:00:08 AM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   IPS@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: Flow Control
> 
> 
> 
> 
> 
> Hi,
> 
> From the mails on this thread it seems that most
> people agree on the following ?
> 
> A) Unsolicited data will be allowed by iSCSI.
> Well, i think that the protocol must be able to handle
> large quantities of unsolicited data to be performant
> for the writes on large latency networks.
> 

This should be done using the method described by Charles Binford, where the
target advertises the amount of unsolicited data it can accept per request
via a mode page.  In my opinion, obtaining performance in high latency
environments is an implementation issue, not a protocol issue.  Products
need to be tailored to such environments by including the appropriate amount
of buffering resources.


> B) We need of course a flow control on the data
> because even if we have a flow control on the commands,
> just a few commands with huge unsolicited data could
> overwhelm the target buffers.
> 

I agree with John and others on this point. The problem with a strict credit
scheme is resource underutilization. For that reason, I like something more
like Randy Haagen's proposal in an earlier posting, where the logical unit
advertises static advisory values that work "most of the time", with the
proviso that the initiator may still get an occassional queue full
condition. With long flight times, of course, this would need to be
buttressed by some method of flushing the pipeline when such an error
occurred. That said, additional tools would still be needed so the initiator
can control the amount of inflight commands and data.

With regard to the various dynamic credit allocation proposals, I'm hesitant
to jump on that bandwagon without some behavioral data from real life. Of
course, there's still the ultimate feedback loop from the user to the
storage provider when performance goes down the tubes or cost goes through
the roof.


> C) We need a flow control on the commands to avoid
> the TASK SET FULL condition. If the target hit this condition
> it has to drop command (return task set full) and
> drops data associated. Avoiding the task set full condition
> avoid too the "dead locks".
> 

As noted above, a better approach is one that avoids queue full most of the
time with some way to resychronize both ends of the pipe when it does occur.

<remainder deleted>

Charles