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

From: "GOODE, B (Bur), ALABS" <[email-masked]>
Date: Wed, 19 Feb 2003 13:07:30 -0500

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: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Feb 2003 15:14:03 -0500

In message <[email-masked]>
> delay budget.  20ms would be preferable References to 200-300 byte

Bur,

Thanks for the clarification.  btw- Even G.722 is 24 to 32 kbit/s.

All of these encoding seem to sample at 20 msec.  At least doubling up
to 40 msec would be reasonable and very simple.  I can understand if
you don't want to do that.  Please read on.

AFAIK G.729 is used for cell phone only and there are good reasons to
send very low bandwidths and small packets over the airways.  Even if
you did G.729 end to end, you're not going to do RSVP/TE signaling
from cell phone to cell phone or cell phone to POTS handset.  (Please
correct me if I'm wrong about that).  If you are doing G.729 end to
end, and really want 20-30 msec, then I suppose you really do have to
either 1) mux at the gateway or 2) increase the delay a bit, 3) live
with tiny payloads.

[Aside: If the RTT on a cellular link is as high as 100-200 msec (each
end of a call), fussing over another 20-50 msec in the core does not
seem to me like it should be such a big deal, but that's also not my
decision.]

Even if you are going to go G.729 end to end (voice gateway to voice
gateway), you certainly won't be doing per call RSVP/TE signaling
(correct me if I'm wrong).  It will be at most one RSVP/TE tunnel
gateway to gateway.  If so, you can keep the small delay budget and
mux except in the rare case of one call per gateway pair.  If there
are that many gateways that one call per gateway pair is common, it is
extremely unlikely E2E RSVP/TE signaling is going to scale.  If the
number of gateways is much smaller, then multiplexing becomes feasible
in principle and can even reduce the delay down to 10-20 msec while
keeping payloads large.

This leads to the question - if multiplexing is feasible in principle
is it practical.  RTP itself doesn't supports multiplexing except by
means of channels.  The number of channels and mapping of channels
could be mapped using SDP and a new SDP "a=" attribute.  If you don't
like SDP or would prefer not to use it, you'd need some other protocol
to maintain the mapping of channels to calls.  I'm sure this is
different from your current encapsulation but so is VO/MPLS with
header compression and it might be something that Infonet might be a
lot better off doing than trying to create end2end RSVP/TE sessions.

If you are really are going to pursue this sort of design, then it
would be helpful to know how scalable RSVP/TE would need to be and how
you plan to maintain scalable RSVP/TE signaling.  Hierarchical will
only get you so far.

You might want to consider just compressing the RTP/UDP headers,
yeilding as little as 24 byte overhead (IP+4) instead of 40
(IP+UDP_RTP).  This would eliminate the reliance on E2E RSVP/TE.

btw- I sincerely thank you for replying.  Too many SPs are too silent
publicly about what they want to do, making IETF work harder.

Regards,

Curtis

ps - [aside: any thoughts on AMR and AMR-WB rather than G.729?
23kbit/s for AMR-WB except during congestion.  Larger packet sizes
might actually releive some of the cell site congestion and the
100-200 msec delays though I understand rfc3095 can address this to a
large extent.]