On Sat, 28 Jun 2003, John Voigt wrote:
> I'm beginning to see that I was very unclear in my original post. In an
> attempt to simplify my question I left out some important information which
> is key to understanding what needs to happen to solve my problem. My
> apologies for that.
> Let's say I have 25 users on my WLAN. 21 are "residential" customers and 4
> are "commercial" customers. So I really have 2 problems - 1 is shaping
> traffic differently for each class of customer and 2 is limiting bandwidth
> differently in each direction for each class. Problem 2 solves an issue
> with wireless lans called the "hidden node" problem. The technical details
> are outside the scope of this but if you're really interested you can do a
> Google search and you'll find out all about the hidden node problem.
I'd hardly say "solves". That problem can only be addressed effectively
at the link layer, not the IP layer. It's important to understand how
*little* can be done at the IP layer.
There are basically three things IP can do to throttle bandwidth:
1) Discard packets.
2) Send ICMP Source Quench.
3) Send RFC3168 Explicit Congestion Notification.
By far, #1 is the most common approach. #2 has been around since the
inception of IP, but is somewhat crude and has never been widely used (not
to mention running afoul of confused sysadmins that like to block ICMP at
firewalls). #3 is quite recent and not yet widely supported, and can also
run afoul of certain picky firewalls. The net result is that most
bandwidth limiting is done by *throwing away perfectly good packets*.
With TCP as the transport protocol, dropping packets *indirectly* controls
the transmission rate, due to TCP's congestion avoidance algorithm. In
fact, in most cases, dropped packets are the *only* feedback TCP gets
regarding bandwidth limitations, guaranteeing that it can almost never
fully utilize whatever bandwidth is available. With non-TCP protocols,
the effect of dropped packets is a function of the higher-layer protocol's
retransmission and congestion control policy.
So, in the case you're most concerned about (upstream wireless), the
*only* method you have available is to discard the packets that so
painstakingly made it through collision avoidance, and hope that the
remote(s) get(s) the hint.
If you're counting on TCP to do this, then the only question with regard
to asymmetry is why it doesn't already figure out that upstream
transmission is harder. If this really is an issue, I suspect that it's
mainly due to the willingness of the remotes to keep excessively long
queues of their own, sending bursts of packets when they get the chance.
While it would be better to fix this in the remotes themselves, it might
be sufficient to enforce fair sharing of the bandwidth with appropriate
time constants to discourage "burstiness" without making any assumptions
about the actual bandwidth available. The main problem is that I don't
see any option to specify the time constant of the BW measurement. Also
note that AFAIK the time *resolution* of the BW measurement is the "tick"
(4ms in m0n0wall).
> So now what I do (I am currently doing this with a very expensive commercial
> box which I'd obviously like to replace) is group my 21 users into 3 groups
> of 7 and assign each group 512kb downstream BW and 64KB upstream BW. I then
I presume the "64KB" was supposed to be "64kb" ("b" = bit, "B" = byte).
Otherwise, both numbers would be the same. :-)
> create an individual group for each of the commercial customers with as much
> bandwidth as they've paid for. My current solution also has a nice feature
> I'd like to include (though it's not critical) which limits "unknown"
> stations (MAC addresses we don't recognize) to it's own set of bandwidth
I don't see the purpose of the three groups of 7. I'd expect you either
want all 21 in one group for simplicity, or each of the 21 in its own
group to enforce "fairness". I'm not sure you really need any explicit
limitation on those stations at all, as long as the commercial customers
get "first crack" at the BW they've paid for.
> So I guess to boil this down further, I need to be able to set up asymmetric
> pipes and assign MAC addresses (IPFW2 can do this right?) to the pipes. A
Yes, you can do that, although I think the only need for asymmetry should
be in the guaranteed-bandwidth cases. After that, let everyone fight over
what's left. AFAICT there's no such thing as an asymmetric pipe, but you
can treat the two directions as separate pipes.
It would be nice if there were a way to cause TCP ACK-only packets to
bypass traffic shaping, since dropping them can never make things better,
but there doesn't appear to be any provision for doing this (since it
involves a somewhat complicated test on the packet length).
If sophisticated traffic shaping is important, you might want to look at
OpenBSD, since it has more flexibility in that area. Or even when using
FreeBSD, the (substantial) section of the OpenBSD FAQ on the new PF might
be somewhat helpful, taking the PF differences into account. See:
or, more specifically:
> nice PHP GUI would be a nice plus.
Or even just a way to merge user-defined rules with the automatic ones.
The typical problem with GUIs is that they become limitations on the
flexibility. I.e., as has been said about some systems, "making simple
things easy and complicated things impossible". :-)