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

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Feb 2003 11:09:30 -0500

In message <[email-masked]>, raymond zhang w
rites:
> 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

Raymond,

For every SP I've spoken to, and most have "I" in front of the "SP",
loss in the backbone for voice is effectively held to very near
absolute zero.  Any variation in demand is absorbed first by the fact
that they are somewhat overprovisioned, and second by taking some
resources from IP through preferred queueing of the VOIP traffic.

If you are now talking about CE-PE links, you've changed the problem
statement.  For this problem, the best solution might be to put the
existing RTP/UDP/IP/PPP header compression on the PE line cards rather
than in the route processor to solve bottlenecks there.  That's a
practical problem, not a standards issue.

Curtis

---

From: raymond zhang <[email-masked]>
Date: Thu, 20 Feb 2003 05:32:11 -0800

Hi Uzelac,

Regards,
Raymond

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