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

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

Cheng,

> > From: Douglas Otis [mailto:dotis@sanlight.net]
> > Sent: Wednesday, November 01, 2000 9:25 AM
> >
> > 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.
>
> For those of us who design adapters, we punt the flow control problem to
> ULP.  For an adapter, ULP must pre-allocated buffers for
> receiving incoming
> segments.  For flow control, I think you are referring the buffers used by
> TCP/IP, RAID or File Systems.  Without flow control, when incoming TCP
> segment overflows, an adapter just throws them away.

No, it is not related to the normal use of SCSI.  Normally, SCSI targets
control exchanges.  For FC, it is done using credit tokens.  A transport
using IP must provide an additional flow control scheme to allow the target
the ability to access data from the initiator without communication buffers
closing.  Should the initiator fill buffers preempting the ability of the
target to proceed.  That would mean adapters directly handing the IP
transport of SCSI must include this flow control scheme.  For it to extend
to multiple targets, a B-B credit token would be the most straight forward
means of accomplishing this and would allow taking advantage of RFC 2960.

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

I wonder the advantage of side stepping the queue if you are attempting to
test response through the queue.  Yes, the queue can be side-stepped, but to
what advantage?  If there is adequate flow control, such side-stepping
should not be required.

> > 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. :(
>
> Yes, to saturate a fibre channel adapter, you need more than 10 fastest
> 15000 rpm drives.  A TOC-Offload-Engine adapter is capable of running at
> wire speed.  But, it relies on ULP to take advantage of this speed.

Doug