From: Filyurin, Yan (yan.filyurin@eds.com)
Date: Sat Jun 23 2007 - 09:18:25 ART
That is where I got most of my information from and I am not fully
convinced. So in case of FRTS is the behavior the same then and at what
point, must you be accumulating credits?
-----Original Message-----
From: Joseph Saad [mailto:joseph.s.saad@gmail.com]
Sent: Saturday, June 23, 2007 3:36 AM
To: 'Bit Gossip'; Filyurin, Yan; 'Mike Kraus (mikraus)'
Cc: ccielab@groupstudy.com
Subject: RE: Help with concept explanation
Shape peak refills Bc + Be tokens (instead of just Bc tokens for shape
average) into the token bucket for each Tc. However, bucket size is the
same for both shape average & shape peak and is equal to Bc+Be.
Shaping rate (in case of shape peak) will = configured rate in the shape
peak command * (1 + Be/Bc)
More information can be found at Wendel Odom's, Ip Telephony Self-Study
Cisco Qos Exam Certification Guide
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Bit Gossip
Sent: Saturday, June 23, 2007 9:16 AM
To: Filyurin, Yan; Mike Kraus (mikraus)
Cc: ccielab@groupstudy.com
Subject: Re: Help with concept explanation
Hi Yan,
the test that I have done seems to contraddict your explanation of
'shape
peak':
http://groupstudy.com/archives/ccielab/200705/msg01184.html
Saying that the bucket is refilled with BC every TC implies CIR=BC/TC
which
means that your substainable rate is also BC/TC. My lab as well as the
doccd
shows instead that the substainable rate is <shape peak
value>*(1+be/bc).
The extra bonus that you say you get at the first TC will have no
long-term effect on the CIR as it will be depleted very soon if one keep
pushing more than BC.
So I am more tempted to say that the refill rate in case of 'shape peak'
is
(bc+be) per TC.
Having said that, I still dont get why they had invented this 'shape
peak'
command as it doesnt do anything more than 'shape average' can do apart
from
adding a lot of confusion.....
Thanks,
Bit.
----- Original Message -----
From: "Filyurin, Yan" <yan.filyurin@eds.com>
To: "Mike Kraus (mikraus)" <mikraus@cisco.com>
Cc: <ccielab@groupstudy.com>
Sent: Saturday, June 23, 2007 3:03 AM
Subject: RE: Help with concept explanation
> Actually I was never able to find a good document that described and
> Odom's book while excellent did not quiet explain it for me to
> understand it, so I continued asking around. In the end I saw the
> following revelation, after talking to our ANS
>
> I also would like to offer a shameless promotion for Michael Zuo's
notes
> that includes some details on that as well and goes into it.
>
> The revelation was the different between shape average and shape peak.
>
> In case of shape average, one can do the shaping rate, BC and BE.
Often
> people don't do BE and the goal of shape average is not to exceed the
> rate. So in the course of a TC BC packets pass the shaper and move
on.
> If less than BC moves through the shaper, there are tokens left and
> those will get transmitted in the next TC cycle. So token bucket is
BC
> + BE and in the next TC intervals the tokens that were accumulated can
> be used if anything needs it. So that way shape average complies with
> CIR and only allows sending of BC+ bps if it accumulated credit from
the
> previous cycle, or cycles. The token bucket start with just BC. You
> can configure BE, but that is so you can use bandwidth more
efficiently
> and what did not get sent in one interval can be send in the next one.
>
> In case of shape peak the bucket starts out with BC + BE, gets filled
> with BC every time interval and so if you want to transfer at the very
> beginning BC + BE, you can do that, but to keep on doing that, you
have
> to accumulate credits, so in theory when doing shape peak, you
suddenly
> get to send up to peak rate, if enough credits got accumulated. In
> other words, at every interval you can send up to a peak rate if
> bandwidth is available and you have the credits and you already start
> out with them in the token bucket. That is very similar to how frame
> relay traffic shaping works. So if you are specifying BE and BC under
> that map-class you are kind of saying that this PVC can burst up to
that
> peak rate. So the same formula of rate = CIR * (1 + be/bc) will apply
> to frame relay traffic shaping.
>
> Generic traffic shaping as I understand it is very similar to shape
> average. Same goes for specifying traffic-rate is frame relay map
> class. This part I am still researching.
>
>
>
> -----Original Message-----
> From: Mike Kraus (mikraus) [mailto:mikraus@cisco.com]
> Sent: Wednesday, June 20, 2007 11:38 PM
> To: Filyurin, Yan
> Subject: RE: Help with concept explanation
>
> Yan, what document helped the light bulb come on for you? I need to
> read up on this myself as well.
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Filyurin, Yan
> Sent: Wednesday, June 20, 2007 10:27 PM
> To: ccielab@groupstudy.com
> Subject: RE: Help with concept explanation
>
> Never mind, I figured it out, after reading up some more on it, but I
> must say shape average vs. shape peak is the biggest QOS mystery!
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Filyurin, Yan
> Sent: Wednesday, June 20, 2007 4:19 PM
> To: ccielab@groupstudy.com
> Subject: Help with concept explanation
>
> I know this comes in the discussions every month, but I think there is
a
> difference in how Cisco Documentation describes it vs. how some
authors
> describe it.
>
> After reading a few examples in the practice labs, I saw that if I
were
> given a frame relay traffic shaping requirement that would be
something
> like this.
>
> A circuit has access rate of 1024kbps and PVC provisioned at 512kbps
and
> configure the connection to not go above the CIR, but if enough
credits
> have been accumulated be able to burst up to the port speed.
>
> Frame Relay traffic shaping is pretty straightforward, assuming TC of
> 1/8 of a second.
>
> Frame-relay map-class shape
> frame-relay cir 512000
> frame-relay bc 64000
> frame-relay be 64000
>
>
> There could be numerous alternative solutions either using frame-relay
> traffic, rate, generic traffic shaping or class based shaping. And
the
> one thing, I am not clear on is why in case of Class Based traffic
> shaping the configuration involves shape peak.
>
> Class class-default
> shape peak 512000 64000 64000
>
>
> If I understand how shape peak works, the token bucket will
effectively
> be BC + BE, which would be in case on frame-relay traffic shaping, but
> in case of shape peak BC + BE will go into bucket every time interval
> and won't it be different from frame relay shaping configuration
>
> Would shape average be more appropriate.
>
> I know everyone is sick of this discussion, as it keeps constantly
> appearing and I thought I understood this well, but this seems to go
> against it.
>
> Also Cisco documents it differently that Wendell Odom's book.
>
> Yan
>
>
This archive was generated by hypermail 2.1.4 : Sun Jul 01 2007 - 17:24:51 ART