RE: Keep-alive traffic (was iSCSI: more on StatRN)

["Douglas Otis" <dotis@sanlight.net>]

David,

I agree a SCSI ping should not be processed out of sequence.  Your
description of LU flow control is a bit difficult to follow.  At this point
in time, flow control is target based and not LU based.  I would advocate
making SCSI flow control medium based rather than LU or target based.
Rather than attempting to virtualized many targets on different network
medium appear as a single target together with inordinate overhead, flow
control at the point of access to hidden network medium using class 3
controls and keep the targets independent.  Rather than requiring a
connection per target (drive) these drives can share a connection at the
point of access (SCSI portal).  Rather than dividing a WAN into micro
channels, fewer connections allows significantly lower latency with bursty
SCSI traffic.

Doug

> > The adapter treats ACK's and Pings packets separately.  It has the
> > intelligence to know the ACK of fibre channel.  It could be
> programmed to
> > handle iSCSI pings.  As that in TCP-zero-copy, with cooperation
> from the TCP
> > driver, the adapter can even be programmed to handle the TCP
> ACKs without
> > queuing or waiting.  I guess this is a different way of
> avoiding blocking.
>
> This is not how a streaming protocol like TCP works, you cannot discard
> TCP
> segments and then process a later ping. If you toss a TCP segment it
> will
> keep coming back to you repeatedly until you process it. You won't even
> see the iSCSI ping until you have processed all the data before it.
> Unless
> you want the adapter to understand the ULP (which you said you did not)
> you
> must pass things up and the ULP must have buffers available or the
> adapter
> must assert TCP flow control which you said you didn't need to do...
>
> > > Do not forget about the buffers feeding the individual mediums.
> > > A device being serviced by this server interface is only able
> to deliver
> > > about 200 requests per second where most of these requests
> are small. Only
> > > by joining together several targets will wire speed be possible
> > > on any given connection. Unfortunately, iSCSI does not allow this
> > provision
> > > and hence requires a connection per target. :(
>
> One disadvantage of multiplexing different LUs on the same TCP
> connection
> is that you cannot leverage the TCP flow control.  If the LUs command
> buffers are full whether you assert an iSCSI level flow control or TCP
> level flow control doesn't matter much.  With a shared connection it
> is important that you don't TCP flow control so that one LU with a full
> command queue doesn't block another that is available.
>
> 	-David
>