[LARTC] Problems with policing

[Thomas Heinz <josef.k@mytomorrow.de>]

Hi

I'm pretty new to this traffic control stuff but I find it very amazing. I read
the howto and experimented a little with the "ultimate" traffic conditioner.

My focus was on policing not shaping. In the script the following two lines
are responsible for that.

tc qdisc add dev $DEV handle ffff: ingress
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
    0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

I set DOWNLINK a lot below the real downstream bandwidth of my internet
connection and started several downloads (tcp). I measured the current
incoming traffic with iptraf and everything seems fine. The packets were
dropped so that my incoming traffic was below DOWNLINK (at least most
of the time).

After that I used iperf to generate a lot of incoming udp traffic and
it got through! The policing didn't drop the packets. How can this be?

By the way I'm using 2.4.16 with the htb patch, h323/newnat (netfilter),
freeswan 1.92 and several pending netfilter patches.
In userland I use the tc binary from http://luxik.cdi.cz/~devik/qos/htb/

Another problem was that tc -s qdisc show
always answers with:

  qdisc ingress ffff: dev ppp0
  Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

This seems to be a known problem according to some postings of this list. Is it
just a "cosmetical" problem? After all at least some tcp packets were dropped
according to the policing rules.

Unfortunately the howto doesn't go very deeply in this policing matter.
Therefore I have a question or two :-)

1) Chapter 12.3 of the howto says that there are two ways to police: either
    using kernel estimator or token bucket filter.
    The policing rule in the script makes use of tbf. How can I use kernel
    estimator and what is preferable?

2) There are four overlimit actions: continue, drop, pass/OK and reclassify.
    What exactly is the difference between continue, pass/OK and reclassify and
    how do they fit in the tc syntax?

3) Consider the following scenario (only downstream is considered).
    I want to prevent queues outside my linux box. I never want to drop incoming
    ssh (not scp) connections and incoming udp traffic (h323 for example).
    Everything else can be dropped in order let the incoming traffic stay below a
    certain bound.
    For example: The downstream bandwidth is 100KByte/sec. All incoming ssh and
    upd connections consume <= 20 KByte/sec (this has not to be assured by the
    tc filters, it's simply assumed). Now the overall traffic (including the
    ssh and upd connections) should always stay below 95KByte/sec in order to
    prevent external queueing.
    How can this be achieved and does it make sense to use policing that way?


I appreciate any help on this topic. Thanks for your time and concern.


Thomas


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/