Voip network design

[Js007]

I am looking for some input from all of you experienced network designers.

Does a device exist that would throttle or block all network traffic based on a different devices condition?

Ex... Small home network with low isp bandwidth available. ( 760kbps up). Voip works fine with no other network traffic happening. Router Qos has limitations and doesn't do anything for incoming traffic. Is there a scenario possible that could be set up where upon Voip traffic happening (call being established), all other network traffic would be throttled to zero or blocked until the voip condition changed?

I know about Qos- will not control incoming traffic. So if streaming or loading has started, Qos is useless.

I could set up bandwidth throttling with router, but to be effective all non voip traffic would need to be low all the time even when the voip overhead is not needed.

I don't know if I am explaining things well enough but hopefully you can get my drift and let me know if I am just dreaming up something that doesn't exists, or if it is really possible.

Thanks in advance!

Joe

 

[USAFRet]

Although I have not used it lately, try dd-wrt on your router.

 

[eibgrad]

Well actually QoS does control incoming traffic, but only IMPLICITLY.

TCP/IP is self-regulating and will automatically adjust traffic flow according to how well/fast each side can process the data. If one side issues fewer network requests over a given period of time, TCP/IP will return less data over a given period of time as well, in the assumption the receiver is being overloaded, and vice versa.

If it didn’t work this way, imagine how poorly the system would work! You’d have overloaded systems everywhere, rejecting large amounts of data, and all of it requiring resends, and no way to adjust data flows.

That's why it's false to claim you can't control incoming traffic. You can, but you can’t do it EXPLICITLY, you can only influence it by the behavior you exhibit on the outgoing side. And that's the point of QoS. Of course, like anything else, some implementations are better than others. But they're all based on the same principles and understanding about how TCP/IP works.

If you wanted to consider essentially SUSPENDING processes in favor of other processes, that’s raises its own problems. At some point, any related and active TCP/IP sessions are going to be dropped by the other side (presumed DEAD). That’s why you really need a *good* QoS implementation, so you can control traffic flow in a way that’s consistent w/ the TCP/IP architecture.

Of course, if the situation is bad enough, and QoS doesn't work well for you, you may have no choice but to add a second internet connection, perhaps using a dual-wan router so you can load balance, have failover protection, etc.

 

[bill001g]

It is all luck if you can affect incoming traffic by dropping outgoing traffic. First it is not TCPIP traffic it is ONLY TCP traffic that has a automatic slowdown built in. UDP traffic is unaffected. Most game traffic and many times streaming traffic is send via UDP. It will send at a fixed rate no matter how much you drop. Some UDP application may detect drops and slow down but this varies greatly by the application. VoIP in particular will not change the codec based on drop or jitter.

Even if you look at only TCP it cannot really favor one application by dropping outbound traffic. When I download a file I am only sending ACK packets up and at a minimum I get 1 MTU worth of data down. So for every 64 bytes of upload traffic I can get 12k/sec of data (assuming a 1500 byte MTU). Now the way TCP actually works is it keeps increasing the amount of traffic sent up to the TCP windows size per ack. Using the older limit of 64kbyte max window size the stream will increase until a single 64byte packet sent will result in a download rate of 512kbits/sec. So being able to send just 4 64 byte packet (2kbit/sec) can result in 2Mbit/sec download. This of course is ignoring the fact that it takes some time for the ACK packets to actual travel over the network so the actual download speed is also partially limited by the latency.

So how do you ever come up with a QoS policy applied OUTBOUND where as little as 2k/sec of outbound traffic can cause 2Mbit/sec of download traffic to occur. This only looks at a single TCP session. Let assume you have 50 because you are running bit torrent. Even if you only allow a single ack per session per sec you still can get 600k/sec and that is the absolute minimum because they all will try to increase the rate as soon as they get that one ack. How would you even define a policy to limit this. On top of these most consumer routers do not have the ability to limit by session they only have the ability to limit by IP or port. Some are even worse and have no concept of hard bandwidth limit. They only have the ability to prefer which traffic to drop outbound. BUT if say I have a 1m up limit and I only am attempting to send 100k/sec no traffic at all will be dropped. It will only drop when it actually reached 1m/sec

So now I have a application requirement like voice that actually has 2 requirements. It must have a dedicated bandwidth and it must have low jitter. This is normally called express forwarding and the common QoS tag for VoIP packets is called EF.

For a single call...ie no three way calls etc. If I am running g.711 codec I need about 100k/sec both up and down continuously plus some small amount of TCP for the SIP/H323 for the call setup and the messages that indicate I still have a active call.

Outbound you could reserve the 100k but I cannot see a way to ever GUARANTEE 100k/sec down other than to completely block all other traffic.

Normally this type of function is called RSVP in a commercial network. It is used to dynamically create a path in all the intervening routers. Our video conferencing system uses this to ensure it can get the bandwidth or it puts up a message that the requested quality cannot be obtained and that you should choose another. RSVP is a very advanced form of QoS that is difficult to implement even in a commercial network where you control all the routers and circuits.

Unfortunately no matter how hard you try there is no way to even come close to emulating the EF concept that VoIP really requires on the internet. You just have to tolerate noise and echo because of packet loss you cannot control.

The outbound QoS really is only good for TCP base application. You can make web surfing appear to run fast by limiting other application because unlike VoIP and other UDP streaming application it can tolerate some small packet loss.

It is possible to do what you want with a firewall but I don't know if any of the consumer ones can do it. It is mostly used to dynamically setup rules based on the call setup messages in the SIP/H323 stream. Because H323 is not 100% standard many times you have to open other ports based on messages sent between the VoIP devices during the call setup. It is normally used to ALLOW other stuff but I suspect you could use it to block traffic also. Even in commercial firewalls this it not a common feature or they only support particular vendors implementations.

 

[Js007]

Thanks for your responses!

I see my issues as two separate subjects now. Qos and my lack of bandwidth.


I suspected in a higher quality router or network equipment I could achieve what I am trying to accomplish, but this is just a home application with just a few users of which are almost never in use. But my primary problem starts with the slow available ISP speed with no other options until they expand. All of your explanations are very thorough and make sense...I thank you for that! But I am assuming with the best QOS in the world working on 760 up is not going to handle the loading of one web page without affecting an active voip call in progress. (jitter, chopping, etc..).
The high priority of voip cannot maintain the best quality when other things are trying to squeeze through the small pipe...or funnel would be a better way to explain it.

My biggest problem is when my daughter starts streaming a you tube video on her ipod when I am on a call. The few other network devices we can just refrain from using. So the ipod is the wild card and I was looking for a way to just block it when voip was in use. If it would just loose network ability altogether during this time would be fine with me. I could go into the router and activate an access restriction for the current time but that is a lot of work just to make sure it doesn't walk on me.










[/quotemsg]

 

[bill001g]

If your limitation is upload then the QoS works very well.....assuming you have one of the routers that has more than that "high,medium,low" crap. As mentioned dd-wrt does have the ability to limit. You need to think backwards when it comes to this. You limit all traffic except VoIP traffic to say 400k which leaves 300k for your voice.

But as you mentioned in your previous post it does limit the bandwidth when you are not using it. Commercial cisco router QoS does have a feature that allows you to guarantee voice traffic and when you are not using it allow other applications to use the bandwidth if you are not. If you had control of both ends of the connection it might be work but on one end only it likely is a waste of money. which is my next point.

The youtube video it not a issue with the UPLOAD it is a DOWNLOAD limitation. If we lie a little bit what your daughter does is say give me a video...and then receives video. During this time she does not ask youtube for anything until she is done. So you could limit her to zero after she asked and the video would still consume all the download bandwidth.

To a point we are lucky that youtube is not technically a "streaming" media. It uses TCP rather than UDP. So to some extent you can control it with upload QoS but not a lot.

Not sure what to tell you. The only solution would a somewhat automated version of what you propose and that would be blocking everyone but you from using the device. Although it sound simple it is not so easy to detect your usage and then block traffic....I suspect it can be done on dd-wrt since you can run scripts in the underlying linux based OS but it is beyond my abilities.