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

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

The starting assumptions for the proposal were that the transport
must be TCP, and TCP could not be modified in any way.  If you
don't buy the starting assumptions, it may be a waste
of time to discuss the specifics of the proposal.

NO changes or new options to TCP are proposed.
Frame alignment is not a requirement,
only a recommendation, so no existing TCP APIs and kernel
implementations need to change.  (Perhaps I sould soften
"recommendation" and make it "possible feature to be
considered by implementators when convenient".)

The CRC is certainly open for discussion.  It looks
to me like I can do a software CRC in 3 risc instructions
per byte of data using a moderately sized table lookup
(less that 32KB).  Is a CRC a good thing or a bad thing?
Should it be optional or required?

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


>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.  As SCSI does not benefit from VI
>with zero copy already possible with frame alignment, the area where there
>could be commonality has been missed with the choice of CRC.  Rather than
>modifying thousands of TCP implementations, it would seem appropriate to
>leave TCP as is and concentrate on providing these improved features using
>SCTP designed to handle these requirements together with additional
features
>yet to be resolved with TCP.  You need not convince systems to change TCP
to
>benefit from rather important features found with SCTP.  Do not encumber
TCP
>with disruptive options.  SCTP can emerge using UDP and become supported
>without making these changes to TCP that you advocate as evolutionary.
Once
>you implement frame alignment, the API for TCP becomes unusable as it does
>not afford means of discerning frames.  SCTP implementations already
address
>these problems and so I do not see your approach as evolutionary but rather
>revolutionary.  You do not get my vote on this approach.
>
>Doug