From: Joseph Saad (joseph.s.saad@gmail.com)
Date: Sat Jun 23 2007 - 09:28:13 ART
It is just more risky, anything above Bc, will be marked with DE. And more
likely to be dropped if the FR network is congested. But if not, it is
advantageous to the ISP's client. I don't recall the source of this though.
-----Original Message-----
From: Filyurin, Yan [mailto:yan.filyurin@eds.com]
Sent: Saturday, June 23, 2007 4:18 PM
To: Joseph Saad; Bit Gossip; Mike Kraus (mikraus)
Cc: ccielab@groupstudy.com
Subject: RE: Help with concept explanation
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