Since the absolute rate-limiting step (no pun intended) is your SDSL line, I _think_ you might achieve the desired affect through either method, applying egress traffic control to eth1, or ingress control through an IMQ device. Of course, you don't want to limit all traffic from eth1 towards your client-"hosts" to this tiny 512k ... but that can be taken care of with some more fine-tuned filtering on your egress case. I am currently experimenting with a similar situation where the wirespeed is unlimited (100Mbit compared to the ~10Mbit that I want to throttle at) and my initial setup was to do egress managment on both sides of the FW box. It works well, but I have a problem: traffic from the internet to eth1 (to keep with the conventions of your example) gets limited at flow point (3) ... however, incoming traffic at eth0 measures signifcantly (25%) higher than the eth1-ceiling rate -- the FW box seemingly can receive (and throw away) packets willy-nilly since there's no set limit on eth0's incoming. I thought that throttling eth1 would be enough (assuming some sort of rate-discovery smarts) but I guess I was wrong. Once I do some testing with an IMQ setup on eth0, I'll be happy to let you know how it goes (assuming others aven't already piped up). Can anyone give me a pointer to an explanation of how tcp rate-discovery works? Was it a silly assumption to make that if one side of a router was choked that the other side would refrain from this wasteful sort of behavior? Or, is this a context dependent situation where single tcp streams would do what I want, but thousands of small ones may not have a long enough connection time to behave properly when such a choke-point is pegged at its limit? thanks, -rob On Fri, Apr 25, 2003 at 03:57:39AM -0700, George Spiliotis wrote: > > Now suppose that we implement the same bandwidth management > rules as in flow point (1) at flow point (3) changing eth0 > to eth1 (i.e., the internal interface) and ip_src with > ip_dst (as is been suggested by LARTC). What should happen > (**am I right on this one??**) is that packets traveling > towards host 2 will start to be dropped because host 2 gets > the information at a rate of only 102Kbps so, after an > allowed latency time, the host on the internet which sends > information for our host 2 will slow down eventually to a > rate of 102Kbps. The rest 410Kbps of our DSL line is used > for the information flowing towards our host 1. This should > accomplice our task partially. > > What happens if the fw box has also a proxy service running > and some of the information requested by host 2 is already > on the fw box? Then it seems that creating such a low > (512Kbps) ceil on a real 10Mbps internal interface is not > the best approach. Now suppose we create an IMQ interface > at flow point (2) and attach the same disciplines (htb) as > in flow point (1). This should eventually accomplice our > 80/20 division of bandwidth but does it really works on the > traffic entering our fw/bw manager box (considering some > latency time for the flows to become stabilized)? It seems > this is the way to go for policing traffic entering our > fw/bw management box but I really need more information on > the subject. > > Thank you for your time, > George. > > _______________________________________________ > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
