RE: iSCSI: Flow Control

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: David Robinson [mailto:David.Robinson@EBay.Sun.COM]
> Sent: Wednesday, September 20, 2000 10:54 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: Flow Control
> 
> 
> > You're almost there.  Since the TCP connection carries 
> control traffic for
> > all logical units, you don't want the flow of control 
> information to stop
> > due to the command queue on one LUN becoming full (a kind 
> of head-of-line
> > blocking).  SAM gets around this by implementing what you 
> refer to as the
> > naive policy. i.e., it maintains continuous flow through 
> the pipeline by
> > dumping commands when the queue fills.
> 
> I have always been advocating a connection per LUN so this 
> problem seems
> to reinforce my belief. But I agree that if the WG wants multiple
> LUNs per connection this problem needs to be addressed. 

As I said earlier:

"..........even if the TCP connection only serviced a single LUN, you'd
still want to keep the pipeline flowing to insure that SCSI task management
commands would eventually get serviced."

> .......................................................My lack of
> understanding comes from my NFS background where NFS over TCP in
> practice doesn't have a flow control problem even though it is common
> to mux multiple mount points over a single connection.  The simple
> reason why this is not a problem is because the initiator (client) 
> doesn't issue more requests to the target (export point) than it can
> buffer. The question is if the protocol expects the initiator to
> send more commands than a LUN can queue. If so this can be defended
> against either statically at session establishment (assumes command
> queues lengths are static) or dynamic flow control.

Agreed.  If there is agreement that this is an issue, a solution along those
lines might be possible.  As I recall, though, there seemed to be a rough
consensus that any policy for regulating control traffic should be specified
in SAM-xx (i.e. by the T10 committee), not within iSCSI.  There seemed to be
no consensus on whether or not this was an ips problem, however.

Charles