Dear list members,

I want to develop a bandwidth manager for shaping traffic
in my company. I am trying to find out if it is better to
use an IMQ interface or shape the traffic towards the
internal machines, so any help on this matter will be much
appreciated...

The specifics. The design is simple (so that me, and
possibly others, can understand the principle):
We have one machine acting as a firewall/bandwidth manager
on a SDSL line and two internal hosts connected to it. We
want to assign the available DSL bandwidth with a rate
80/20 to these two hosts. The schematic is as follows:

+----------+
                                  +--------------->|  Host
1  | (10.0.0.1)
                                  |
+----------+
            +----------------+    |
<-- SDSL -->|  fw/bw manager |<---+
            +----------------+    |
                                  |
+----------+
          <---(1)         --->(3) +--------------->|  Host
2  |
          --->(2)
+----------+

I have marked the possible points for shaping traffic with
the marks (1),(2) and (3). Now flow (1) is the first to
address (which happens to be the easy part of the
construct) with an htb qdisc (expressed in tcng):

eth0 {
  egress {
    class (<$h1>) if ip_src == 10.0.0.1;
    class (<$h2>) if 1;
    htb () {
      class (rate 512Kbps, ceil 512Kbps) {
        $h1 = class (rate 410Kbps, ceil 512Kbps) { sfq; }
// 80%
        $h2 = class (rate 102Kbps, ceil 512Kbps) { sfq; }
// 20%
      }
    }
  }
}

For simplicity lets assume that no NAT or other mangling of
the packets happen at the firewall in both directions, so
packets enter and leave with their source and destination
IPs unchanged.

Now, suppose that host 1 and host 2 start to generate
traffic towards the internet at a rate of 512Kbps each, at
the same time, for 5 seconds. It is easy to see that host 1
data will leave the fw/bw box at a rate of 410Kbps while
host 2 data will queue up leaving at a rate of 102Kbps,
till all data from host 1 is sent, thus leaving the whole
512Kbps for host 2.

What happens if host 1 and host 2 initiate a connection
with a foreign host on the internet requesting both 1Mbyte
of data to travel from the internet towards host 1 & 2?
Both hosts send relatively small packets which reach
quickly the destination host and data starts to flow from
that host on the internet to our ISP and through the DSL to
our fw/bw box. Because ACK packets generated by hosts 1 & 2
are relatively small they are never queued at flow point
(1) so data flowing from the internet towards hosts 1 & 2
are sharing in equal parts the available DSL bandwidth
(50/50) which is obviously not adhering to our 80/20 rule
for hosts 1 & 2.

Now suppose that we implement the same bandwidth management
rules as in flow point (1) at flow point (3) changing eth0
to eth1 (i.e., the internal interface) and ip_src with
ip_dst (as is been suggested by LARTC). What should happen
(**am I right on this one??**) is that packets traveling
towards host 2 will start to be dropped because host 2 gets
the information at a rate of only 102Kbps so, after an
allowed latency time, the host on the internet which sends
information for our host 2 will slow down eventually to a
rate of 102Kbps. The rest 410Kbps of our DSL line is used
for the information flowing towards our host 1. This should
accomplice our task partially.

What happens if the fw box has also a proxy service running
and some of the information requested by host 2 is already
on the fw box? Then it seems that creating such a low
(512Kbps) ceil on a real 10Mbps internal interface is not
the best approach. Now suppose we create an IMQ interface
at flow point (2) and attach the same disciplines (htb) as
in flow point (1). This should eventually accomplice our
80/20 division of bandwidth but does it really works on the
traffic entering our fw/bw manager box (considering some
latency time for the flows to become stabilized)? It seems
this is the way to go for policing traffic entering our
fw/bw management box but I really need more information on
the subject.

Thank you for your time,
George.

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com