RE: Frame-Relay Traffic Shaping "Be" Value

From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Fri Oct 24 2003 - 19:39:15 GMT-3


1) The Be bucket as the Bc bucket has a limit on the amount of credits it
can hold. The Be does not have a limit on the length (amount of Tc's) it can
hold credits for or continue accumulate credits. But no matter how long it
takes to fill the Be bucket it can still only hold a certain amount of
credits.

2) As per the engineer spec on FRTS, if the size of the packet is larger
than the max Bc bucket size, the Bc bucket will still transmit the packet
but the packet will cause the Bc bucket to go into a debt situation. I
normally do not mention this as it just creates confusion as to the fact
that shaping is allowing a debt situation to occur.

3) If the Be bucket is 8000 than the Be can hold only 8000 no matter how
many credits are attempted to be put into it. The Be bucket could be filled
during one Tc (8000 credits in one Tc) or it could be filled in 8000 Tc's (1
credit per Tc).

Don't confuse the amount of credits the Be bucket can hold with the length
of time the Be bucket can hold or accumulate credits for.

Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
Internetwork Expert, Inc.
http://www.InternetworkExpert.com

-----Original Message-----
From: Yasser Aly [mailto:blackyeyes00@hotmail.com]
Sent: Friday, October 24, 2003 1:37 PM
To: bdennis@internetworkexpert.com
Cc: ccielab@groupstudy.com
Subject: RE: Frame-Relay Traffic Shaping "Be" Value

Hi Brian,

  I read the presentation you made - which I find very valuable - before
posting the question.
Unfortunatelly some question popped in my mind that I couldn't find answrs
to from the presentation.
If u can help in providing answers for these question this will be great.

Questions are:

1- In your presentation page "slide 28" you said
" If the Bc bucket has leftover credits when a new interval (Tc) starts,
those credits will cause the Bc bucket to overflow, and these overflows will

be caught by the Be bucket. If the Be bucket is already full the credits
will be lost.

Now I am confused whether Be bucket has a limit or not and what is the
relation of how long Be can hold credits with its max.

2- If Bc= 8000, Be=16000 and a packet needs to be transmitted with size
bigger than either Bc and Be, how this packet will be transmitted ?

3- If Be= 8000, does this mean that Be will be credited only during the
first Tc with these credits and any additions to it will be only due to
overflows from Bc once full or Be will be credited by 8000 every Tc , like
the case of Bc credited by Bc value every Tc.

Thanks a lot for your reply.

Regards,
Yasser
>From: "Brian Dennis" <bdennis@internetworkexpert.com>
>To: "'Yasser Aly'" <blackyeyes00@hotmail.com>
>CC: <ccielab@groupstudy.com>
>Subject: RE: Frame-Relay Traffic Shaping "Be" Value
>Date: Fri, 24 Oct 2003 12:11:22 -0700
>
>The length of time that Be can continue to accumulate credit is different
>than how much credit the Be bucket can hold. You might be getting that part
>confused.
>
>Rather than reading over my e-mails you might try checking out the
>presentation I put together on FRTS to help clear things up.
>
>http://www.internetworkexpert.com/resources/01700368.htm
>
>Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
>bdennis@internetworkexpert.com
>Toll Free: 877-224-8987
>Direct: 775-745-6404 (Outside the US and Canada)
>Internetwork Expert, Inc.
>http://www.InternetworkExpert.com
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Yasser Aly
>Sent: Friday, October 24, 2003 11:25 AM
>To: brian@labforge.com
>Cc: ccielab@groupstudy.com
>Subject: Re: Frame-Relay Traffic Shaping "Be" Value
>
>Hi Brian,
>
> While reading some of the archived posts about FRTS I passed by yours.
>
>You are saying at the end of the post
>" At the start of every Tc Bc amount of credits are added to the Bc bucket.
>If the bucket has credits left over when the next Tc starts those credits
>will cause the Bc bucket to overflow but the overflow credits will be
>caught
>
>by the Be bucket. The Be bucket can only hold Be amount of credits. If the
>Bc and Be buckets are both full the new credits added each Tc will be
>lost."
>
>But at the very begining of your post u said that " There doesn't appear to
>be a limit as to how long Be can continue to build up credits. I've tested
>FRTS scenarios where Be credits built up over 10 minutes (CIR =16000 and Be
>= 12000000)." Doesn't this contradict from the previous statement that Be
>has a limited size, if it was full and extra Bc overflowed they will be
>lost
>
>and not added to Be ?
>
>Would u kindly elaborate this more to remove my confusion.
>
>Best Regards,
>Yasser
>
> >From: "Brian Dennis" <brian@labforge.com>
> >Reply-To: "Brian Dennis" <brian@labforge.com>
> >To: <ccielab@groupstudy.com>
> >Subject: Frame-Relay Traffic Shaping "Be" Value
> >Date: Thu, 24 Apr 2003 17:00:19 -0700
> >
> >After testing FRTS I can say that Be can be larger than the previous
> >"internal interval" (Tc) and even the previous "interval" (full second).
> >There does not appear to be a limit as to how long Be can continue to
> >build up credits (aka tokens). This means that Be can hold credits from
> >a multitude of previous Tc's and even a multitude of full seconds. I've
> >tested FRTS scenarios where Be credits built up over 10 minutes (CIR =
> >16000 and Be = 12000000).
> >
> >For those interested in understanding FRTS let me explain it from the
> >perspective a single "bucket" (i.e. Be = 0) FRST configuration and then
> >from a dual "bucket" (i.e. Be > 0) FRST configuration.
> >
> >Let's start off the single bucket explanation:
> >
> >map-class frame-relay SingleBucket
> > frame-relay cir 16000
> > frame-relay bc 2000
> >
> >When we first apply FRTS to an interface (or DLCI) we will start out
> >with a single bucket full of credits. Every Tc the amount of credits
> >equaling Bc is added to this bucket. When a packet needs to be sent the
> >router will check to see if there are enough credits to send the packet
> >(1 credit equals 1 bit). If there are enough credits, the router will
> >send the packet and removes the amount of credits equaling the size of
> >the packet. If there are not enough credits the packet gets "shaped" and
> >placed in the FRTS hold queue awaiting enough credits to send the
> >packet.
> >
> >Since this is a single bucket configuration we do not store excess
> >credits and theoretically can never send more than Bc amount of bits per
> >Tc. If this bucket has credits left over when the next Tc starts these
> >left over credits will be lost. This is because at the start of every Tc
> >Bc amount of credits are added to this bucket that can only hold Bc
> >amount of credits.
> >
> >In contrast to CAR FRTS will never borrow credits from future Bc's and
> >will theoretically never go into debt. This ensures that with FRTS the
> >router is always guaranteed to have credits to send every Tc. As a side
> >note remember that CAR on the other hand does not really guarantee
> >bandwidth. CAR only limits bandwidth.
> >
> >Now the dual bucket explanation:
> >
> >map-class frame-relay DualBucket
> > frame-relay cir 16000
> > frame-relay bc 2000
> > frame-relay be 62000
> >
> >When we first apply FRTS to an interface (or DLCI) we will start out
> >with two buckets full of credits. Lets call the first bucket the Bc
> >bucket and the second bucket the Be bucket. When a packet needs to be
> >sent the router will check to see if the Bc bucket has enough credits to
> >send the packet. If it does have enough credits the packet is sent and
> >the amount of credits equaling the size of the packet is removed from
> >the Bc bucket. If the Bc bucket does not have enough credits the router
> >will check the Be bucket. The packet will be sent if there are enough
> >credits in the Be bucket and the amount of credits equaling the size of
> >the packet will be removed from the Be bucket. If there aren't enough
> >credits in the Bc or Be buckets the packet is stored in the FRTS hold
> >queue till there are enough credits built up to send the packet.
> >
> >At the start of every Tc Bc amount of credits are added to the Bc
> >bucket. If the bucket has credits left over when the next Tc starts
> >those credits will cause the Bc bucket to overflow but the overflow
> >credits will be caught by the Be bucket. The Be bucket can only hold Be
> >amount of credits. If the Bc and Be buckets are both full the new
> >credits added each Tc will be lost.
> >
> >This is actually my short explanation of FRTS ;-)
> >
> >Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> >Director of CCIE Training and Development - IPexpert, Inc.
> >Mailto: brian@ipexpert.net
> >Toll Free: 866.225.8064
> >Outside U.S. & Canada: 312.321.6924
>
>_________________________________________________________________
>Help STOP SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>



This archive was generated by hypermail 2.1.4 : Mon Nov 24 2003 - 07:53:08 GMT-3