The MPLS WG Archive

[raymond zhang <zhangr@info.net>]

At 10:46 AM 2/19/2003 -0500, Curtis Villamizar wrote:

Hi Curtis,

Sorry I went off-line yesterday...  Pls see further comments in line below.

>In message <5.1.0.14.0.20030218213848.03324f20@delta.info.net>, raymond 
>zhang w
>rites:
> > 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 
> frame
> > s
> > > > 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
> > .
>
>
>Let me see if I understand this.  If you have 101 calls you have some
>(misguided) notion that you drop less with tiny payloads and lots of
>overhead.

Good point...my brief description above is not the best example to 
illustrate this.  However issue remains in such situations.  Upper bounds 
in terms of delay and loss need to be maintained in a much stricter sense 
for such real-time class as voice...  Also, as Bur and Jerry pointed out, a 
payload size of 20 to 30 bytes enables us to do that much better across the 
voice path in delay budget planning  in terms of queue efficiency (per HoP 
delay and variance), esp across the lower speed local-access links at lower 
sub-T1/E1 rates in an integrated data/voice environment.  It may be more 
pronounced when the voice path spans across multiple continents with low 
speed last mile connections.

>If you had large payloads the same link would hold 120-150 calls
>depending on how large the payload was.

You meant muxing voice frames from multiple calls into one packet ?  Now I 
understand a bit what you are referring to, altho not all customer 
locations have same number of concurrent calls, many remote locations with 
very small # of concurrent calls.  That means we would either have voice 
packets with variable frame-sizes on EF queues or stuff more voice frames 
from the same call into one packet ?

>Next question - is your notion of drop more with larger payloads only
>applicable to ATM when packet shredding is being done rather than
>discarding entire frames?  Don't all modern ATM switches support PPD?
>If this is an ATM only issue and furthermore an old ATM switch issue
>its probably not one for the IETF to address.

No.  It is over a MPLS packet network


>The way things have been explained to me is an attempt is made to keep
>no more than about 30% of the bandwidth on a link for EF (or pick a
>number) and leave the rest for IP.  The actual EF reservation might be
>40% to 70% of the link so if you went to 101 calls and only 100 fit,
>IP would be squeezed out of some more bandwidth than you'd like it to.


A larger EF allocation on an egress interface may starve the rest of the 
data queues... That's why there is upper bound for EF allocation.  Of 
course, the higher the link speed, the higher EF bandwidth can be allocated 
(e.g. local-access link).  In addition, EF traffic is policed which will 
not erode into bandwidth space allocated for other classes.


>Are you talking about EF on an IP or MPLS diffserv network or a VC on
>an ATM network or TDM where you have to reserve exactly what you
>expect to use and get hammerred if you use ever so slightly more?

EF on MPLS diffserv network...


>This is what has been recommended in the diff-serv and MPLS WGs almost
>since the diff-serv WG started.  The technique is certainly no secret.
>A few people at SPs have hinted that their employer may consider the
>fact that they are using it to be some sort of secret.
>Curtis