A question came up, after posting the below explanation:
Anyone knows if there actually exists a protocol that would allow two
routers (specifically m0n0wall and whatever is on the ISP side of the
WAN link) to "negotiate" shaping info (in this case: so as to limit
inbound traffic on the ISP side)?
Various "technologies" comes to mind, such as RIP, SNMP and QoS, but I
wouldn't know if any of these will do this job, nor if it is likely
that any ISP are (or would) support(ing) this kind of thing?
If anyone knows about such a protocol or "technology", I'd like to
hear about it (mainly to satisfy my curiosity). More important, if
this might indeed be possible, it should be worthwhile to look into
having m0n0wall support such a technology, as it would much improve
the results of traffic-shaping! (Even if no ISP currently support
this, there might still be users with a m0n0<->m0n0 setups that could
benefit from such "interactive" or "adaptive" shaping?)
Well, just a thought anyway...
Adam Nellemann wrote:
> 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 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!!!!
>>>>>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?!
>>>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
>>>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
> 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