Although I respect the theoretical argument that "you can't shape/ limit inbound packets", my observations agree with those of with Karl that it's simply not true in the real world. If you read my original posting, I am effectively limiting inbound traffic as far as the user is concerned (inbound =3D=3D the higher-bandwidth download direction from the external Internet). Again, that's working quite well already - whatever mechanism is being used by altq seems completely effective in doing that, at least in my setup. Bumblebees can actually fly, folks.
In fact what I'm trying to do now is limit the outbound traffic from the router ( =3D=3D the lower-bandwidth upload direction, TO the external Internet) which I would think would be easier - as I control the router and can in theory ( there's that word again...) shape/limit either at the point of (a) accepting those packets from the internal, NATted network interface or (b) sending those same packets out of the router over the exernal, ADSL-connected interface. That seems very doable; the question is how to manage it simultaneously with the download direction when those packets already part of an established, stateful TCP connection that bypasses the firewall rules. So while the discussion is interesting, it's not in the least germane to the original question (a working bi-directional PF ruleset...) I'm still hoping an example of that is out there somewhere....somewhere.... thanks /BP/ On Jan 11, 11:41=A0am, lanc...@ucolick.org (Kyle Lanclos) wrote: > Karl O. Pinc wrote: > > There are may proofs that throttling TCP works, starting > > with the original paper (Van Jacoson) in 1988 through > > to the many products today that _do_ manage to reserve enough > > inbound bandwidth that, e.g., VOIP works reliably. =A0I once > > promised on this list to setup a test environment and > > re-prove it but have never gotten around to it and it > > hardly seems worth bothering. > > We have an observatory that sits on the other side of four bonded T1 > links, and for political reasons, use pf to shape the traffic *only* > on the observatory end of the link. We shape both inbound and outbound > traffic; while the outbound traffic is shaped much, much more > effectively, the shaping we perform on the inbound traffic is an > improvement over no shaping at all. > > It is only effective for our situation if we deliberately sacrifice a > fraction of our inbound bandwidth. In our case, the maximum bandwidth > of the bonded T1 link is 6 megabits/second. Our pf configuration uses > a maximum bandwidth of 5.5 megabits/second (limit determined empirically)= , > and random early detection to drop packets. > > The other key factor is that the inbound streams we care about tend to > use much lower bandwidth than whatever it is that's clogging up our > inbound pipe. If all we cared about was raw throughput, the loss of 10% > of our total bandwidth may be more of a problem than ungraceful network > congestion. > > --Kyle
