From: Yasser Aly (blackyeyes00@hotmail.com)
Date: Sat Oct 25 2003 - 16:57:45 GMT-3
Thanks Brian for the clarification
Cheers,
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 15:39:15 -0700
>
>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
> >
> >
>
>_________________________________________________________________
>Protect your PC - get McAfee.com VirusScan Online
>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
>
This archive was generated by hypermail 2.1.4 : Mon Nov 24 2003 - 07:53:08 GMT-3