From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Tue May 25 2004 - 22:19:13 GMT-3
Emil,
It's documented that way because data traffic in general is not
delay sensitive like voice traffic is. Changing the Bc doesn't change
your average output rate. It just changes the average output rate per
interval, which determines the delay within that second.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Fernando, Emil
> Sent: Tuesday, May 25, 2004 8:11 PM
> To: 'Brian McGahan'
> Cc: 'ccielab@groupstudy.com'
> Subject: RE: Frame-Relay and QoS Questions
>
> Brian,
>
> I really appreciate your comments on this issue. It had cleared many
> puzzles
> I had for long time.
> We are having cisco commands for packet fragmentation for long time
but I
> could not find any docs cisco recommending these commands for traffic
> shaping for general data traffic except the Voice traffic.
>
> Thank you again for your valuable input
>
> Emil
>
>
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Wednesday, 26 May 2004 10:48 AM
> To: Fernando, Emil
> Cc: ccielab@groupstudy.com
> Subject: RE: Frame-Relay and QoS Questions
>
>
> Emil,
>
> > What I am trying to say is that the packet will not flow
continuously
> out
> > of the interface if size of the packet is larger than Bc.
>
> Logically yes that would be true if you adhered to the
> algorithm. However, what happens if fragmentation is not enabled, and
> the packet size is larger that the Bc? When Cisco first implemented
> FRTS they forgot to address this issue, and packets would get hung in
> the output queue. In order to resolve it they simply adjusted the
> algorithm to allow you to send more than Bc per Tc (even without Be)
if
> the packet waiting to get dequeued was larger than Bc.
>
> The CAR algorithm also takes this into account as you can see
> from the below output:
>
> R1(config)#int e0/0
> R1(config-if)#rate-limit output 10000 1000 2000 conform transmit
exceed
> drop
> Illegal normal burst size
> Increasing normal burst size to mtu size 1500
>
> Why does the router give you this error? The reason is that if
> you Bc is less than MTU, you can end up in the situation where a
packet
> cannot conform EVER simply because it is too large.
>
> For the above reason this is why frame-relay fragmentation is
> available. By forcing the router to fragment packets that are larger
> than Bc, you are ensuring that it will take no longer than one Tc to
> dequeued a single packet to the transmit ring.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: Fernando, Emil [mailto:emil.fernando@atosorigin.com]
> > Sent: Tuesday, May 25, 2004 7:24 PM
> > To: Brian McGahan
> > Cc: 'ccielab@groupstudy.com'
> > Subject: RE: Frame-Relay and QoS Questions
> >
> >
> > Brian,
> >
> > Thanks for your reply. I now have more doubts to clear. Even if the
> > algorithm borrows more credit for bigger packets, the traffic
shaping
> > still
> > need to adhere to the algorithm by pausing the amount of bytes
allowed
> in
> > one Tc ( be=0). In a situation where router has a bigger AR the
packet
> has
> > to be delayed until the next Tc is available which could fragment
the
> > packet. is it correct ?
> > What I am trying to say is that the packet will not flow
continuously
> out
> > of
> > the interface if size of the packet is larger than Bc.
> >
> > I appreciate you comments.
> >
> > Thanks
> >
> > Emil
> >
> > -----Original Message-----
> > From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> > Sent: Wednesday, 26 May 2004 9:59 AM
> > To: Fernando, Emil
> > Subject: RE: Frame-Relay and QoS Questions
> >
> >
> > Emil,
> >
> > The shaping algorithm borrows credit from the next interval.
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> >
> >
> > > -----Original Message-----
> > > From: Fernando, Emil [mailto:emil.fernando@atosorigin.com]
> > > Sent: Tuesday, May 25, 2004 6:59 PM
> > > To: Brian McGahan
> > > Cc: ccielab@groupstudy.com
> > > Subject: RE: Frame-Relay and QoS Questions
> > >
> > >
> > > Brian,
> > >
> > > I appreciate if you can clear it for us as to how the router
handles
> a
> > > packet of more than 640byte ( in this case) when frame
fragmentation
> > is
> > > not
> > > enable. My understanding is that in this case it should not get
> > through.
> > > Pls. explain how this packet takes more than one Tc as the token
> > bucket
> > > does
> > > not accumulate tokens in bc bucket.
> > > Does the router in this case fragment the packet or use be bucket
?
> > what
> > > happen if the be=0 ?
> > >
> > > Thank you
> > >
> > > Emil
> > >
> > > -----Original Message-----
> > > From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> > > Sent: Saturday, 22 May 2004 9:28 AM
> > > To: Mujica, Raul - (Per); Osterberg, Todd (EM, ITS);
> > > ccielab@groupstudy.com
> > > Subject: RE: Frame-Relay and QoS Questions
> > >
> > >
> > > I'm not sure what you mean by fragment delay, but in simpler
> > > terms the fragment size is just the Bc expressed in bytes (Bc/8).
> You
> > > can configure it to be larger or smaller, but by setting it to be
> Bc/8
> > > you are ensuring that a fragment takes no longer than 1 Tc to
send.
> > >
> > > HTH,
> > >
> > > Brian McGahan, CCIE #8593
> > > bmcgahan@internetworkexpert.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.InternetworkExpert.com
> > > Toll Free: 877-224-8987 x 705
> > > Outside US: 775-826-4344 x 705
> > >
> > >
> > > > -----Original Message-----
> > > > From: Mujica, Raul - (Per) [mailto:raul.mujica@telmex.com]
> > > > Sent: Friday, May 21, 2004 6:18 PM
> > > > To: Brian McGahan; Osterberg, Todd (EM, ITS);
> ccielab@groupstudy.com
> > > > Subject: RE: Frame-Relay and QoS Questions
> > > >
> > > > Brian,
> > > > I want to confirm if you use the formula "FS = BW * fragment
delay
> /
> > > 8" to
> > > > define fragment.
> > > >
> > > > FS = [512000 * (1/100)] / 8 = 640 bytes.
> > > >
> > > > Thank
> > > > Raul
> > > >
> > > >
> > > > -----Mensaje original-----
> > > > De: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> > > > Enviado el: Viernes, 21 de Mayo de 2004 04:53 p.m.
> > > > Para: Osterberg, Todd (EM, ITS); ccielab@groupstudy.com
> > > > Asunto: RE: Frame-Relay and QoS Questions
> > > >
> > > > Hi Todd,
> > > >
> > > > Your Bc value for the class is WAY to high. The size of
Bc
> > > > determines the worst case delay for a packet as it waits to move
> > from
> > > > the output queue to the transmit ring. The larger the Bc the
more
> > > > possibility to have an unacceptable delay. You should use the
> > > following
> > > > calculation:
> > > >
> > > > Bc = CIR/100
> > > >
> > > > This results in the Tc interval of 10ms, which is the
minimum
> > > > configurable. You should also considering enabling
fragmentation,
> > as
> > > > with a CIR of 512000 and a Bc of 5120 the maximum packet size
you
> > can
> > > > send in a single interval is 640 bytes. You should set the
> fragment
> > > > size to 640 bytes to ensure that a single packet does not need
> more
> > > than
> > > > one Tc to be transmitted. Your class should therefore read
> > something
> > > as
> > > > follows:
> > > >
> > > > map-class frame-relay 256k-frts
> > > > service-policy output QoS-Policy
> > > > frame-relay mincir 256000
> > > > frame-relay cir 512000
> > > > frame-relay bc 5120
> > > > frame-relay fragment 640
> > > >
> > > > If you are going to configure Be on the circuit you
should
> > > > determine at what rate the provider is policing you at. If your
> > > > applications can endure possible packet loss in favor of
bandwidth
> > you
> > > > may consider setting the Be to be the (AR - 512000)/100. This
> will
> > > > allow you to burst up to the AR if you have enough credit.
> > > >
> > > > Next, inside your service policy you are matching af41
and
> then
> > > > setting it to af41. Do you mean to do this for traffic that is
> > > matched
> > > > by the access-list but not already set to af41?
> > > >
> > > > For further reference see the following paper on FRTS:
> > > >
> > > > http://www.internetworkexpert.com/resources/01700368.htm
> > > >
> > > > HTH,
> > > >
> > > > Brian McGahan, CCIE #8593
> > > > bmcgahan@internetworkexpert.com
> > > >
> > > > Internetwork Expert, Inc.
> > > > http://www.InternetworkExpert.com
> > > > Toll Free: 877-224-8987 x 705
> > > > Outside US: 775-826-4344 x 705
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > Behalf
> > > > Of
> > > > > Osterberg, Todd (EM, ITS)
> > > > > Sent: Friday, May 21, 2004 4:39 PM
> > > > > To: ccielab@groupstudy.com
> > > > > Subject: Frame-Relay and QoS Questions
> > > > >
> > > > > I have some questions for the group...
> > > > >
> > > > > Remote site has a single frame-relay t1 with 2 pvcs. Primary
> PVC
> > > has
> > > > a
> > > > > CIR of 256K but can burst to full AR. The backup PVC is 4K
but
> > can
> > > > > burst to full AR. With the contact we have with the Telco,
out
> > > > packets
> > > > > never get marked DE, we are not charged more if we send
traffic
> at
> > > > > double the CIR. We will be running video conferencing and
> > multicast
> > > > > audio (16K) and multicast video (56K) sessions across the WAN.
> > Here
> > > > is
> > > > > the sample config for a remote site with a 256K CIR (see
below).
> > So
> > > > > here are my questions:
> > > > >
> > > > > 1. What are the thoughts/comments on the CIR/MINCIR/Be/Bc
> > values.
> > > > > 2. What would you tweak these values to be if the CIR was
> > 512K?
> > > > > 3. Is there any interaction between the interface bandwidth
> > > command
> > > > > and the FRTS map-class values?
> > > > >
> > > > > The configuration at the head end will be similar except that
it
> > > will
> > > > be
> > > > > ATM plus we will be providing a class-map for multicast
traffic.
> > > > >
> > > > > Any other thoughts or comments would be appreciated.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Todd Allen Osterberg
> > > > > GE IT Solutions
> > > > > Cisco Content Networking Specialist
> > > > >
> > > > > class-map match-any video-conference
> > > > > match access-group 102
> > > > > match ip dscp af41
> > > > >
> > > > >
> > > > > policy-map QoS-Policy
> > > > > class video-conference
> > > > > priority 450 30000
> > > > > set ip dscp af41
> > > > > class class-default
> > > > > fair-queue
> > > > > random-detect dscp-based
> > > > >
> > > > >
> > > > > access-list 102 permit ip host x.x.x.x any << ip address of
the
> > > h.323
> > > > > end point >>
> > > > >
> > > > >
> > > > > interface serial0/0
> > > > > encapsulation frame-relay
> > > > > no ip address
> > > > > desc physical interface <<<circuit id>>> etc
> > > > > frame-relay traffic-shaping
> > > > >
> > > > > interface serial0/0.16
> > > > > desc primary PVC CIR=256k, burst to 1500K
> > > > > frame-relay interface-dlci 16
> > > > > class 256k-frts
> > > > > ip address 10.1.1.1 255.255.255.0
> > > > > bandwidth 256
> > > > >
> > > > > interface serial0/0.26
> > > > > desc backup pvc CIR=4K, burst to 1500K
> > > > > frame-relay interface dlci 26
> > > > > class 256k-frts
> > > > > ip address 10.2.2.1 255.255.255.0
> > > > > bandwidth 4
> > > > >
> > > > > map-class frame-relay 256k-frts
> > > > > service-policy output QoS-Policy
> > > > > frame-relay mincir 256000
> > > > > frame-relay cir 512000
> > > > > frame-relay bc 1000000
> > > > > frame-relay be 30000
> > > > >
> > > > >
> > > > > router eigrp 42
> > > > > network 10.0.0.0
> > > > >
> > > > >
> > > >
> > >
> >
>
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:17 GMT-3