The MPLS WG Archive

["Jim Hand" <hand17@earthlink.net>]

	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:curtis@fictitious.org]
> Sent: Wednesday, February 19, 2003 11:25 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net; 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
> <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com>
> , "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
>