[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>Also, any compute-in-advance approaches only help under light load,
paul>and do nothing for you under high load.
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
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
 The remaining CPU time until the next 20 msec interrupt is then available
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,
DSP (DSP because of the need for a voice codec function in an IP phone).
counter mode synchronization allows precomputation of the receive keystream
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