[OPLINTECH] Bandwidth issues.

[Nathan Eady]

"Christopher Brose" <brosech at oplin.org> writes:

> I know everyone looks at the subject “bandwidth issues” and cringes,

There are a couple of issues.

First, you have to find the right queuing discipline for your needs.
For example, if you have all your staff systems behind an inner
firewall that does one-to-many NAT, you either don't want fairness on
a per-IP-address basis, or more likely you want to treat that address
specially (e.g., prioritize it to a lower layer).  On the other hand,
some popular queuing disciplines (e.g., SFQ) do their "fairness" on a
per-connection basis, rather than a per-IP-address basis.  That's
problematic because some protocols, including most of the important
ones (dns, http, etc) are largely designed to use one connection per
process; whereas, others (notably, peer-to-peer filesharing) are
designed to use dozens of connections at once, which can allow those
users to unfairly monopolize all the available bandwidth.  So you have
to know what you're trying to accomplish and pick out a queuing
discipline appropriate for that.  If your needs are complex, you
probably need a classful root discipline and some subqueues, to get
everything like you want it.

The other thing is that a lot of traffic (e.g., most web traffic) is
fairly asymetric, so to be effective you really need to shape at both
ends of the bottleneck (which will typically be your T1).  Shaping
your upstream traffic doesn't necessarily stop the downstream traffic
from being congested and unfairly monopolized by a small number of
high-demand users or applications (especially if they're using
protocols that tend toward asymetric usage), so if that's what's
happening, you'd really need to have shaping done on the ISP's (e.g.,
OPLIN's) end.

Personally, I am just thankful that I work in a single-site library,
so we don't have to worry about things like our ILS being slowed down
by internet congestion.

-- 
Nathan Eady
Galion Public Library