The MPLS WG Archive

[raymond zhang <zhangr@info.net>]

Hi Uzelac,


At 01:39 PM 2/19/2003 -0500, Uzelac, Adam wrote:
> > 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!

Surely if you could maintain 0% or near 0% packet loss ratio over all voice 
paths (e2e) during busy hour, tho upper bound delay limit  becomes 
increasingly difficult to meet esp for inter-continental calls (worsened by 
longer propagation delay) in which paths include the low speed CE-PE links...

Regards,
Raymond


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