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

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 19 Feb 2003 13:39:08 -0500

> 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

I am afraid there is some confusion on this one.  The 200-300 bytes probably
included the RTP/UDP/IP headers as well.

Bandwidth Calculations	G.711
Packetization Delay (in ms)	20
Payload Speed (in bits per second)	64,000
Payload (in bytes)		160
RTP (in bytes)			12
UDP (in bytes)			8
IP (in bytes)			20
Total Packet Size (in bytes)	200

BUT the issue still stands - Using the G.723.1 coder (which produces 24 byte
frames
every 30 milliseconds), each packet would have only 24 bytes of data to 40
bytes of header.
Thus, the header would be 67% of the entire packet.  The bigger the payload,
the better, with the understood impact should packet loss occur.  Reduce the
ratio by increasing the payload and don't drop any packets on the floor!

-Adam Uzelac

-----Original Message-----
From: GOODE, B (Bur), ALABS [mailto:[email-masked]]
Sent: Wednesday, February 19, 2003 1:08 PM
To: [email-masked]; Ash, Gerald R (Jerry), ALABS
Cc: raymond zhang; [email-masked]; George Swallow; Loa Andersson
Subject: RE: E2E VoIP over MPLS ('VoMPLS') Header Compression 

We (AT&T) and Raymond (Infonet) clearly stated that we were talking
about G.729 at 8 Kb/s.  Curtis responds with an example of G.711 using
64 Kb/s.  We cannot afford more than 30 ms packetization delay in our
delay budget.  20ms would be preferable References to 200-300 byte
packets is just absurd.

Bur

> -----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]>
> , "Ash, Gerald R (Jerry), ALABS" writes:
> > 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 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.
> 
> > The proposal in the I-Ds is to extend VoIP header 
> compression on an end-to-en
> > d basis, in an MPLS context.
> > 
> > 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: raymond zhang <[email-masked]>
Date: Tue, 25 Feb 2003 23:43:15 -0800

Hi Curtis,

Sorry for the delayed response...

>I'm just trying to come up with something that will actually work.

Surely, this is indeed the final objective and do very much appreciate your 
initiating a thread of discussions as engaging as this in helping to 
further clarify and bring focus on the nature of the issues/problems...

A bit more comments in lines below.

Regards,
Raymond

At 02:35 PM 2/20/2003 -0500, Curtis Villamizar wrote:

>In message <[email-masked]>, raymond 
>zhang w
>rites:
> > Curtis,
> >
> > Thanks for the response and see some further comments in line...   Based
> > upon discussions we have thus far including your response to my 
> comments in
> > response to Uzelac's email, maybe I should make some clarifications first
> > which may help my understanding of your input as well in any further
> > discussions:
> >
> > The environment in which I am referring to is a global IP/MPLS 
> packet-based
> > network spanning all major and sub-continents where it is not always
> > possible to get ample bandwidth (over-provisioning) economically (very
> > expensive in fact)...  The issues of delay or packet loss do not normally
> > present problems at all as you pointed out, in some continental or 
> national
> > networks of ISPs or SPs but to offer similar level of integrated services
> > (voice/data) for customers with world-wide locations, it is in these 
> remote
> > regions and over last mile local loops that we spend a bit more efforts on
> > to optimize.
> >
> > On low speed local-loops (PE-CE links), IP/UDP/RTP compressions is
> > needed.  I think we both agree on that.  As for PE doing the comp/depcomp,
> > I'd like to hear a bit more from the Vendors...  My experience has been
> > that hardware based compression at PE levels on the edge of the network
> > with large # of aggregating diffserve-enabled customer links presents
> > complexity that may become unmanageable to SPs and with amount of edge
> > features already processed through hardware, would adding
> > compression/decompression be even feasible ?  Besides,   the upgrade
> > path  may be very costly for these line cards which maybe deployed in 
> large
> > numbers across the global network as we add new feature sets/hardware
> > capabilities.  So I am not in favor of it as an option for PE level
> > routers.   Therefore the concept of distributing compression/decompression
> > into CE levels, not in the network appeals in a great deal.  If PE is not
> > doing the comp/decomp, then the compressed path needs to be e2e...
> >
> > Further comments in lines ....
> >
> > Regards,
> > Raymond
>
>
>The applicability statement part of this is embedded in the draft
>itself, rather than following a requirement document.

There will be a requirements draft per Loa's suggestion and in fact it is 
already submitted.

>You are citing PE-CE as the primary problem.  Others have cited PE to
>PE within the metro.
>
>If the problem is PE-CE, lets stick with that problem.

The problems exist in both cases...

>If PE-CE is the problem you are trying to solve, then RTP/UDP/IP/PPP
>compression should do wonders.  I agree with you entirely that the
>current practical problem there is that the PE can't handle the
>comp/depcomp at anywhere close to line rate on even relatively slow
>interfaces.  The PPS rate for these tinygrams is enormous.  (Of course
>making them bigger would help reduce the PPS rate in addition to
>improving the encaps efficiency).
>
>At one packet per 30 msec, you have 30 pps.  At 8kbit/s a T1 holds not
>quite 200 of these if the PPP encaps was 4 bytes or less.  Times 200
>calls you have 6000 pps.  Nothing at all for a line card, but not many
>of these will start to swamp a route processor if that is how the
>comp/decomp is implemented.
>
>Putting the compression in the CE might on the onset sound appealing.
>If you think you have problems with the PE handling the comp/decomp,
>wait til you try to bring up a full mesh of LSPs to all the CE for
>this sort of scale of global networks.  No sense trading one practical
>limitation for another of much more enormous magnitude.

Well, thus far in our discussion, we have established that we need at least 
comp/dcomp over PE-CE link.  Then we discussed the infeasibility of having 
PE to do comp/dcomp, upon which I come to that the other option would 
carrie compressed VoIP packets over the entire path across the network and 
do comp/decomp outside of the network, for example, at the CE or a large 
aggregation box ( in a voice access only environment and not part of the 
IGP plane of SP's network).

But we would in this case be dealing with comp/decomp distributed 
throughout the network instead of being at the aggregating PEs.  Namely, 
the amount of meshing may be much smaller at the CE level since they are 
customer specific.  This would be further reduced since not every call 
occupies its unique virtual connection.  Calls between the same pair of 
gateways may be aggregated onto the same e2e LSP if LSP is used as an e2e 
path.

Then the meshing on the PE could be limited to a set of aggregating or 
hierarchical LSPs among much smaller # of PEs (comparing to # of connected 
CEs to all PEs) (also since not every customer has locations in every PoP 
around the world which may ease the aggregation load on the PE level 
LSPs)... So this is not a trade at the same scale.  Nonetheless, as you 
pointed out, the scaling issues will worsen (may still be manageable 
depending the degree of the mesh) from provisioning to tunnel maintenance 
(setup/teardown due to link/interface events, e.g.) as number of customer 
sites increase.  I wonder what your thoughts are on the other Ash 
draft 
(file:///D:/onnet-data/out/IPbackbone/ietf/avt/draft-ash-e2e-crtp-hdr-compress-00.txt) 
where LSP does not get extended down to the CE, instead RSVP-TE tunnels are 
built between PEs, yet PE may only spend the first cycle just to establish 
the context state and then do not spend cycles to do comp/decomp for 
subsequent ip/udp/rtp compressed packets ?

>If there is a huge number of CE then at some point you'll have to
>partition the network to make this continue to work.  If so you might
>get CE to some voice/VOIP aggregation box/gateway and have these
>terminate the LSPs and do comp/decomp, then communicate among
>themselves.  This is likely to be a huge comp/decomp load.  You can
>concentrate the comp/decomp at some specialized processor or try to do
>the processing on the line cards (which may mean new line cards).

Could be an option but preferably not on the direct diffserve path into the 
network, in other words, placed behind the CEs, for example...

>If a CE is supporting on the order of at least 100 (to 200 if encaps
>efficiency can be improved), then muxing might be easier on the PE
>router.  For example, separating 300 pps of 600 byte packets is likely
>to be a lot easier (even if 6000 pps are sent out) than compressing
>and decompressing 6000pps and would add zero delay.  Either way,
>moving processing to the PE line card seems essential.
>I'm just trying to come up with something that will actually work.
>
>Regards,
>
>Curtis
>
>ps - wrt queueing and serialization delay.  30bytes into a T1 incurs a
>serialization delay of 240bits/1.5mbits or 0.16 msec.  200 bytes is 1
>msec serialization.  If CE means customer handset then we're e2e MPLS
>becomes completely absurd so I think it should be safe so assume at
>least T1 and it not you get delay.  With serialization times on the
>order of 1 msec edge and these days under a microsecond in cores, the
>queueing argument has never held water for priority queued traffic
>that is not congested.
>
>That's a moot point for a single flow if you have to hold the playout
>time for 200 msec to get 200 bytes packets because that is already an
>excessive delay.  For multiplexing, the argument against large packets
>based on serialization and queueing simply doesn't hold up.
>
>We're not talking IP over barbed wire in the third world, right?  Its
>at least T1?

Well, sub-T1/E1 are quite common as well...

> > >Tiny payload is needed for queue efficiency is a myth left over from
> > >the ATM days.  It is simply not true.
> >
> > I think there are two aspects in this...  Firstly traffic flows with
> > constant packet size would improve queue efficiency (M/D/1) and smaller
> > packet payload would reduce delay across low speed links (not an issue 
> once
> > again in areas of network with large pipes since no or little qeueuing)
> > which is required as part of the budge delay planning.  The voice quality
> > is provided on a per path basis not just over segments of the path inside
> > SP's major portion of the backbone.   ( I don't mean to spur another 
> around
> > of discussions on ATM vs. IP at all ! I thought issues are well understood
> > by now).