[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: is 1 Gbps a MUST?
At 08:57 PM 2/21/2002, Fred Baker (firstname.lastname@example.org) wrote: > > At 03:06 PM 2/21/2002, CAVANNA,VICENTE V (A-Roseville,ex1) wrote: > >If my interpretation is correct, the current (and earlier ones too) > >security draft at > >http://www.drizzle.com/~aboba/RDMA/draft-ietf-ips-security-10.txt > >seems to say that an IPSec implementation MUST be capable of > >running at 1 Gbps. > > I won't respond to the wording of the draft, but to the sense > that it must be intended to convey. If the wording doesn't > convey this, it is the wording which must change. > > It seems to me that if the transfer of encrypted data at nominal > link rates is expected, then encryption and decryption must be > achieved at link rates. If 1 GBPS link rates are in view, guess > what rates are important. If 10 GBPS... > > It seems to me that the question is not whether or not you are > mandated to implement IPSEC in software, but what you need to do > to accomplish link speed encryption and decryption. Hardware and > software are duals; you can implement the algorithm either way, > and the trade-off is money vs speed. > > We offer our customers both software and hardware options for > IPSEC, and if the expected encryption rate is above certain speeds, > we get fairly insistent on the latter. We call that "common sense". While wire speed parity is ideal, there may be queuing within the IPSEC engine ahead of TCP receive buffers and this will have the effect of pacing the send as the window will be consumed by this queue together with an apparent RTT increase. This does not mean packets must be dropped should the engine lag behind wire speed. Framing offered in SCTP allows segments to be processed irrespective of reception order as does IPSEC, but for such a scheme to be used with TCP, a generalized convention should be adopted within the transport to accommodate pre-application processing that may include a robust checking scheme together with PDU to buffer assignments. Placing PDU pre-processing and PDU to buffer assignment at the IP layer is onerous as advocated by iSCSI. Even combined with TCP, without standardized conventions, a selective process based on application association must be employed. Each new application then imposes unique interfacing and processing by means of these hodgepodge structures. Each application will also need optimization to modularize this unique and optional transport layer processing which will likely become application specific networking APIs. Creating conventions for this technique, if to be included within TCP to assist high speed processing, forestalls degeneration of standardization. Doug
Last updated: Fri Feb 22 11:17:59 2002
8846 messages in chronological order