Hello, I know this has been discussed before, but I am not a developer (I wish I did have the skills as I would code this myself otherwise). I have a huge respect for all that the OpenBSD community does and this is not a winge or a moan, please hear our woes.
Yes, of course downstream queuing is only of benefit for TCP to get the sender to slow down etc etc, but that is exactly what we need. IF we don't queue downstream traffic, our downstream link gets saturated and our ISP starts to drop random packets. If we do the downstream queuing here, we pre-emptively drop low priority packets before saturation thus slowing the sender down before saturating the WAN's downstream leaving headroom for VoIP etc. We have a firewall with 4 internal interfaces for various different subnets and 1 external WAN interface like many users have. Queuing upload traffic is easy on the WAN interface, but downstream traffic needs to be queued on each of the internal interfaces. Initially this would seem fine, until you realise that if 3 of the 4 internal interfaces are idle the busy 4th interface cannot use the entire download bandwidth available on the WAN. This is because you can only assign a 'slice' of the total download bandwidth (summing to 100% of WAN speed) to each of the internal interfaces resulting in very inefficient download utilisation across the internal zones. I appreciate that we could buy 'another' 2 boxes with only two interfaces to sit on the WAN link (both running CARP etc) but this seems extremely inefficient, wasteful, harder to manage and simply ugly when compared to other features of OpenBSD, to end up with 4 boxes (2 multi-zone firewalls, and 2 queue servers) to achieve resilient download queuing shared across multiple local subnets. So, their is a clear need to be able to queue inbound traffic on the WAN interface when there are multiple internal local interfaces. I appreciate this is a feature that would need to be added to ALTQ than PF. So far my thinking is to create a second virtual loop-back interface 'lo1', and divert (divert-to not redirect (rdr-to)) all inbound traffic on the WAN interface to lo1. Then set-up a queue on lo1 which represents the desired shared 'inbound queue' for all internal interfaces. Naturally after the traffic passes through lo1 it will get queued, and the packets should then get routed as normal via their respective internal local interfaces etc. Would this work? We have to use inbound queuing, without it our WAN link saturates with low priority traffic, and we need to maintain headroom for high priority VoIP traffic etc. But we also want any internal local network to be able to fully utilise the WAN downstream bandwidth instead of only 1/4 of it even when the others are idle. Thanks for your thoughts and ideas in advance :) Andy If we had to bounty this, how much? I might be able to get =A3100 for a bounty? Cheers.
