RE: is 1 Gbps a MUST?

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

At 08:57 PM 2/21/2002, Fred Baker (fred@cisco.com) 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