* Kurt Huwig <42C98CEA.3080000@xxxxxxxxx> 2005-07-04 21:24 > I have quality-problems with my VoIP connection caused by two causes: > > 1. head of line blocking > > My MTU is somewhere between 1400 and 1500 and my upstream is > 16kBytes/sec. VoIP sends a packet every 20ms, so one 1500 byte package > blocks the sending of 4.6 packets on time. There is no possible way to solve this problem without lowering the bandwidth requirements of your VoIP application. You could try using a stronger compression algorithm by using another codec or reduce the quality. Even the most brilliant QoS setup cannot push more data through a pipe than physically possible. > 2. queuing on remote side > > If I run a download, the queue on my provider's side is filled up and I > get long delays. Up to a certain amount of connections you can teach all the involved nodes to always send below the threshold which would end in a queue at your isp. > I have two ideas how to handle this: > > 1. fragmentation > > Once VoIP traffic starts, I send an ICMP message that fragmentation is > neccessary and the maximum size is somethink like 150 bytes. This only increases the overhead per packet so you'll end up transferring even less actual payload in the end which is probably not what you want. > 2. reduction of tcp window size > > Here I alter the packages to report a window size of 1 which should > reduce the downstream data rate. How would that solve your _VoiP_ problem? After all the problem is that you simply don't have enough bandwidth to cover the needs of your application. You really need to solve this at application level first. What you need is a stable, constant flow of packets well within your bandwidth bounds. Once your application is running smoothly solo on a line you can get back to QoS and ensure to guarantee the minimum required ressources while being influenced by other users. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html