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

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

Cheng,

A flow control scheme is required beyond TCP as target and initiator traffic
must be handled separately over the same connection.  Unfettered, the
initiator will consume buffers required by the target for completion of
commands.  A type of buffer to buffer control is required beyond TCP.
Presently, there is an optional command window which can provide only
rudimentary control with respect to a common medium.  Buffer to buffer
credits for the underlying media allows specific control where needed. It is
also important to allow multiple targets to be carried over the same
connection to reduce connection count.

By having a flow control scheme that resolves to the real target, buffers do
not become bloated and thus you do not have head of queue blocking hiding a
SCSI ping. 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. :(

Doug


> > > You are 100% correct.  If we have a table defining all possible error,
> not
> > > receiving the PDU with the right StatRN is one.  The question becomes
> how
> > > long do you wait?  I also understand your position in using ping every
> 10
> > > seconds so we don't need to wait four minutes to decide if TCP
> > > connection is gone.
> >
> > Wouldn't the ping simply queue up behind other undelivered TCP
> > data?
> > --
> >  Glen Turner                                 Network Engineer
> >  (08) 8303 3936      Australian Academic and Research Network
> >  glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
>
> You are referring to TCP implementation with software.  In an
> TCP-Offload-Engine (TOE) adapter, there is no queue.  Every
> incoming frame,
> including the ping is served at the speed of the wire .  This is must a
> because BB-Credit only slows the adapter down to match the incoming frame
> rate to the host memory bus speed rate.  The TOE adapter takes the ping
> frame from incoming FIFO and sends reply back immediately to the outgoing
> FIFO, no queuing and no waiting.  The adapter does the same for the Fibre
> Channel ACK frames.  The same mechanism can even be used to TCP ACK's, if
> properly designed.
>