From: Mike Schlenger (mschlenger@xxxxxxxxxxxxxxxxxxxxxxx)
Date: Mon Jul 08 2002 - 15:16:04 GMT-3
Thanks for the doc reference. I never even heard of this before..... and
here there's an RFC attached to it. Go figure. As I was looking at the docs,
I noticed that you're not necessarily encapsulating data in ppp.....you're
just establishing a ppp chap/pap session over frame relay. Very interesting
stuff and worth the extra look.
Mike
Mike Schlenger
CCIE #7079
-----Original Message-----
From: Shane Miles [mailto:smiles@ftdata.com]
Sent: Monday, July 08, 2002 11:54 AM
To: 'ccielab@groupstudy.com '
Subject: RE: Voice Traffic Shaping questions
It is possible to do PPP over Frame Relay. I've used it with Link
Fragmentation and Interleaving. I've also tested PPP Multilink over Frame
Relay. It works pretty well.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos
_c/fqcprt6/qcflfifr.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_
4/pppframe.htm
-----Original Message-----
From: Mike Schlenger
To: 'Tom Larus'
Cc: 'ccielab@groupstudy.com'
Sent: 7/8/02 11:56 AM
Subject: RE: Voice Traffic Shaping questions
If you have slow frame relay links, you can't use ppp since they are both
layer 2 protocols. If you subscribe to frame relay service they I would use
LLQ (Low latency queuing) along with frame relay traffic shaping. I have
several production examples of working configurations. Alternately, follow
the links below:
LLQ for VoIP over Frame
http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/q
oswa
n.htm#xtocid27
Frame Traffic Shaping
http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/q
oswa
n.htm#xtocid20
Mike
CCIE #7079
-----Original Message-----
From: Tom Larus [mailto:tlarus@cox.net]
Sent: Monday, July 08, 2002 9: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