I've been tuning some networks for VoIP recently, and to get really good results I've found it's been necessary to do altq in both directions. This has familiarized me with the problems associated with not being able to do altq on inbound traffic. I'm aware of several arguments against doing this, but I don't think any of the ones I've heard address the problem satisfactorily:
-Hosts cannot be prevented from sending me packets, so the potential exists for inbound bandwidth to be exausted no matter what I do. But this flaw is shared by other policy tools in PF, such as OS fingerprinting. That OS fingerprinting can be thwarted by an attacker does not mean it's useless as a policy tool. Similarly, in most cases the protocol in question (usually TCP) will throttle a connection in response to lost packets. If the inbound limit is set sufficiently below the maximum of the connection (in my experience, about 10-15% below), it will have the effect of reserving some bandwidth for more important traffic. An attacker or misbehaving protocol can still cause problems, but they will be a problem either way. -Inbound queuing can be implemented in some circumstances by using altq on the internal interface. These situations are what have convinced me it's useful as a policy tool. However, this has flaws. For example, if there is more than one internal network, one can't create a single altq instance that covers them all. You can divide bandwidth between them, but you can't borrow between the different queues in this case. Also, if there's traffic bound for the firewall itself, this won't touch any queues on the inbound direction. As an example, one of the sites where I've encountered this issue has a 10 mb external connection, with two companies sharing the connection. Currently, bandwidth must be divided between the two offices, with no borrowing on the inbound queues because they're on different interfaces. Another instance where this might happen is if an office has a LAN and also a restricted wireless network. I can understand why inbound queuing would be regarded as the wrong solution to this since it's not really inbound queuing; the packet has already been received. An alternative might be the ability to do borrowing between queues for different interfaces, or create a virtual queue that can be a parent to queues on many interfaces. Does anyone know of a way to handle this with the existing capabilities of PF/altq? -Anthony
