Re: iSCSI: Flow Control

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

If what Doug says is true, lets please stop this discussion!
We have much bigger fish to fry than trying to build a better TCP!

	-David

Douglas Otis wrote:
> 
> David,
> 
> I think that Pierre is explaining how to re-engineer a TCP stack to allow
> just-in-time delivery of iSCSI packets to be sent to allow last moment
> re-ordering.  As he points out on the receive side, as long as the TCP
> segments are in order, the receive side should be shallow.  His concept of
> head of queue blocking is only from the perspective of the sending side.
> One other means might include some heuristic indicating the size of the send
> buffer but that would be part of the pacing he is employing.  I would
> imagine two send queues would be employed with different priorities.  These
> would not be a standard TCP implementations but of no concern to the
> proposed draft.
> 
> Doug
> 
> > Pierre,
> > I don't know if I completely understand what you are proposing,
> > but is seems that you are proposing to process TCP segments out
> > of order.  As I have said in a previous message, this is extremely
> > dangerous as the TCP layer will not ACK any segment until all previous
> > segments are processed. Without an ACK the segment may be retransmitted
> > many times and that will require iSCSI to track what has been processed
> > and what has not by adding a segment number.  Essentially duplicating
> > TCP segment numbers, SACK doesn't help either.
> >
> > If you are proposing that iSCSI simply keep receiving data without
> > doing the SCSI layer processing and thus at the SCSI layer processing
> > them out of order.  This is feasible but it is still subject to buffer
> > restrictions that would cause data to be discarded which is the whole
> > point of these flow control discussions, to minimize data being
> > discarded.
> >
> > What I strongly object to is any feature in the iSCSI layer that
> > requires
> > any direct manipulation of the TCP layer features like the window
> > pointers.
> > Implementations are free to violate layering as an optimization but
> > it MUST be possible to have a functional implementation without
> > knowing any details of the TCP implemenation.
> >
> >       -David
> >
> > Pierre Labat wrote:
> > >
> > > julian_satran@il.ibm.com wrote:
> > >
> > > > Pierre,
> > > >
> > > > You are wrong again. When the target reopens the window -
> > i.e., reads some
> > > > data from the
> > > > pipe at his end you get to put your Read command - but it
> > goes after the
> > > > rest of the window and
> > > > window can be several megabytes.
> > >
> > > Julian,
> > >
> > > The TCP window is not a buffer on the receive side.
> > > On the receive side, in our case (the target) and as far as TCP segments
> > > arrive
> > > in order, there is not an opaque  FIFO containing a full window size of
> > > command/data
> > > waiting to be processed. You can avoid that.
> > > What the target does is: receive bytes through the TCP
> > connection, does the
> > > TCP work
> > > and forms a iSCSI PDU. The maximum you have to store is a few
> > TCP segments
> > > to re-build the PDU. As soon as the PDU is built it is processed.
> > > When the target wants to close the TCP window it updates accordingly the
> > > window and CONTINUEs to process the incoming PDUs.
> > > At that point you assume that the incoming PDUs are put in an
> > opaque FIFO, but
> > >
> > > rather than that,  the target can process them and put the data
> > a the right
> > > location in the target cache.
> > > Then, when the window is opened again and the read PDU comes,
> > it is processed
> > > immediately.
> > >
> > > In fact as Y P Cheng described in a previous mail in this
> > thread, the model
> > > that
> > > can be used for iSCSI traffic is different of the common model
> > we have for
> > > regular
> > > TCP/IP networking although a  TCP fully complient with the
> > RFCs can be used
> > > for iSCSI.
> > > In regular TCP/IP networking the application (on the transmit
> > side) fills
> > > a FIFO that the adapter empties. In our case as explained by Y P Cheng
> > > you replace the FIFO by an "exchange table" what i called a flat
> > > array. It allows you to avoid the head of queue blocking at this level.
> > >
> > > On the receive side (the target in our case) in regular networking,
> > > the incoming data are tossed in a FIFO by TCP. The application
> > > empties this FIFO and can block (in this case the FIFO grows)
> > > and yes, when the application unblock, it has a large amount
> > > of PDUs to process.
> > > But in the model described the application never blocks. Hence
> > there is no
> > > big receive opaque FIFO on the target. In our case the
> > application is the
> > > module that
> > > process the iSCSI pdus. The application never blocks because it
> > is able to
> > > pace down
> > > the flow coming from the initiator with the TCP window and the command
> > > flow control (MaxCmdRN).
> > >
> > > Regards,
> > >
> > > Pierre