RE: a vote for asymmetric connections in a session

[Michael Krause <krause@cup.hp.com>]

At 10:12 AM 9/12/00 -0700, Y P Cheng wrote:

>With or without ACK, a new NIC adapter has taken on a lot of TCP tasks such
>as reordering, retransmission, and congestion flow control. (See my other
>posting on how the  RTT and data transfer are handled like having an
>asymmetric queue.)  In fact, the adapters with VI implementation can easily
>perform RDMA for TCP, hence, eliminating the TCP memory-to-memory copy
>overhead.

Zero processor copy implementations of TCP have been implemented and can be 
implemented with an iSCSI engine in hardware.  I don't see this as an issue.

I do agree that the use of RDMA is a very compelling and would like to see 
this specified.  Back at the first BOF, I requested that the RDMA be 
aligned with InfiniBand's semantics and potentially headers (would fit in 
the TCP options space) since this would allow simple bridging to be 
implemented independent of the underlying I/O interconnect (PCI, PCI-X, 
InfiniBand) in the long-run while enabling higher-level storage protocols 
such as SVP to re-use the iSCSI hardware (I believe some one else noted 
this benefit as well).

>Without a NIC card, we can implement equivalent functions in the
>iSCSI driver. I hope in defining the iSCSI protocol we should consider the
>power of the new NIC adapters without worrying too much on the old
>programming model of TCP queuing and stack processing.

It is not difficult to implement in hardware nor requires that much in 
terms of driver modifications to accommodate.  The issue is how one 
implements the h/w / s/w interface and as many FC implementations have 
shown, this is not that difficult to do and achieve zero processor copy 
solutions.

Mike