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?
> 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?
> -----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
> 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.
> 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