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

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

Jim,

Protection from spoofing as proposed is obtained with frame alignment, if
out of sequence processing is allowed.  To allow reception of frames without
headers, as possible without alignment, non-IDed sequences are not excluded
and must be held and verified by other means adding significant complexity.
Out of sequence processing would be practical should sending and receiving
agents both support an alignment.  As your proposal would not merit benefits
without alignment for both zero copy and out of sequence processing, it is
specious to suggest such alignment implementation is only suggested.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Jim Williams
> 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
>
>