All you need to do is specify the queue to be the same name in inbound and outbound. Once you label a state/packet as part of a queue, it's sticky. If it's on the way out interface A and it has a queue named 'bob' and you've assigned it to the 'bob' queue, it'll be queued. If you create a queue on interface B called 'bob', it'll be queued that way. As such you can also specify them to have different properties, just call them the same thing. It's worked this way since at least 2005, probably before.
Kelley Reynolds President Inside Systems, Inc. On Jan 11, 2011, at 3:46 PM, Bonnie Packet wrote: > 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 >
