Here's the theory behind why inbound shaping doesn't work (or at least
doesn't work well) If anyone has knowledge to the contrary, please post:
= = =
Since there is no built-in "traffic control messages" (or similar) in
TCP/IP, there is no way for m0n0wall to "tell" the device(s) on the
"other side" of your WAN link (such as the router at your ISP's end of
your ADSL line) to stop sending packets (or do so at a slower rate).
For this reason, limiting your inbound traffic will only cause packets
to be queued on your m0n0wall box. While this may cause you (on a LAN
box) to see shaped traffic limits being upheld, those queued packets
would still have arrived through your ADSL line at the same rate
(bandwidth) that they were sent from the server(s), regardless of what
settings you have in your m0n0wall traffic shaper, and would thus have
"hogged" whatever portion of your inbound bandwidth they happened to need.
Of course, eventually, since the ACK's for these (queued) packets
doesn't arrive (or are much delayed), the sending server(s) may stop
transmitting more packets, but it is difficult to say if this has the
effect you were looking for with the inbound traffic shaping, and it
will certainly depend on the protocol(s) and the server(s) in
question. In some cases this may have little to no effect, in others
it may cause inbound traffic to become "lumpy", and (perhaps) in some
it may do just what you want (ie. cause traffic to be slowed down to
the limit you have set in the shaper).
Since the latter effect (delaying of ACK packets) can be achieved with
proper outbound shaping (of small packets, with the ACK flag set), I
would think that is the better solution, instead of queueing a lot of
traffic on m0n0wall (especially if you have ANY kind of RAM or CPU
limitation on the m0n0wall box!)
= = =
As mentioned, if you (or anyone) has good arguments or knowledge that
contradicts the above, I would much like to know about it (and, so I
should think, would the rest of the mailinglist!)
Jose Iadicicco wrote:
> Hi all you guys! Why you sayed that traffic shapper for inbound
> traffic doesn´t work? I configured the traffic shaper for inbound
> traffic and outbound traffic and it works so fine! I limited the
> downstream to 64 Kbits and the upstream to 32 Kbits and it works
> okey too. I dont understand you guys. Can you explain me what are
> you talking about? My internet connection is 512 kbits upstream and
> 128 kbits downstream (ADSL) and I have 12 computers of different
> people using Kazaa, Emule, etc etc in each computer, without any
> control of each computer, but its working okey since 4 months ago
> when I configured the traffic shaper.
> Greetings to all you friends!!!!
> --- Adam Nellemann <adam at nellemann dot nu> escribió: > > Dennis
> Wallberg wrote:
>>>> Hi I read the traffic_shaper.txt and I have one question.
>>>> "For assymetric WAN connections, it is important to ensure
>>>> that all pipes and queues exists in pairs, one for each
>>>> direction, and that these have the apropriate bandwidth
>>>> specifications". Do I really have to have pipes/queues for
>>>> inbound traffic? Would it not be sufficient with
>>>> rules/pipes/queues on by outbound traffic since this it the
>>>> only traffic I really can control?!
>> Hi Dennis,
>> You are of course right, there is (usually) no need to have any
>> pipes/queues/rules for inbound traffic. Indeed, this will often
>> make things worse!
>> I was rather new to traffic sharing when I wrote the text, and
>> did so in a hurry due to "popular demand". At the time I thought
>> I'd soon get around to writing another, more thorough, version,
>> as well as possibly doing the traffic shaper chapter for the
>> m0n0wall documentation project. Unfortunatly I've been very busy
>> ever since, and have thus had no time to do these things :(
>> Since then I've myself removed all the inbound rules from my own
>> m0n0wall configuration. I guess I should have posted a notice
>> about this.
>> Sorry for the inconvinience this may have caused!
>> Hopefully I will soon be able to, at least, post an updated
>> version of traffic_shaper.txt, with corrections such as the
>> above, but right now I'm still too busy.
>> 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
> ===== El objetivo escencial del correr es probar los limites de la
> voluntad humana...
> ------------ Los mejores usados y las más tentadoras ofertas de 0km
> están en Yahoo! Autos. Comprá o vendé tu auto en