[ previous ] [ next ] [ threads ]
 From:  David W. Hess <dwhess at banishedsouls dot org>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Re: Trouble with VoIP and AC Nielsen's Homescan consumer panel
 Date:  Sun, 17 Sep 2006 20:22:02 -0500
Michael Brown pretty much summed up the limitations of trying to apply traffic
shaping to inbound connections when you have no control on the other side of
your link.  By the time TCP or external flow control can act, the damage is
already done and VOIP traffic is being delayed or dropped.  In the worst case,
not only have unwanted packets already traversed the slowest link, but in order
to indicate that throttling is necessary, they have to be dropped even though
they are already available and the link has already paid the price getting them
to your network.  Incoming flow control is still needed but it is not as
effective as outgoing flow control.

pfsense uses a different traffic shaper (altq versus pf?) which among other
things has the ability to borrow traffic from unsaturated queues and has
adjustable service curves.  Shaping inbound traffic however is still limited by
the nature of IP.  pfsense also supports Random Early Detection and Explicit
Congestion Notification which should throttle earlier and without dropping
packets but the later is not universally supported and I am not sure how much
they help.

Personally I found the pfsense traffic shaper to give better VOIP performance
but it is difficult to quantify and setup is more complex.

On Mon, 18 Sep 2006 09:56:59 +1200, you wrote:

>Is this correct if traffic shaping is correctly configured?
>Does anyone know if pfsense is any better, in light of this explanation, and presuming it to be
>Kind regards 
>David Hingston 
>----- Original Message ----- 
>From: "Michael Brown" <knightmb at knightmb dot dyndns dot org>
>To: <m0n0wall at lists dot m0n0 dot ch>
>Sent: Monday, September 18, 2006 9:47 AM
>Subject: Re: [m0n0wall] Re: Trouble with VoIP and AC Nielsen's Homescan consumer panel
>I tackled this same issue last year with m0n0wall, but soon found that 
>it's not m0n0wall but just the way TCP/IP is built along with ISP and 
>your Internet connection.  When you get into a phone call, your vonage 
>service is using about 90 K/bs of bandwidth.  While you are on the 
>phone, you go download your favorite linux distro and then all of sudden 
>you can't hear what the other guy is saying.  The problem is not 
>m0n0wall or Vonage or anything else in the hardware setup you have. The 
>problem is, as soon as you start the download of that file, the server 
>tries to send the data as fast as it can.  If it can send more than you 
>can receive, then TCP/IP kicks in to start cutting things down until a 
>more stable rate is achieved.  The problem with this means that m0n0wall 
>can't traffic shape data when the connection you are on is over 
>saturated.  So if you have a 1 MB  connection to the Internet and a 
>server starts to chuck a file at 2 MB then there is nothing m0n0wall can 
>do to stop this until the send server finally let's it transfer speed 
>drop down low enough to pass through your hardware limitation on 
>bandwidth.  Then m0n0wall has a chance to apply some traffic shaping 
>rules. So it doesn't matter if you make one pipe for 56K for everything 
>else and the other for 900 K for Vonage, the rules just won't have any 
>effect against over saturation. Now when it comes to sending traffic 
>shaping rules, m0n0wall has the advantage because it's the start point 
>of the packets and thus can traffic shape those perfectly.  So if you 
>have a send pipe limited to 512 K/bs, m0n0wall isn't going to try to 
>send things out at 900 K/bs just for the heck of it, it will stay within 
>the rules you set.
>Basically, m0n0wall is not "first in line" when it comes to traffic 
>shaping data being received because your ISP, Internet, etc all come 
>before it. It is first in line when it comes to sending data and traffic 
>shaping because on the opposite side of the Internet, it can control how 
>much is being sent to begin with.  That doesn't mean m0n0wall is useless 
>at traffic shaping inbound data, only that real time applications like 
>VoIP will suffer because of this.  M0n0wall is great, but if the data is 
>already being over crowded before it even gets to m0n0wall, traffic 
>shaping won't solve the issue. That's where you get into ISP issues, but 
>good luck trying to get them to do you a favor.
>Basically, m0n0wall is great, but if packets are being dropped before it 
>even reaches m0n0wall, there is nothing you can do about it.
>Hope this saves some hair pulling like I had.
>Richard Deno wrote:
>> Ive just added a set of 150K pipes for Vonage to directly use, and 
>> have been
>> checking on port forwarding (the 10000-20000 block is forwarded, and I've
>> tried forwarding the other ports but with no change in quality).  
>> However I
>> still am getting some fairly poor voice quality and not able to 
>> complete the
>> data transmissions.  If someone could find that dialing prefix that 
>> would be
>> great.
>> Thanks a bunch--
>> Richard
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch