|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: TCP RDMA option to accelerate NFS, CIFS, SCSI, etc.
True. You can do everything by processing headers... but the you need to
understand all the protocols that are amased over TCP. To do it in silicon
it will probably make sense for a subset.
RDMA is a general purpose solution and the user decides what to do with it.
You can look at it as a simple way to enable the protocl stack and the
application to completely separate the protocol state machine (defined by
headers and/or trailers) from the payload.
As for the vulnerability to attacks with a good size RDMAID and some
imagination you can get the same level of protection as with the TCP
sequence number (even a bit better because sequence numbers can be guessed
from context).
Julo
Alan Cox <alan@lxorguk.ukuu.org.uk> on 25/02/2000 15:17:05
Please respond to Alan Cox <alan@lxorguk.ukuu.org.uk>
To: julian_satran%ibmil.RSCS@STUTVM1.DE.IBM.COM
cc: David.Robinson@EBay.Sun.COM (David Robinson), ips@ece.cmu.edu,
tcp-impl@grc.nasa.gov (bcc: Julian Satran/Haifa/IBM)
Subject: Re: TCP RDMA option to accelerate NFS, CIFS, SCSI, etc.
> Gb/s it requires some innovation and lots of silicon. The RDMA option
makes
> it possible at a far lower price. And the zero copy it enables might go
> deep into the application space as it is only an annotation on packets.
I am not convinced the amount of silicon changes between the two. The
RDMA id make be faked by an attacker so must still be verified.
Va Jacobson proposed and to an extent implemented a system where the user
context does all the TCP work. In that sort of situation and with a more
sensible API than the BSD socket one you dont appear to need a lot of
silicon,
in fact the worst case is the wildcard.
Alan
Home Last updated: Tue Sep 04 01:08:18 2001 6315 messages in chronological order |