[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSec for IP Telephony
paul>Sure, but I've yet to see a DES implementation so poor that it added
paul>anywhere near 10 ms to the latency, especially for the sort of packet
paul>sizes you're likely to see for this application.
paul>
paul>Also, any compute-in-advance approaches only help under light load,
paul>and do nothing for you under high load.
paul>
paul> paul
In the low-end IPSec telephone terminal application I described, the
speech load is constant, and a properly designed system would always be able
to
precompute the keystream in advance of the voice codec having the data
available. For example, every 20 msec, on a H/W interrupt basis, the CPU
performs a vocoding analysis operation, encrypts the resulting packet (or
portion thereof) with precomputed Tx keystream and queues it for output,
decrypts the incoming packet using precomputed Rx keystream, synthesizes the
received voice, and calculates the two new keystream values for the next
packet.
The remaining CPU time until the next 20 msec interrupt is then available
for
management/supervisory functions.
Also note that the round trip latency figure I quoted includes four
instantiations of 3DES (#1 Tx -> #2 Rx -> #2 Tx -> #1 Rx) on a low-end,
low-cost
DSP (DSP because of the need for a voice codec function in an IP phone).
Using
counter mode synchronization allows precomputation of the receive keystream
as
well as the transmit keystream.
I admit that for a router or high-end device, this issue is a "don't
care". However, for internet telephony to take off, I think low-end,
mass-market, inexpensive (less than $50 retail), desktop IP terminals will
be
necessary.
Frank
Follow-Ups: