The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <000001c2d8f0$d5941e80$3a785b87@mt.att.com>, "Jim Hand" writes:
> 	In many VoIP services I am working with, the most important place for
> bandwidth efficiency is on the access link between the customer premise and
> the provider edge.  There is limited opportunity at the customer premise for
> connection muxing, because of the limited number of connections.  So I think
> it would be necessary to do compression on the access link in many cases
> anyway.

What is the range of bandwidths of the CE-PE links?

It we are talking at least 80 kbit/sec links, then you can mux 10
calls to the PE for 300 byte packets.  Pulling apart the packets might
be easier than header twiddling.  Pulling them apart and remuxing
into large packets might also be easier than header twiddling.

The practical problem here is entirely the CPU on the PE.

> 	You could then do connection muxing inside the Service Provider's netwo
> rk.
> But in order to do the connection muxing, you would likely have to
> decompress the packets first (perhaps there might be some way around this).
> This would require a place in the network where you would have to do both
> compression/decompresion and connection muxing/demuxing.  That's a lot of
> load at some aggregation points in the network.  With the end-to-end
> compression, we were hoping to push the compression load out toward the
> edges, where there are more boxes to apply to the compression load, and
> avoid it altogether within the SP transport network.
> 
> Thanks,
> Jim

Jim,

Doing the compression at the edges would be the most sensible.
Unfortunately edge to edge (which is also compression to compression
in this case) RSVP-TE is unlikely to scale to the very large number of
CE.  Even PE to PE is unlikely.  If you have the PE or P do
decompresion we've already established that the PE gets overloaded.

Therefore, RTP/UDP header compression, leaving the IP header intact,
seems to make more sense.  It only gets efficiency up from 30/70 to
30/54.  Beyond that doing an adaptive encoding that moves the playout
point might be worth considering.  At 80 msec rather than 30 msec,
efficiency would then be 80/104 with RTP/UDP compression.  Its the
SP's call whether increasing delay only in times of congestion but
maintaining near zero loss would be an attractive tradeoff.  Beyond
100 msec you may discourage some callers also reducing congestion but
due to a noticable drop in service quality (which might no longer be
an attractive tradeoff).  The benefit is that the PE/P are not
required to do anything.

To do RTP/UDP header compression e2e, you need some form of signaling
to setup.  This might be worth pursuing.

If you can get the PE to do RTP/UDP/IP header comp/decomp this would
further improve the CE-PE but lose the gain in the core.  If you could
also get the PE to do RTP/UDP comp/decomp on the core side, this would
further improve the situation in the core.  This is a lot to ask the
PE to do and in many cases would require that you replace the PE which
one SP already ruled out.

Curtis