Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 19 Feb 2003 10:29:06 -0500

Curtis,

>I think the SPs should speak as to whether the bandwidth inefficiency
>of 30 byte payloads or the potential to lose a packet with a 200 byte
>is a greater problem.  

Both are important issues, but if you read the first few sentences of http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt you'll see that bandwidth efficiency plays a major role in the motivation for the proposed capability.  Further, the packet sizes quoted in the I-D are typical for VoIP in SP networks, as Raymond noted.  Also, VoIP header compression (cRTP, for example) is in use in SP networks on a link by link basis to address the bandwidth efficiency issue.  

The proposal in the I-Ds is to extend VoIP header compression on an end-to-end basis, in an MPLS context.

Your suggestions for muxing voice calls into larger packets connote a PSTN/TDM-like model.  Some people actually think that the TDM model is pretty efficient for voice, however, VoIP is another matter, and has issues for larger packets, e.g., increased e2e delay, etc.

Jerry

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Feb 2003 11:24:41 -0500

In message <[email-masked]>
, "Ash, Gerald R (Jerry), ALABS" writes:
> Both are important issues, but if you read the first few sentences of http://
> ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt you'll see 
> that bandwidth efficiency plays a major role in the motivation for the propos
> ed capability.  Further, the packet sizes quoted in the I-D are typical for V
> oIP in SP networks, as Raymond noted.  Also, VoIP header compression (cRTP, f
> or example) is in use in SP networks on a link by link basis to address the b
> andwidth efficiency issue.  

30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes                62% overhead
30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes	  21% overhead
200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes		  19% overhead
300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes		  14% overhead

No header compression and larger frames seems to be the winner as far
as efficiency goes even if you could compress the header to 8 bytes.

> Your suggestions for muxing voice calls into larger packets connote a PSTN/TD
> M-like model.  Some people actually think that the TDM model is pretty effici
> ent for voice, however, VoIP is another matter, and has issues for larger pac
> kets, e.g., increased e2e delay, etc.

You don't mux calls, you collect the frames of a single call and
introduce some assembly delay.

Audio compression techniques typcially do a good job of silence
suppression and vary in the amount of data they send.  Even the best
(that produce reasonable quality audio) consume up to 64 kbit/sec when
someone is actively talking and near nothing on silence.  What would
you consider the average transmission rate for compressed audio?
Somewhere around 16-32 kbit/sec?

To assemble a 300 byte packet at 64 kbit/sec you need under 40 msec,
200 msec gets you 25 msec.  If you set a queueing delay point (as
recommended all over the place for RTP) of 50 msec, you'll get packets
over 300 bytes, and probably an average of well over 200 bytes.

> Jerry 

Please correct me if I'm wrong but your drafts seem to require end2end
MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP.  Since
you are providing new RSVP/TE objects the assumption seems to be
RSVP/TE MPLS edge to edge.  If traffic engineering is done within
regions as can be done with current RTP/UDP/IP/MPLS regardless of
whether LDP is also used, that works fine and scales extremely well.
E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to
scale well in a single provider and is almost certain to become a
severe problem crossing SP boundaries.

Curtis

---

From: "Jim Hand" <[email-masked]>
Date: Wed, 19 Feb 2003 14:51:42 -0500

A 50ms queuing point with a G.711 codec will yield packets over 300 bytes.
A 50ms queuing point with G.729x codecs will yield packets under 50 bytes.
With G.729x with no connection muxing 200-300 byte payload sizes yield
200-300ms delays.

	This is why I had been assuming, apparently along with some others, that
you were talking about connection muxing.

Jim Hand

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Wednesday, February 19, 2003 11:25 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]; raymond zhang; [email-masked]; George Swallow;
> Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS;
> Dave Cooper
> Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression
>
>
>
> In message
> <[email-masked]>
> > The proposal in the I-Ds is to extend VoIP header
> compression on an end-to-en
> > d basis, in an MPLS context.
> >

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Feb 2003 16:20:44 -0500

In message <[email-masked]>, "Jim Hand" writes:
> 	This is why I had been assuming, apparently along with some others,
> that you were talking about connection muxing.
> 
> Jim Hand

I wasn't before but you are correct.  200-300ms delays would be
intolerable and you would have to resort to muxing for reasonable
efficiencies.  40 msec queueing point and RTP/UDP header compression
only might be a reasonable interim.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Feb 2003 18:28:36 -0500

In message <[email-masked]>, "Jim Hand" writes:
> Also, neither draft requires end-to-end MPLS between VoIP endpoints.  One of
> the drafts
> (http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt)
> requires MPLS between the compressor and decompressor.  The other
> (http://ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt )oes
> not require MPLS all the way between compressor and decompressor.  Neither
> draft requires that the compressor and decompressor also be VoIP endpoints.
> 
> Thanks,
> Jim Hand

By end to end I meant compression device to compression device.  I did
say gateway to gateway which might imply VOIP device.

The argument I was making was that if the compression device is very
far toward the edge of the network, then the number of LSPs explodes.
If the compression device is moved closer to the core of the network
such that a full mesh of RSVP/TE LSPs are feasible, then opportunity
for multiplexing is enormous.

If you are going to burden the CPU at the "compression device" why not
have it multiplex rather than header compress and get huge improvement
in encapulation efficiency rather than relatively small improvement in
encapsulation efficiency.  This also makes it feasible to more the
compression closer to the edge and maybe into the VOIP gear rather
than a router concentrating VOIP gear traffic.

Thanks again,

Curtis

---

From: Abhijit <[email-masked]>
Date: Thu, 20 Feb 2003 15:00:29 +0530

I remember reading some work done on Voice over MPLS directly without using RTP/UDP/IP overheads. Is that work going to be a part of MPLS WG? 
IMO, RTP/UDP/IP is a lot of overhead, compared to VoMPLS approach which actually serves the same purpose (atleast in bearer path)

Regards, 

-abhijit.

On Wed, 19 Feb 2003 18:28:36 -0500

-- 
"It's easier said than done."

... and if you don't believe it, try proving that it's easier done than
said, and you'll see that "it's easier said that `it's easier done than
said' than it is done", which really proves that "it's easier said than
done".

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Feb 2003 08:25:32 -0500

In message <[email-masked]>, Abhijit writes:
> 
> I remember reading some work done on Voice over MPLS directly without using R
> TP/UDP/IP overheads. Is that work going to be a part of MPLS WG? 
> IMO, RTP/UDP/IP is a lot of overhead, compared to VoMPLS approach which actua
> lly serves the same purpose (atleast in bearer path)
> 
> Regards, 
> 
> -abhijit.

That work died a long time ago because it required that e2e (or encaps
device to encaps device) LSPs be used.

MPLS RSVP/TE (or LDP) is **NOT** an end2end virtual circuit
technology.  RSVP/TE is a traffic engineering tool.  It has so far
been successfully very applied to traffic engineering localized to SP
core or SP regions.  With the addition of GMPLS it becomes a bit of a
carrier's swiss army knife, supporting dynamic traffic engineering
over optical and TDM but deployment of GMPLS may be a ways off.

The reason I'm objecting to the drafts that were offerred is that they
also required e2e (compression device to compression device) RSVP/TE
LSPs and as a result may be impractical (ie: doomed to the same fate
of the prior voice/MPLS effort).

Ideally some scheme that allowed end users to encapsulate very
efficiently but also met carrier needs would be best.  That idealized
goal doesn't seem feasible.  For the end user (for example, using
voice over IP from PC to PC) adding delay and increasing packet size
seems the only feasible option.  For the carrier, multiplexing streams
from a gateway seems to me to be a more attractive solution than a
special encapsulation between gateways that requires an e2e (do I need
to repeat the disclaimer on e2e again) RSVP/TE LSP to work.

Curtis

ps - end2end in this sort of context (MPLS, RSVP/TE or LDP) is always
assumed to mean at most edge of the carrier's network, not end user.
This is because end user to end user in an MPLS discussion is so
absurd that it can't possibly be intended as part of the discussion.
E2e is assumed to mean the edge of whatever is being discussed, the
edge is the voice compression/encaps gateways in this context.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Feb 2003 10:21:40 -0500

In message <[email-masked]>, "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.

That is where the RTP/UDP/IP header compression can be utilized.
Either Casner's older RFC specifically for PPP or the newer one
(rfc3095) specifically for cellular.

> 	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.

Right.

You can't possibly do MPLS RSVP/TE from the customer edge all the way
to the other customer edge, so voice/MPLS is an immediate non-starter.

The aggregation router will need to decompress headers and forward.
If and only if backbone bandwidth is a pressing issue does any header
compression or multiplexing need to be done in the backbone.

Alternately you need a compression over IP that doesn't require e2e
RSVP/TE MPLS (for some large value of e2e).

> Jim

What the SPs probably could really use for the access circuit
bandwidth problem is the RTP/UDP/IP header compression done on the
line cards rather than sent to the route processor (to be handled by
the onboard macintosh as one person at an ISP used to like to say when
680x0 was the processor on his routers).  I'm probably not the first
person to think of that, but I don't know that anyone has done it yet.

Curtis

---

From: David Charlap <[email-masked]>
Date: Thu, 20 Feb 2003 12:26:10 -0500

> to the other customer edge, so voice/MPLS is an immediate non-starter.

If used in the context of voice-through-internet, then yes.

But it may still be useful within a voice carrier.  Think of how voice 
carriers currently run their voice circuits over ATM.  You don't have an 
ATM circuit going all the way to your home.  If carriers want to 
eventually merge their voice and data infrastructures, then voice-over- 
MPLS sounds like something they may want.

But I don't think there's any need for the IETF to get involved in such 
development, since the only IP-related component would be managing the 
LSP itself, and existing protocols are adequate for that task.

-- David

---

From: "john smith" <[email-masked]>
Date: Thu, 20 Feb 2003 23:56:52 +0530

> > to the other customer edge, so voice/MPLS is an immediate non-starter.
SS7 :-) doesnt come tell your telephone....

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Feb 2003 13:12:18 -0500

> If used in the context of voice-through-internet, then yes.

You are completely igoring the context of this statement which was if
you try to solve the problem CE to CE then voice/MPLS is a
non-starter.

So I guesss we agree.

> MPLS sounds like something they may want.

So we're back to ATM again (why doesn't that surprise me), and
specifically ATM used in the metros.  :-)

f so, the CE-PE-...-PE-CE described in the draft just applies within a
metro and so CE-PE-...-PE-CE is really incorrect.  It might just be
that the applicability is seriously overstated in the draft.

> LSP itself, and existing protocols are adequate for that task.

What we are gradually establishing is that the practical scope of this
work is much more limited than the internet-draft would imply.  Given
the state scope of the internet-draft, the technique it is presenting
is inpractical at best if not infeasible.  It would seem from this
thread that for certain problems, like CE-PE link, and PE to PE across
an entire SP (rather than just within a metro), there are better
solutions.

If this is a technology that for practical reasons is applicable only
for the metro but would in fact be useful for the metro, just have the
internet-draft say that and move on either accepting it acknowledging
its limited applicability or not accepting it.

Curtis

---

From: "Jim Hand" <[email-masked]>
Date: Wed, 19 Feb 2003 17:37:20 -0500

Thanks,
Jim Hand

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Feb 2003 09:30:22 -0500

> draft requires that the compressor and decompressor also be VoIP endpoints.

Jim,

I suppose you didn't read any of this thread where I said more than
once that e2e means compressor to decompressor in this context since
it couldn't possibly mean anything else and e2e is shorter to write.
It is the only interpretation that makes any sense whatsoever so it is
sufficiently unambiguous to carry on an email conversation.

draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te mpls for the
above definition of e2e which I hope I don't have to repeat with every
email message.

draft-ash-e2e-crtp-hdr-compress-00 requires either of two conditions.
1) e2e rsvp/te mpls (for the above definition of e2e), 2) every router
along the way knows how to do compression and decompression.

Case #2 is the one that SP are saying is impractical because the PE
CPU is overloaded with too many PPS.  Except for this practical matter
case #2 is every bit as good a solution for the CE-PE links as rfc2508
over PPP links (with most CE-PE being PPP).  Needless to say that
makes case #2 completely absurd in the core (comp/decomp on oc192c
interfaces).

That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e
rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which
requires e2e rsvp/te mpls plus requires every hop in the path to
support comp/decomp making it even worse.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Feb 2003 11:58:54 -0500

In message <[email-masked]>, "Jim Hand" writes:
> 	Maybe we need to re-write draft-ash-e2e-crtp-hdr-compress-00 to clarify
> .  I
> will look into this.
> 
> 	This draft does require RSVP TE e2e over the MPLS part of the network, 
> but
> it does not require that MPLS or RSVP TE be extended to CE's.  And it does
> not require that the original compressor and decompressor be attached to
> MPLS.
> 
> 	Also, it does require that routers other than MPLS "P" routers have the
> ability to support compression and decompression.   But that does not mean
> that these routers will have to *perform* compression and decompression on
> each compressed packet.  Routers that support compressed packets on both
> input links and output links should only have to perform a
> decompression/compression cycle on a small fraction of the total number of
> packets.  Most compressed packets would be switched from input to output
> without performing decompression and compression.
> 
> Thanks,
> Jim

Jim,

What we are trying to establish is if you are actually solving a
practical problem Which has two parts.  The first is identifying what
problem it is you are trying to solve.  The second is determining if
what you are suggesting solved the problem.

If the discussion so far is valid, the problem is CE-PE and the simple
solution of just compressing on the CE and decompressing on the PE has
a practical problem of overloading the PE.  Having P routers support
compression and decompression **is part of the current problem**.

If the above paragraph is not valid for some reason, please start by
telling us what problem you are trying to solve, then tell us why the
techniques in these drafts solve the problem without creating a bigger
problem elsewhere.

Regards,

Curtis

---

From: "Jim Hand" <[email-masked]>
Date: Wed, 19 Feb 2003 23:05:20 -0500

You could then do connection muxing inside the Service Provider's network.

Thanks,
Jim
> Sent: Wednesday, February 19, 2003 6:29 PM
> To: Jim Hand
> Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS;
> raymond zhang;
> [email-masked]; George Swallow; Loa Andersson; GOODE, B (Bur),
> ALABS; Dave
> Cooper
> Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression -
> End-to-End MPLS
>
>
>

---

From: "Jim Hand" <[email-masked]>
Date: Fri, 21 Feb 2003 10:56:00 -0500

Maybe we need to re-write draft-ash-e2e-crtp-hdr-compress-00 to clarify.  I
will look into this.

	This draft does require RSVP TE e2e over the MPLS part of the network, but
it does not require that MPLS or RSVP TE be extended to CE's.  And it does
not require that the original compressor and decompressor be attached to
MPLS.

Thanks,
Jim

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Feb 2003 13:26:26 -0500

> it would be necessary to do compression on the access link in many cases

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.

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

---

From: "Jim Hand" <[email-masked]>
Date: Fri, 21 Feb 2003 17:56:45 -0500

> Sent: Friday, February 21, 2003 11:59 AM

> compression and decompression **is part of the current problem**.

Neither of the drafts require P routers to support compression and
decompression.

> techniques in these drafts solve the problem without creating a bigger

A problem statement/requirements document will be submitted for discussion
on the list.

---

From: Loa Andersson <[email-masked]>
Date: Sun, 23 Feb 2003 18:41:35 +0100

All,

it wouldn't be hard to make the point based on this discussion that I 
tried to
make when this discussion just started.

I seems like a good idea to split the docs into two
 
1. problem and requirments
2. the solution

I can't really escape the impression that what is going on here is that 
one is
looking into the solution to try to find out what the requirments really 
were.

/Loa

Jim Hand wrote:

>>>>Cc: [email-masked]; raymond zhang; [email-masked];
>>>>        
>>>>
>>George Swallow;
>>    
>>
>>>>Please correct me if I'm wrong but your drafts seem to
>>>>        
>>>>
>>require end2end
>>    
>>
>>>>MPLS where RTP/UDP/IP/MPLS normally requires just end2end
>>>>        
>>>>
>>IP.  Since
>>    
>>
>>>>whether LDP is also used, that works fine and scales
>>>>        
>>>>
>>extremely well.
>>    
>>
>>>>E2E RSVP/TE MPLS all the way to each peice of VOIP gear
>>>>        
>>>>
>>is unlikely to
>>    
>>