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

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

Glen,

The timeout for a connection should be much longer than the time required to
plow through a buffer.  Again this buffer should be kept lean using a
separate flow control from that of TCP.  I see little advantage in
attempting to process a connection probe out of sequence.

Doug

> Y P Cheng wrote:
>
> > 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...
>
> The BSD socket API won't allow this sort of look-ahead for a
> standard TCP segment.
>
> So for iSCSI Ping and Ping Response to be worthwhile to allow
> software implementations to implement fail-over schemes, the Ping
> and Ping Response should use TCP's Urgent feature to allow
> out-of-order delivery of the Pings to the socket held open by the
> iSCSI target?
>
> So maybe we need to add:
>
>    Ping and Ping Response SHOULD be marked by TCP as urgent data [RFC793].
>
> Do we need to allow for that BSD4.2 mis-interpretation of the TCP
> urgent pointer?  Does iSCSI have a Null command that we can require
> as padding before the Ping commands?
>
> --
>  Glen Turner                                 Network Engineer
>  (08) 8303 3936      Australian Academic and Research Network
>  glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
> --
>  The revolution will not be televised, it will be digitised
>