OMB: IPv6 by June 2008

Wed Jul 13 04:06:05 UTC 2005

> > How are people making the case for IPv6 with [VOIP]?
> > With G.711 and 20ms voice samples, with IPv4 you get:

If you're running G.711, you've decided that network bandwidth isn't a
problem for your application.  Percentage of overhead doesn't really
matter - it's total overhead bandwidth compared to available bandwidth
that sometimes matters.   There are several different usage scenarios
where there are different tools available for managing bandwidth
consumption
* LANs - you generally don't care
* Single point-to-point calls between general-purpose Internet
endpoints - bandwidth might matter, depending on the pipe size at each
end, and compression can be useful, but usually the more important
problems on small connections are MTU size (because of the latency of
a 1500 byte packet on a 128kbps upstream) and to some extent
prioritization.
* Multiple simultaneous calls between endpoints on a Layer 1 or Layer
2 network - Voice over Layer 2 Frame or ATM has largely fallen out of
fashion, though it worked well for its day.  IP header compression
from vendors starting with C is generally intended for this
environment - some of the versions also support fragmentation to work
around the MTU size problem, but many of them don't work well for
Frame/ATM interworking.
* Multiple simultaneous calls between a pair of Internet endpoints -
there are trunking-style VOIP protocols such as some of the IAX
versions that let you use one set of IP+Layer4 headers to  carry
multiple voice channels, and these can eliminate most of the per-call
overhead (at least when you have most of your channels active, which
is when it matters.)   There are some other VOIP-call-stacking
protocol approaches that at least let you use one set of IP headers to
carry a bunch of {Layer 4 header + Payload} tuples that reduces some
overhead.
* Multiple simultaneous calls at one endpoint to a bunch of
single-call or few-call endpoints across a general IP network.  At the
big end, the easy approach is to just buy fat pipes, but there are
carriers or applications that use header compression on the access
line, either with PPP headers to an access router or frame relay to an
Internet or MPLS edge router.  Unfortunately, we've mostly found it's
difficult to make those solutions scalable - typically the access
cards that are scalable for carrier-sized networks don't do that in
ASICs, and the router doesn't have enough CPU horsepower to support a
significant number of compression sessions in the main CPU at a
reasonable price (where "reasonable" is defined as "cheaper than
adding another access line and a couple more router cards".)
* Encrypted Voice Sessions - the popular approach is to use IPSEC,
which often requires adding a layer or two of NAT traversal UDP
headers as well, so any complaints about the overhead of IPv4 or IPv6
headers on an 8kbps voice session just get multiplied.  It's much more
efficient to do the encryption at the voice layer (at least for
Internet VOIP, as opposed to enterprise VPNs where all the bits are
getting wrapped in IPSEC anyway.)  SIP supports it, and even some
H.323 versions have it tacked on,  but I've found it very frustrating
how much carrier-scale and large-enterprise VOIP equipment doesn't
support payload encryption, so VOIP carriers either don't encrypt
(leaving VOIP wide open to wiretapping without even the grudging
pretense of protection of some of the CALEA rules), even on the media
connection which is between callers, or it's an option that the
carriers didn't buy/provision/activate/whatever.  Skype at least gets
some credit here (though they're using proprietary protocols and
closed source, so it's impossible to tell whether they've done a
secure implementation  that doesn't leak keying material all over the
place), and the Asterisk PBXs are capable of encrypting voice and
signalling channels for many choices of endpoints.

----
             Thanks;     Bill