SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


Home

Last updated: Tue Sep 04 01:06:32 2001
6315 messages in chronological order