From: Larson, Chris (Contractor) (Chris.Larson@xxxxxx)
Date: Mon Jul 08 2002 - 14:05:31 GMT-3
Can you do ppp multilink on a line with frame-relay encapsulation? I do not
think so but..........
Frame-relay fragmentation is generally used for interleaving Voice packets
on frame relay links, along with other shaping mechanisms.
-----Original Message-----
From: Tom Larus [mailto:tlarus@cox.net]
Sent: Monday, July 08, 2002 10:14 AM
To: Colin Barber; ccielab@groupstudy.com
Subject: Re: Voice Traffic Shaping questions
About those big packets holding up the little voice packets, would ppp
multilink interleave and fragmentation of all packets on the slow frame
relay links solve that problem enough to get acceptable voice quality
("acceptable" meaning pretty darn good, since there is little tolerance for
jitter when it comes to voice)? Can we use these two features together. (I
really need to nail down which QOS features can be used together, and which
ones cannot. Does anyone have a quick and dirty checklist on this point
that he or she would be willing to share with the group?)
----- Original Message -----
From: "Colin Barber" <Colin.Barber@telewest.co.uk>
To: <ccielab@groupstudy.com>
Sent: Monday, July 08, 2002 3:48 AM
Subject: RE: Voice Traffic Shaping questions
> WFQ does use ip precedence but will not give good voice quality during
> congestion. There will still be jitter due to larger packets holding up
the
> small voice packets and there maybe other data traffic that has the same
or
> higher ip precedence.
>
> TC is calculated by the CIR and BC settings.
>
> Colin
>
> -----Original Message-----
> From: Anthony Pace [mailto:anthonypace@fastmail.fm]
> Sent: 08 July 2002 00:59
> To: Steven Ridder; ccielab@groupstudy.com
> Subject: Re: Voice Traffic Shaping questions
>
>
> Thank you very much for these responses. I very much appreciate them.
>
> So you are saying that WFQ would give the voice more bandwidth by
> virtue of the fact that the packets had some precedence bits set. Are
> you also saying that this would not really be good enough due to the
> fact that WFQ would still attempt to give other traffic so much of the
> "pie" that it could wreck the voice call?
>
> In my Tc question you indicated that I was correct. Am I corredct that
> the mere existance of some "voice" keywords thrttles down the Tc, or is
> it the CIR to Bc ratio that determines this. If it is the latter than
> that explains alot.
>
> Anthony Pace
> ------------------------------------------------
> 4. How do we toggle "tc" interval? All the examples say 125ms. for DATA
> and 10ms. for voice. Do we control it when we set the CIR and Bc ? Is
> it the presence of voice keywords in the config that will throttle it
> to 10s?
>
> If I set CIR=64K and Bc=8K have I set Tc to 125ms?
> If I set CIR=64K and Bc=640 bytes then have I set Tc to 10ms?
>
> You are correct again.
>
>
>
>
>
>
>
>
>
> On Sun, 07 Jul 2002 09:21:34 -0400, "Steven Ridder"
> <saridder@hotmail.com> said:
> > Answers In-line---
> >
> > 1. Is "FRAME-RELAY VOICE BANDWIDTH xx" just used for voice over Frame
> > or is it applicatble to VoIP over Frame? I have seen examples both ways
> > (in books) and I am wondering if one may be a typo.
> >
> > I think it has too do with VoFR if I remember correctly, but I'm too
> > lazy to
> > look it up.
> >
> > 2. If I want to shape for VoIP, can I get away with setting precedence
> > bits on the IP dial-peer and enableing WFQ on every interum interface
> > on every interum router? I read somewhere that just turning on WFQ
> > would cause the precedence bits to be taken into consideration. Is this
> > just wishfull thinking on my part?
> >
> >
> > The WFQ algorithm does take IP Prec values into consideration. So if I
> > have
> > a voice call with DiffServ EF value, it will certainly give me more
> > avail BW
> > than an e-mail, but that's not enough when you are using voice/video.
> >
> > WFQ is what I'd call a "shared" method. WFQ works like shares of a
> > company.
> > If I join a startup, and the company has 8000 shares to give sway,
> > and I
> > get 4000 of them, I'm looking pretty. I have 50% of the shares. If
> > the
> > company grows and it needs to issue more shares to more employees, say
> > it
> > releases up to 80,000 shares, my 4000 shares just became 5%.
> >
> > WFQ woeks the same way. If there are just two types of traffic going
> > across
> > a link, say an e-mail and a voice conversation. Say the voice had 50%
> > of BW
> > guaranteed. My voice call is good and I'm happy. Then say some more
> > people
> > came on line and began browsing the web, watching real player, etc..
> > The
> > WFQ algorithm has to allot them some of the BW to them as well, and it
> > does
> > it by diluting the current allocations. So, the other flows get some
> > BW
> > guaranteed and my 50% could go to 5%, destroying my call.
> >
> > 3. If there are multiple routers between the dial-peers, do we need to
> > apply our traffic-shapaing mechanism to all interum interfaces on all
> > interum routers?, (Queing, RSVP (or whatever mechanism we chose)) I
> > would think the answer is yes if we think the link could degrade the
> > quality of the phone calls. I would think that the only execptions
> > would be that we set the precedence bits, and compress headers only on
> > INGRESS into the IP cloud.
> >
> > Yes, you need a common corporate policy to handle traffic.
> >
> >
> > 4. How do we toggle "tc" interval? All the examples say 125ms. for DATA
> > and 10ms. for voice. Do we control it when we set the CIR and Bc ? Is
> > it the presence of voice keywords in the config that will throttle it
> > to 10s?
> >
> > If I set CIR=64K and Bc=8K have I set Tc to 125ms?
> > If I set CIR=64K and Bc=640 bytes then have I set Tc to 10ms?
> >
> > You are correct again.
> >
> > If anyone knows any of these I would be very gratefull to hear the
> > answers.
> >
> > Anthony Pace
> >
> >
> > --
> > Anthony Pace
> > anthonypace@fastmail.fm
> >
> > --
> > http://fastmail.fm - One of many happy users:
> > http://www.fastmail.fm/docs/quotes.html
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:22 GMT-3