John Voigt wrote:
> ----- Original Message -----
[...removed for brevity...]
> Maybe I misunderstood your question or the point you were making. I just
> don't see any reason to not use that 1-5% as I'm struggling to figure out
> what we're saving it for.
Let me try to explain what I'm talking about, and let me start by
noting that this, in turn, is something I've been told by people whom
might know more than I about these things than I, but even so this is
a complex topic and there might possibly be more than one "truth" to
(WARNING: Looong "explanation by example" follows...)
Imagine a situation where two hosts on the WAN are sending and
recieving packets to and from one or more hosts on your LAN. Let's say
one is your VoIP server and the other is some ftp server.
Now, as long as the total bandwidth used by these two "packet streams"
are below the limit imposed by (some piece of hardware owned by) your
ISP, everything is fine, and the traffic shaper in your m0n0wall will
be able to do it's job (in this case, ensure that a minimum number of
bytes/second gets through to your VoIP server, so as to prevent voice
But in case, say the ftp transfer, gets up to speed and start sending
data faster to the server, so the sum of these two streams exceeds (or
at least hits the roof of) your ISP imposed limit, the problems begin:
Your ISPs aforementioned "piece of hardware" (say your ADSL modem, or
the router on their side) will now start dropping random packets, in
order to keep your data stream at or below your purchased limit. Since
your ISP does not care if the packets dropped are from your ftp
transfer or from your VoIP device, you get what I termed "arbitrary
shaping", as opposed to the shaping imposed by your configuration of
the m0n0wall shaper. Such "arbitrary shaping" is exactly what you are
trying to avoid, by using the m0n0wall shaper, as "arbitrary" does NOT
ensure any particular priority or bandwidth to any particular kind of
(say VoIP) packets.
If you had instead made you m0n0wall pipes just that tad smaller than
your ISPs "pipe" (or "measured bandwidth" actually), then the above
situation should never arise, since m0n0wall should start "throtling"
(ie. dropping packets or whatever) BEFORE the ISP device does, and
hence m0n0wall will continue to be the device that "decides" which
packets gets droped and which doesn't, which MUST be the case if you
want to ensure that it is NOT the VoIP packets that get dropped (or
whatever your rules, queues and pipes dictate).
So, as you can see, it is not that we are actually "saving" those
1-5%, it is simply a sort of "safty margin", ensuring that the
m0n0wall shaper will start dropping and/or queueing packets BEFORE
some ISP controlled device does it. Ideally you would of course make
your pipes exactly as large as your maximum (un-shaped) bandwidth, but
since such measurements can´t ever be 100% precise, I choose to err on
the smaller side, seeing as that will never have a greater impact than
those few "safty" percents, whereas erring on the larger side could,
potentially (assuming the above "theory" is correct), put your shaper
out of commision in the situations where you need it the most.
All the above has silently assumed outbound shaping. I'm not exactly
sure of how it all relates to inbound shaping? It might be that for
inbound pipes, you DO want to make them a tad larger than your
bandwidth, but I don't think that is the case, although that is based
entirely upon my own intuition?
I hope all this makes some sense at all? Even if it does, there might
be some flaw in the logic somewhere, that I have either missed, or
lack the knowledge to spot?
As before, I am very interested in hearing any arguments against (or
for, for that matter) the above, as I am not in any way an expert on
this topic, but on the other hand I would like for my shaper to be
configured in an optimal way...