Re: RDMA over TCP (Was Re: VI (Was: Avoiding deadlock in iSCSI))

["Jim Williams" <jimw@giganet.com>]

-----Original Message-----
From: Douglas Otis <dotis@sanlight.net>
To: Jim Williams <jimw@giganet.com>; ips@ece.cmu.edu <ips@ece.cmu.edu>
Date: Tuesday, September 26, 2000 2:52 PM
Subject: RE: RDMA over TCP (Was Re: VI (Was: Avoiding deadlock in iSCSI))



Regarding:
    ftp://coke.giganet.com/rdma-tcp.txt

>Jim,
>
>In summary, you expect kernel modifications of TCP API to allow frame
>alignment, a hardware based 32-bit CRC that uses a different polynomial
than
>FCP and a direct copy method at the NIC.

I do not expect kernel modifications.  The motivation for RDMA is to allow
a NIC to directly place received data in the target buffer without
kernel intervention or host data copy.  One can certainly argue how
and whether this should be done and whether there should be a protocol
independent mechanism for RMDA.  However if the received data must
be processed by the kernel, it might as well be processed in order
using the conventional API without any changes.  One could argue
that some small performance gains could be had by doing kernel
modifications, but my guess that this is way insufficient to justify
modifying the API.

>Both FDDI and FC have selected a CRC polynomial ignored
>by your proposal.

Ethernet, FDDI, and FC all use the same CRC polynomial.  When encapsulating
a CRC within an ethernet frame, it really doesn't make all that much
difference what polynomial is used, the only important requirement is
that it be relatively prime to the ethernet CRC polynomial so that
coverage is additive, not redundant.

>Recommending, suggesting, or offering a feature of frame
>alignment and out of sequence processing rend the TCP API.  There are
better
>alternatives to your proposal in SCTP, so I fail to see the justification.

I agree that there are somewhat easier ways to accomplish the objectives
with SCTP, but my goal was to show that it can be done with TCP.  The
justification is that there are customers that want to buy TCP.
In the short term there are some fundamental infrastructure issues
that favor TCP.  Things like the availability of well tested reference
implementations, availibility of test, design, and QA tools that
understand TCP, availability of more engineers and other professionals
that understand TCP.  Ultimately in the long term, it may make sense to
support both TCP and SCTP and let the market place decide which
will prevail.