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

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

Jim,

Manage frame based data using a byte stream, especially when out of sequence
processing is permitted?  The API must allow for this type of data handling
foreign to TCP.  As such, this proposal changes the API to allow these
modifications with respect to both send and receive regardless how the
proposal is worded.  Both FDDI and FC have selected a CRC polynomial ignored
by your proposal.  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.

Doug

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