VoIP over IPsec
Steven M. Bellovin
smb at research.att.com
Mon Feb 17 14:11:45 UTC 2003
In message <006401c2d655$abb5d560$93b58742 at ssprunk>, "Stephen Sprunk" writes:
>
>Thus spake "Charles Youse" <cyouse at register.com>
>> In order to cut costs in our telecom budget I'm toying with the idea
>> of replacing a lot of our inter-office leased lines with VPN
>> connections over the public Internet. [...]
>> Assume for the moment that latency and bandwidth are not an issue;
>> e.g., any two points that will be exchanging voice data will both have
>> transit from the same provider with an aggressive SLA.
>
>Latency, bandwidth, and packet loss are moot. Jitter is VoIP's enemy.
>
While jitter is more important, you can't ignore the others. The
traditional phone network has long had a delay budget -- each component
is supposed to bound how long it takes to process voice. Bandwidth
matters, too, because the serialization delay for a packet increases
the latency at that hop.
This causes problems for compression and IPsec. You can get better
compression -- and hence reduce bandwidth demands -- by compressing
longer samples. Of course, this means that you can't finish the
compression until the end of that time interval, which increases the
latency. The obvious solution is to compress shorter segments, but
that means that the IPsec overhead is a significant portion of the
bandwidth consumed, which again has latency implications for
bandwidth-limited channels.
I'm not saying you can't do this; I am saying that under certain
circumstances, there may be issues. Latency, for example, is a
psychoacoustic phenomena (did you enjoy the last call you made over a
satellite circuit? I didn't.)
And yes, I had to crunch the numbers on this for my day job a few years
ago.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)
More information about the NANOG
mailing list