RE: ISCSI: flow control

[Robert Snively <rsnively@Brocade.COM>]

>  >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.
>  
>  The "ugly" mechanism is undesirable for a variety of reasons 
>  including fast 
>  convergence / recovery upon data loss.  A credit system is simple to 
>  implement and provides a way to bound this problem and the 
>  implementation 
>  complexity (whether in software or hardware or if operating 
>  across a set of 
>  adapters).   With a single connection implementation, this 
>  is trivial to 
>  accommodate and future multi-port or multi-adapter solutions 
>  can take 
>  advantage of it as you note with minimal effort.  Given this 
>  does not 
>  really impact a single connection solution, what compelling 
>  reason is there 
>  for removing its definition / requirement within the spec at 
>  this point?

Actually, the ugly problem is not made much less ugly by having
a credit system.  The problem is that the command receipt resources 
of a "target" are oversubscribed during periods of high activity on 
a properly configured system simply because of the statistical
characteristics of storage access.  The command resources are also
shared among multiple sessions.  The only way to guarantee credit
is to share the credit out among the multiple sessions.  This
necessarily leaves a lot of unused resources lying around for
sessions that are not very busy at a given instant and unnecessarily
limits the capabilities of those sessions that are busy and would
otherwise be able to make constructive use of those resources.
The result is higher latencies and lower throughputs than you would
hope.  What you really need is dynamic credit allocation, which will
always leave the possibility that a particular session may find
itself oversubscribed and forcing busy indications.  Which is effectively
the mechanism SCSI uses today.

Bob Snively
Brocade Communications           Phone  408 487 8135
1745 Technology Drive
San Jose, CA 95110               Email   rsnively@brocade.com