[ previous ] [ next ] [ threads ]
 From:  Michael Brown <knightmb at knightmb dot dyndns dot org>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Inbound (downloaded) traffic is not being shaped at all
 Date:  Sun, 28 Jan 2007 12:02:39 -0600
Well, I think there is a mis-understanding here. You can traffic shape 
inbound traffic, but it's not possible to make it "instant".  When you 
traffic shape outbound traffic, you already know your "limits" and 
m0n0wall responds to this accordingly.  With inbound traffic, even when 
you know your "limits" inbound, you can't account for limits that exist 
outside of your connection.

For example, if you are trying to traffic shape so that your VoIP phone 
and your favorite website to download from can co-exist without messing 
with your phone calls. The problem here is the burst of traffic that 
flows across the Internet.  You are on a VoIP call when you click on 
your favorite web site to download a large file.  If your ISP link 
limits you to a 1.5 M/bps down and you have m0n0wall set accordingly, 
everything is fine until someone outside of your ISP network tries to 
send data faster than your link can handle.  So you click a file from 
the website and it starts to send the file at 3 M/bps, well your link 
can't even handle that speed so before it even gets to m0n0wall, packets 
are being resent to let the server know that this 3 M/bps speed is too 
fast and that it needs to slow down until the speed evens out.  If you 
are in the middle of a VoIP call, it will really mess with the call 
until the "inbound" data finally calms down to a speed that you link can 
handle, then m0n0wall can finally get it's hand on the packets to 
traffic shape further.

It's not that you can't traffic shape your link to 768 K/bps if you 
wanted, it's that large speed burst on the Internet that funnel down 
your link are beyond the reach of m0n0wall.  TCP/IP is made to be 
flexible for speed, but it always starts at the highest speed possible 
then works it way down to a stable speed.  If you want to limit 
everyone's download speed to 768 K/bps, then m0n0wall can easily do 
this.  If you are hoping to have a perfect VoIP call while this takes 
place, it will all depend on your ISP if this will work properly or not 
for the first few seconds that the download begins during that VoIP call.

Hopefully that explanation wasn't too confusing?


Michael wrote:
> So there is no point in having any inbound traffic rules on the WAN
> interface, only outbound (upload) on the WAN interface? I was hoping I could
> shape nntp downloaded traffic to use a low priority queue.
> Is the above assumption correct Chris?
> Mike
> -----Original Message-----
> From: Chris Buechler [mailto:cbuechler at gmail dot com] 
> Sent: Sunday, January 28, 2007 1:24 AM
> Cc: m0n0wall at lists dot m0n0 dot ch
> Subject: Re: [m0n0wall] Inbound (downloaded) traffic is not being shaped at
> all
> On 1/28/07, Michael <zlinda1002 at cox dot net> wrote:
>> I have been monitoring the monowall 1.3b2 for awhile now and just realized
>> that NO traffic is going through any of the rules that have to do with
>> incoming traffic (downloaded to my pc, etc), traffic is fine with the
>> outgoing. I have read that monowall doesn't help with inbound traffic for
>> some and then others it seems to work.
> Nothing can shape inbound traffic effectively. By the time it gets to
> your firewall, there's no sense in queuing it since your bottleneck
> isn't between the firewall and the internal hosts, it's your Internet
> connection and it's already past that point. The only really effective
> way to shape that traffic is if you controlled something on your ISP's
> end before it gets to your rate-limited link.
> -Chris
> ---------------------------------------------------------------------
> 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