QoS with dynamic bandwidth

justanas1 · ‎03-02-2008

Dear all,

i have a Cisco 6509 switch connected to other Cisco 6509 switch using SDH network, i have some problems that effect voice traffic over, and important TCP trafficover this SDH link.

i want to implemet QoS to the outbound traffic of each switch, but the problem is that the WAN bandwidth is not fixed because there is video traffic in this SDH network , so the available bandwidth is dynamicly changed.

so i want to know if there is a method i can use to determine the availbe bandwidth, hense i can use queuing methods.

Thanks

Joseph W. Doherty · ‎03-02-2008

Are you saying you don't have control over the device feeding traffic to the SDH link, such as 6509 you plan to use QoS is further upstream? Or in your posting, you have control over the first 6509 that sends traffic to a second 6509 which you don't control and which has the SDH link?

If that's the case, normally the first device would tag traffic and the second will honor the tags. Unaware of any dynamic feedback available within Cisco 6500s that would easily assist you. I.e. the second 6509 informing the first 6509 how much available bandwidth there is.

PS:

What I believe your describing might be implemented if you had something like frame-relay's FECN/BECN with a shaper that dynamically throttles bandwidth. In theory, building on some of Cisco's existing features, if the 2nd 6509 could indicate congestion with ECN, and this was echoed back to your 1st 6509, and if something like GTS would slow based on seeing it, you might have what you looking for. However, although you could now reorder your packets within the available bandwidth, you might not have sufficient actual bandwidth for all your LLQ traffic, or your other critical traffic, and it would still be impacted. Another problem, such a feedback loop would probably be too slow to effectively process something like voice. There's a reason why Cisco recommends WAN cloud technologies that support bursting (which is what you might being trying to emulate) should not (the bursting) be used when dealing with voice.

justanas1 · ‎03-02-2008

Dear josephdoherty

thank you for reply,

In fact the connection is as follow:

1st Site(6509)---SDH(IP)Prisma--STM1--SDH(IP)Prisma---2nd Site(6509)

the first site is connected through STM1 link to other site using IP prisma devices,

the IP Prisma is layer 2 and doesnt support QoS.

the congestion point is the Prisma's

i want to configure QoS in 6509's but the problem is that i cannot know the exact available bandwidth in the STM1 link because there is video streaming traffic in this STM1 link.

i hope you can help me.

Thanks

aravindhs · ‎03-03-2008

Hi,

Firstly, you need to determine the types of traffic that are clogging up the link.

Secondly, find the number of real time video streams actually required. (Interactive/ non-interactive) and depending on that, use may appropriate QoS mechanisms on the link.

If you cannot determine the above required info, it won't be possible to deploy QoS correctly.

Cheers

arav

Joseph W. Doherty · ‎03-03-2008

What type of connection is used between the 6509 and the Prisma?

Does the 6509 see all the traffic before it gets to the Prisma device, or does the Prisma device directly inject the video traffic?

If the latter, how variable is bandwidth usage of the video traffic?

[edit]

Also, does the far side 6500 see egress video traffic, or is the problem the video traffic is strictly between the two Prisma devices?

If true, the two Prisma device can not be moved to be behind the 6500s, i.e. they have to be directly connected to the STM1?

[edit2]

If your answers will be that you're stuck with the current config, and the video traffic is strictly between the two Prisma devices, i.e. you're trying to somehow dynamically detect available bandwidth not being used by the video stream; I don't believe you'll find anything on the 6500s that will assist you. Some 3rd party traffic shaping appliances, might be able to help by measuring end-to-end flow performance. Otherwise, you're best bet might be to shape your traffic to whatever bandwidth is not normally used by the video stream. Yes, certainly not ideal, and you lose bandwidth when the video stream isn't running, but when dealing with voice and critical applications where consistent performance is the number one goal, it works. (NB: Not as familiar with 6500 QoS features w/o special WAN cards. I know LAN interfaces are much more limited. For instance, a hierarchal shaper might not be supported on a LAN interface. Possible option, and if possible, set LAN interface to 100 Mbps if now gig.)

justanas1 · ‎03-03-2008

Dear Josephoherty,

the type of connection between the 6509 and the prisma is copper giga interface and there is WAN acceleration device

between the 6509 and the prisma.

The Prisma directly inject video streams to the SDH ring using ASI interfaces.

The video traffic is between the prisma devices and the Cisco not detect it.

what 3rd part traffic shaping you recommend to use?

Thanks alot

Joseph W. Doherty · ‎03-03-2008

For a 3rd party device, I have something in mind like a Packeteer or Exinda type product (unaware of similar product from Cisco). I'm not positive that any one such device would work, but if it monitored individual flow performance, and adjusted flow rates, it might address the problem. Perhaps even your existing WAN acceleration device might have this capability.

On the subject of your WAN acceleration device, this too can be a problem area unless it either manages priorities or marks so a downstream device can manage them. Upstream devices (such as 3rd party traffic shaper) may receive an inaccurate analysis what's actually going across the WAN link.

What you really need is a device at the SDH interface that sees all actual WAN traffic and understands its relative importance. Assuming outbound traffic is correctly marked, or can be classified, you should place a router between the Prisma and the SDH. This could be a standalone router, or you might bounce such a link back off the 6500 (i.e. 6500 to WAAS to Prisma to same 6500 to SDH). If you do the latter, insure the interface supports the necessary QoS processing.

justanas1 · ‎03-03-2008

Thank you very much for your concerns,

In fact the Prisma is designed to work with SDH network, and the interfaces attached to it are ASI interfaces, the video traffic is video stream and not IP traffic, so i can not place the cisco direct to the SDH network.

i think we must upgrade the Prisma to be Layer 3, so it can cabable to do QoS, or check the WAN accelerator to know if it can do bandwidth detection.

Thanks

Mohamed Sobair · ‎03-03-2008

Hi,

Adding to Joseph's, Both Frame-relay media and other than fram-relay, could support

ECN, fram-relay did it by sending (becn) for normally acknowledge flows to the sender

, and (fecn) reflected as becn for un acknowledge ones. As for your Qos, u can reserve bandwidth and configure WRED to send ECN.

Pls consider the following on your Wan QoS:

1- You should classify and mark your voip as the ingress.

2- ensure that not above 33% of the Wan is reserved for Voip using LLQ. (Cisco Recommendation)

3- consider RTP heder compression.(you should watch for the cpu though as its most QoS cpu intense)

4- at least 25% should be left which is the default for (best effort) as Cisco recommends.

Notes:

a) VOIP shoul be always using LLQ independantly.

b) As for the rest of the traffic, The best rcommended method is marking based on

DSCP, and apply WRED.

c) As you know (WRED) is designed to drop packet randomely before Queue gets full, this

is most necessary for TCP flow. Dont apply WRED when Calssifying VOICE.

D) You could send ECN (Explicit Congestion Notification) using WRED as well by marking

the last bits in DSCP field, instead of Dropping packet based on their marking Value,

make sure that devices are ECN compatiable in order to send ECN when

congestion experienced, the peer device should respond ECN by sending ECN echo back

to the sender in response to the ECN. However, the config for ECN is slightly different

here are examples for Note c, d respectively using WRED.

class-map match-all http

match protocol http

set dscp af21

policy-map http

class http

bandwidth 10

random-detect dscp-based

class class-default

fair-queue

random-detect ecn

The above would be applied outpound the interface towards the WAN link.

This would apply WRED By randomly dropping packet based on their dscp values, while

sending ECN to the router, when congestion experienced for rest of any inclassified

packet.

HTH

Mohamed

justanas1 · ‎03-03-2008

Dear Mohammed,

can i use this frame relay congestion tools (ECN, FECN...) in my cenario or it restricted to frame relay media?

Thanks

the peoblem as i mentioned before is that the connection between the 6509 and the prism is giga interface, and the congestion point is the prisma, and the prisma doesnt support qos.

so if i forced the qos policy in the outbound direction, it will not be efficint.

Thanks

paolo bevilacqua · ‎03-03-2008

Hi,

seems to me you cannot do anything. Frame-relay does not apply at in this case.

So either you trust that there is enough bandwidth, or reverse the design place the cisco to manage the stm-1 cicuit, and set the prism device as "user" of the router.