[ previous ] [ next ] [ threads ]
 
 From:  =?iso-8859-1?q?Jose=20Iadicicco?= <joseiadicicco at yahoo dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Cc:  Adam Nellemann <adam at nellemann dot nu>
 Subject:  Re: [m0n0wall] Re: m0n0 - traffic_shaper
 Date:  Wed, 28 Apr 2004 23:39:31 -0300 (ART)
Hi Adam!
        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

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

Greetings Adam!!!!!

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!)
> 
> 
> Regards,
> 
> Adam.
> 
> 
> Jose Iadicicco wrote:
> > Hi all you guys! Why you sayed that traffic shapper 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
> > 
> > 

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


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

------------



http://autos.yahoo.com.ar