I read everything you wrote about shaping, and I understand it, but I think that if I dont
use the incoming traffic shaping, and one of the users of my network opens the kazaa and begins to
download with speeds near the total downstream bandwith, then the others users wouldn´t browse the
The only way i find to ensure all users can share the bandwidth was using the traffic shaping with
10 Kbytes for each one (downstream) and 4 Kbytes for each one (upstream), and everything works
I would like to use a kind of QoS to prioritize the internet browsing before the kazaa and emule,
etc etc. You think another way is possible?
--- Adam Nellemann <adam at nellemann dot nu> escribió: > Hi Jose,
> 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!!!!
> > Jose
> > --- 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?!
> >>>> /Dennis
> >> 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.
> >> Adam.
> >> ---------------------------------------------------------------------
> >> 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
> > http://autos.yahoo.com.ar
> 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