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

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

Jim,

There are practical reasons.  Lower CPU overhead is substantial motivation
possible with SCTP together with significant reductions in latency.  You
will not see much improvement using TCP.  You may view the CRC polynomial as
insignificant, but the present selection is robust. Certainly, you are not
arguing an improved CRC is needed.  An additional CRC is added when there is
*NO* CRC protection within and between pieces of equipment and not because
the CRC within Ethernet is not sufficient.  If you were to use an adapter to
encapsulate FDDI, or FC, then keeping the CRC compatible opens the door to
native access.  Changing the CRC would have little advantage and significant
disadvantage.  As you can cleanly add SCTP at this point in time, compared
to attempting the same with TCP, customers are more likely to be receptive
to these improvements should the NIC interface not change for TCP and yet
new features are offered with SCTP.  In America, innovation sells.  SCTP can
claim the TCP heritage together being compatible to VI and SCSI innovations
while blowing the doors off.

Doug

> -----Original Message-----
> From: Jim Williams [mailto:jimw@giganet.com]
> Sent: Friday, September 29, 2000 7:21 AM
> To: Douglas Otis; rdma@cisco.com; ips@ece.cmu.edu
> Subject: Re: RDMA over TCP (Was Re: VI (Was: Avoiding deadlock in
> iSCSI))
>
>
>
> -----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.
>