QOS on gigabit connections

Unanswered Question
Apr 22nd, 2008

Just wanted to get opinions, if its advisable to apply QOS on routed gigabit interfaces on 3560s? We've got a couple of WAN locations (using free space optics) hooked up thru our gigabit SFP ports, and while I haven't seen any QOS issues yet; there's been questions as to if its necessary to apply QOS to those interfaces? Our Max traffic has, so far, been around 60 to 100mb/s but the connections are capable of going up to a 1gb full duplex

Second question, not quite related, is there a point where applying QOS doesn't make sense?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (3 ratings)
Loading.
Brandon Buffin Wed, 04/23/2008 - 11:11

I would recommend applying QoS to these links even though you have more than enough bandwidth. This is especially true if you will have real time traffic such as voice/video traversing the link. In your scenario, the gigabit link can basically be treated as a LAN and QoS applied accordingly. Take a look at the "Campus QoS Design" section of the QoS SRND below. In my opinion, the only point at which QoS doesn't make sense is if you are only dealing with best effort traffic.

http://www.cisco.com/univercd/cc/td/doc/solution/esm/qossrnd.pdf

Hope this helps. If so, please rate the post.

Brandon

ricky-li Thu, 04/24/2008 - 17:07

After reading that, I think I'll try out auto-qos voip trust. I'll let you know if it works on a switch port that has the "no switchport" option enabled on it.

Joseph W. Doherty Thu, 04/24/2008 - 16:47

When to use QoS? When there would be benefit to manage congestion by treating different traffic differently.

ricky-li Thu, 04/24/2008 - 17:15

I realize that, what I'm asking for is there a certain point where the speed of the link negates the need for QOS? Where traffic on the interface goes thru so quickly, that you'll be making things worse by adding QOS.

For example, once your house is flooded, it doesn't matter how much water came in. Your house is still flooded.

Joseph W. Doherty Thu, 04/24/2008 - 18:57

My prior answer may seem obvious, since you "realize that", but perhaps you don't fully see all the significance within what I wrote when you ask whether the speed of the link negates QoS.

". . . what I'm asking for is there a certain point where the speed of the link negates the need for QOS?"

If by QOS, you have in mind the application of something beyond the often normal FIFO tail drop queue for an interface, and for fixed amounts of traffic bandwidth, such that the aggregate utilization is always less than the link's maximum bandwidth, the answer is yes.

e.g.

Any combination of 80 Kbps CBR VoIP flows and FTP flows sourced from 100 Mbps connected hosts, all across a 1 Gbps link where the aggregate bandwidth doesn't exceed 1 Gbps, shouldn't need QoS.

If the aggregate bandwidth can exceed the transit link's bandwidth, you'll need to analyze the situation.

e.g.

One 80 Kbps CBR VoIP flow and one FTP flow sourced from 1 Gbps connected host, both across a 1 Gbps link, where the aggregate bandwidth exceeds 1 Gbps, would need analysis.

Can you make things worse by adding QoS? Yes.

ricky-li Tue, 04/29/2008 - 10:58

Thanks, thats what I was looking for. I thought that there would be a point where this would occur, but until reading your post I couldn't figure out how to explain it to the rest of my team.

Joseph W. Doherty Tue, 04/29/2008 - 11:22

What might also help, and perhaps where bandwidth does come into play, is the actual instantaneous delay when there's congestion.

Nine 1500 byte FTP packets in a queue, followed by a single VoIP packet, will make for more serialization delay on a T1 vs. 100 Mbps Ethernet (you can calculate the delay for both).

The extra delay on the 100 Mbps link might be within the acceptable bounds for the VoIP packet, but unacceptable for the T1. This is the kind of analysis needed when there's any congestion. The congestion can be transient, such that the link is only has 20% utilization, yet the issue is still the VoIP packet behind other packets during traffic bursts.

Actions

This Discussion