FR traffic shaping question on "mincir" parameter

[rogelioalvez]

Hello everybody:

Let's suppose my router's FR interface has a certain physical rate and that frame-relay traffic-shaping is configured on it.

(Actually, the connection between the routers is a point to point one, without FR switches between them).

Below this physical interface I defined a point-to-point subinterface and attached a "frame-relay class" with the "mincir" parameter configured to a certain rate below the CIR.

Now let's suppose that a burst of output traffic starts to congest my output queue, but "frame-relay adaptive-shaping becn" was not configured.

¿Will the router start to activate traffic shaping and drop close to the mincir as a result of this event?

In other words, I want to know if BECN is the only flow management procedure that will force the router to drop the output rate close to the mincir configured by the operator, or if output congestion is enough to signal the traffic shaping routines to start working.

Any help will be greatly appreciated.

Rogelio Alvez

[Giuseppe Larosa]

Hello Rogelio,

very good question.

the answer is no.

Howevere, a feature called adaptive shaping for interface congestion has been introduced to address this issue.

see

http://www.cisco.com/en/US/partner/docs/ios/wan/configuration/guide/wan_afrt_shp_ic_ps6350_TSD_Products_Configuration_Guide_Chapter.html

or

http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_afrt_shp_ic_ps6350_TSD_Products_Configuration_Guide_Chapter.html

see if the following is supported in your IOS:

Router(config-map-class)# frame-relay adaptive-shaping interface-congestion [queue-depth]

Hope to help

Giuseppe

[rogelioalvez]

Hello Giuseppe:

I connected the "lefthand side router's LAN" to Internet and a PC to the LAN of the "righthand side router".

Then I asked an Internet browser on the PC to download a file from the Internet.

The "lefthand side router" is configured with the following parameters in its class:

cir 128000

mincir 128000

When I ask the PC to download a file from the Internet, the browser shows me that it tries to reach the speed of the physical connection between the routers, but this download rate starts to drop very fast until it reaches 128 kbps.

If I increase the "cir" parameter to 256000 on the left side and start the test again, the PC drops down to 256kbps.

If I eliminate the "traffic-shaping" command, the PC gets its best result, reaching 3mbps (the rate of the physical connection between the routers). Actually, I am supposing this, since each TCP session gets 800kbps (TCP window of 64000 bytes divided the 640ms of RTT delay - satellite connection).

So "traffic shaping" in some way forces the router to start flowing traffic paced at the speed of the "cir" parameter.

So I am a little bit confused. Actually, this is not my configuration, but the customer's one, and I am trying to figure out why I see this behavior and how to improve the results. One of the options I am thinking of is to pace the traffic that comes from the Internet at some value below 3mbps, or perhaps to eliminate FR TS and start using plain LLQ/CBWFQ on the interface.

Any opinions are really appreciated.

Regars, Rogelio

[Giuseppe Larosa]

Hello Rogelio,

you are right and I've rated your post.

the missing becn just removes the capability to react to received becn but FRTS is in action in any case shaping at CIR.

Receiving becn on FR router makes the device to shape at a reduced rate.

Rate is reduced 25% each time a becn is received.

FRTS without becn shapes at CIR that's all.

the feature I've found is an improvement for interfaces with multiple DLCIs where it tries to shape more if aggregate traffic reaches interface congestion even if each single DLCI is belows its own CIR. it is for oversubscribed hub routers serial interfaces.

You can actually combine FRTS and CBWFQ if desired.

This configuration is equivalent to hierarchical QoS on other interface types.

Is the customer complaining of reduced performance ?

Shaping at a rate just below the real CIR of the frame-relay PVC should be correct.

Being frame-relay you need to know the CIR applied by service provider on the PVC the physical link speed is a different matter.

link speed > CIR in your case.

shaping at a rate greater then real rate causes queueing on the wan.

Hope to help

Giuseppe

[rogelioalvez]

This network is kind of special. It actually has been implemented as an ethernet hub in which one router transmits at 3mbps and many destinations (behind a satellite) receive at 3mbps each.

So each destination router receives everything but discards traffic not targeted to it by checkind the DLCI of packets.

So the provider wanted to guarantee each destination with a huge bursting capability if the other destinations are idle and a CIR when congestion appears, but the implementation does not seem to match the idea, since it is enough to have only one destination active, and as soon as it starts downloading Internet traffic, the lefthand side router soon reaches 3mbps on the transmision side, congestion occurs, and the destination is "punished" with 128kbps (CIR configured on the transmiting side).

That's why I am thinking about changing to LLQ and bandwidth percentage allocation.

Regards, Rogelio