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.
> 
> John/


Hi John,

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 
the matter:

(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 
drop-outs).

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...


Regards,

Adam.