cheap managed switch for QoS?

[ZippyDan]

Imagine the following setup:

1. DSL modem with 5 static IPs-> dumb switch
2. Router that manages network connected to dumb switch
3. VOIP router that manages IP phones connected to dumb switch

The VOIP router is my problem, I use it for international calling.

Actually, my DSL connection is the real problem, but I can't do anything about that right now. Specifically I have issues with my upload speed which is very low. If the network is using a lot of bandwidth, my call connection suffers.

I think that if I replace my dumb switch with a managed switch that can prioritize the VOIP router over my network router (and guarantee it a certain amount of bandwidth if needed), then I might see an improvement. I'd like to specify a minimum upstream bandwidth level for the VOIP router. Of course, I'd want the bandwidth to be freed up if no calls are being made, but I think this is how QoS work anyway.

Since there are only two devices here in question, I need the smallest, cheapest managed QoS switch I can find. Any suggestions?

(I have thought about putting the VOIP router behind the network router and letting the network router do QoS; however, let's just say the VOIP router does behave well when behind another router)

 

[imagoon]

You need QoS at the router level, cheap managed switches will honor DCSP etc but rarely will actually have that much control.

 

[ZippyDan]

So I've heard. But my VOIP router hates being behind another router.

Also, I've determined what I need is actually traffic shaping, not QoS.

There is nothing that does shaping at Layer 2 instead of Layer 3?

 

[drebo]

What model is the DSL router? Is it a Motorola Netopia?

Also, being that you can only QoS in the egress direction, you probably will be unable to resolve this issue at all.

A switch can have priority queues based on DSCP or CoS markings, but that will really only matter in cases of congestion on the switch, which you're not going to have in this instance. Your point of congestion is the DSL router. That is where your QoS needs to happen.

You can priority queue on that in the outbound direction only. Your provider would then also need to priority queue your VoIP traffic in their outbound direction (inbound to you).

No other way to effectively do it.

 

[ZippyDan]

the modem is a Zyxel P-660

I don't understand why the ISP is involved or I can only affect one direction. My issue is with the network router competing for bandwidth with the VOIP router. Right now, both those routers are at the edge (connected to the modem). If, theoretically, there was another device at the edge before BOTH devices, I don't see why it couldn't shape traffic in both directions for both devices.

My problem is that the VOIP router likes to be at the edge.

 

[Emulex]

you should be able to trafffic shape both streams if its that easy to separate them - but cheap as in a small pc running *bsd? or cheaper?

 

[ZippyDan]

the network router i have now running Linux could do it

the problem, again, is that the VOIP router doesn't like to be behind another router

 

[imagoon]

the modem is a Zyxel P-660

I don't understand why the ISP is involved or I can only affect one direction. My issue is with the network router competing for bandwidth with the VOIP router. Right now, both those routers are at the edge (connected to the modem). If, theoretically, there was another device at the edge before BOTH devices, I don't see why it couldn't shape traffic in both directions for both devices.

My problem is that the VOIP router likes to be at the edge.

You can do this with Juniper firewalls using transparent QoS etc but that will be a bit above the range your looking at. A Linux PC should be able to do transparent / MIP type control also.

 

[drebo]

Traffic shaping is not the same thing as QoS. Also, you cannot traffic shape ingress traffic that is not TCP.

Why? Because you have no control over how fast the sending server sends its packets to you, and you do not control the side of the link at which non-conforming packets should be dropped.

QoS involves identifying packets via some parameter (DSCP marking, source/destination address/port, CoS marking, etc) and placing that packet into a priority queue on the egress interface. In order to prioritize traffic, the packet needs to already have reached the device. Because your ingress bandwidth on the WAN interface of your modem/router is so much slower than the egress bandwidth on your LAN interface of your modem/router, priority queuing is not needed, as there will never be congestion in that direction.

Consider why a VoIP call quality issue manifests as stuttering. That's caused by dropped packets at the point of congestion. RTP streams are UDP, meaning that missing packets are not retransmitted. When you attempt to send data on a 1Mbps connection, your sending device doesn't know that it's a 1Mbps connection. It's connected to a 100 Mbit switch. At the point where the 100 Mbit network bridges to the 1 Mbps network, you will have queuing. Priority queuing (QoS) will allow you to identify packets for sending before other packets. But doing that in the other direction does not make sense, since you will never have queuing or dropped packets going from a 1 Mbps network to a 100 Mbps network.

Traffic shaping is different, but for UDP connections it still only applies in the egress direction. For TCP connections, it can work in the ingress direction. This is because TCP has a built-in mechanism for resending dropped packets and reducing the speed at which packets are sent at the server based on the number of retransmits. UDP does not have such a mechanism and will send packets exactly as fast as the serving system is configured to send. That means that if the packetization rate of your SIP provider is 20ms, it will send a packet every 20ms regardless of how many are dropped due to congestion. If you do not have control over the point of congestion in the direction of data flow, you cannot determine which packets get dropped and which get sent.

Traffic shaping can be employed to limit TCP ingress traffic by telling the router to drop certain traffic after a certain bit rate has been reached. However, even if you shape the traffic to a rate half of your downstream CIR, you will still have some period of congestion while the TCP protocol throttles itself down to a sustainable rate with no dropped packets.

In conclusion, you cannot QoS both directions of a link when you only control one side of that link. This is one of the issues with VoIP. You can kind of/sort of work around and attempt to aliviate some of the packet loss problems, but you will never completely succeed without controling both sides of the link at which congestion occurs. This is also why you cannot perform QoS on a device between your VoIP gateway and your data router and expect it to do have any effect at all.

 

[Emulex]

dd-wrt asks your upstream kbps so it can reserve it to 80-95% upstream and throttle (lag/buffer) inbound per downstream but it needs to be fixed like dsl not so much like cable with powerboost

 

[bobdole369]

Traffic shaping is not the same thing as QoS. Also, you cannot traffic shape ingress traffic that is not TCP.

Why? Because you have no control over how fast the sending server sends its packets to you, and you do not control the side of the link at which non-conforming packets should be dropped.

QoS involves identifying packets via some parameter (DSCP marking, source/destination address/port, CoS marking, etc) and placing that packet into a priority queue on the egress interface. In order to prioritize traffic, the packet needs to already have reached the device. Because your ingress bandwidth on the WAN interface of your modem/router is so much slower than the egress bandwidth on your LAN interface of your modem/router, priority queuing is not needed, as there will never be congestion in that direction.

Consider why a VoIP call quality issue manifests as stuttering. That's caused by dropped packets at the point of congestion. RTP streams are UDP, meaning that missing packets are not retransmitted. When you attempt to send data on a 1Mbps connection, your sending device doesn't know that it's a 1Mbps connection. It's connected to a 100 Mbit switch. At the point where the 100 Mbit network bridges to the 1 Mbps network, you will have queuing. Priority queuing (QoS) will allow you to identify packets for sending before other packets. But doing that in the other direction does not make sense, since you will never have queuing or dropped packets going from a 1 Mbps network to a 100 Mbps network.

Traffic shaping is different, but for UDP connections it still only applies in the egress direction. For TCP connections, it can work in the ingress direction. This is because TCP has a built-in mechanism for resending dropped packets and reducing the speed at which packets are sent at the server based on the number of retransmits. UDP does not have such a mechanism and will send packets exactly as fast as the serving system is configured to send. That means that if the packetization rate of your SIP provider is 20ms, it will send a packet every 20ms regardless of how many are dropped due to congestion. If you do not have control over the point of congestion in the direction of data flow, you cannot determine which packets get dropped and which get sent.

Traffic shaping can be employed to limit TCP ingress traffic by telling the router to drop certain traffic after a certain bit rate has been reached. However, even if you shape the traffic to a rate half of your downstream CIR, you will still have some period of congestion while the TCP protocol throttles itself down to a sustainable rate with no dropped packets.

In conclusion, you cannot QoS both directions of a link when you only control one side of that link. This is one of the issues with VoIP. You can kind of/sort of work around and attempt to aliviate some of the packet loss problems, but you will never completely succeed without controling both sides of the link at which congestion occurs. This is also why you cannot perform QoS on a device between your VoIP gateway and your data router and expect it to do have any effect at all.

Seconded.

Also your switch doesn't need anything - your router is the only thing you need to worry about. You are NOT saturating a 100mbit link. Besides I bet that modems LAN port is only 10mbit. If you can get that zyxel into bridge mode - you could use something like dd-wrt or an 800 series cisco to do at minimum the priority queuing. But as drebo points out candidly - there is no point. Unless you are already saturating the outbound side, and I doubt that you are.

Get a better connection.

 

[Emulex]

no kidding i'm seeing 70-100megabit down and 10-12 up with comcast business for $199 a month ($10 for 5 usable statics plus one dynamic).

no cap mauahhaha