The MPLS WG Archive

["Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>]

> 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:bgoode@att.com]
Sent: Wednesday, February 19, 2003 1:08 PM
To: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS
Cc: raymond zhang; MPLS@UU.net; 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: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
>