Re: iSCSI: Flow Control

[David Robinson <David.Robinson@EBay.Sun.COM>]

> 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. 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. My
misunderstanding seems to be rooted in a different philosophy between
the SCSI model and the distributed filesystem model.

	-David