Re: iSCSI: Flow Control

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

> > 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.  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.

	-David