The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Feb> msg00044



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

E2E VoIP over MPLS ('VoMPLS') Header Compression

  • From: raymond zhang <zhangr@info.net>
  • Date: Tue, 18 Feb 2003 21:55:45 -0800
  • Cc: curtis@fictitious.org, "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, "MPLS@UU.net" <MPLS@UU.NET>, "George Swallow" <swallow@cisco.com>, "Loa Andersson" <loa.andersson@utfors.se>, "GOODE, B (Bur), ALABS" <bgoode@att.com>, "Hand, James C, ALABS" <jameshand@att.com>

At 10:48 PM 2/18/2003 -0500, Curtis Villamizar wrote:
Hi Curtis,

>In message <5.1.0.14.0.20030218154944.0283e668@delta.info.net>, raymond 
>zhang w
>rites:
> >
> > Regarding payload size, firstly the voice frame size varies with the ITU
> > codecs selected on the CPE.  For example, G.729a has 10ms per voice
> > sampling frame and one could configure to stuff either two or three frames
> > per VoIP packet... Hence 20 to 30 byte payload.  Larger payload size may
> > present an issue in terms of loss, esp for a global network since loss of
> > one packet would result in multiple voice frame losses.
> >
> > As for vendors, I'd say any CPE vendors should have this capability 
> built in.
> > ..
>
>
>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.  All of the SP I've spoken to that are doing
>VOIP are using diffserv EF service or otherwise insuring that voice
>traffic is rarely if ever dropped.

Surely...  bandwidth inefficiency is certainly of a great concern to 
SPs.   In areas where ample capacity can absorb any kind of network 
abnormality, some SPs has choosen not to even have diffserve provisioned at 
each HoP which would warrant larger payload size.  There are two areas, 
where EF is essential to provide a consistent level of statistical 
performance targets for voice traffic which are prone to congestion - PE-CE 
links and where SP's network spans over capacity scarce or expensive 
regions...  One example, if GK is not used and calls are made directly 
between two CEs across the network, there is basically no bandwidth 
admission mechanism to regulate the call request...  If EF bandwidth is 
allocated for 100 calls, when the 101st call comes in, EF would police 
across all voice packets of all calls hence packet drops may occur (the ash 
draft using rsvp signalling may resolve this issue).  In cases such as 
these, smaller payload size may help minimize the frame loss ratio while 
bandwidth efficiency may then be achieved via header compression...  These 
are just a couple of reasons I would like to voice support the two Ash drafts.

Regards,
Raymond



>Curtis