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 3:56 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: Flow Control
> 
> 
> > > However, some have wanted to use the sliding window to 
> solve a different
> > > problem.  They want to enable the target to advertise to 
> the initiator how
> > > many commands the target is able to receive.  This 
> apparently is not 
> specified
> > > in SAM-2, and SAM-2 deals with overflowing the command 
> queue in an ugly way 
> -
> > > throw the commands away and enter an error state.
> > >
> > > 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.
> 
> FC has a command queue overflow problem because it is a 
> datagram protocol
> and cannot at the transport layer finely control the sender.

Not true, but not relevant either -- take my word for it.

>..............................................................But
> with a reliable stream protocol I don't understand how you could
> ever get a command queue overflow.  If you command queue is full
> you simply stop reading from the TCP stream which will eventually
> cause the TCP input buffers to fill and the window to shrink to
> zero causing flow to stop. Short of a naive implementation that
> reads the TCP stream (thus keeping the window open) with no place
> to put the command it just read, I still don't see the problem.
> 

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.

By the way, 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.

Charles