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

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

Cheng,

You misunderstood my point slightly.  There must be a separate flow control
above TCP flow control that a specialized adapter must implement.  RFC 2960
allows multiple flow controls and is a different subject.  Again, what
advantage is there in handling a connection probe out of sequence?

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...
>
> A TCP-Offload-Engine will interpret the TCP/IP header in order to
> move data
> payload directly to application software.  Doug has just pointed
> out that in
> so doing, the adapter must obey the rule of flow control specified by
> RFC2960.  Since the TOE adapter is going over the TCP/IP header,
> all I said
> was with changes to the TCP/IP software like that of zero-copy
> TCP function,
> the adapter can generate ping-response automatically.  No, we are not
> discarding any unprocessed TCP segments.
>
>
>