A proposal for the improvement of the delay pools

Hello everyone.

I'll soon need to implement bandwidth control at my organization, and
so I finally gave an in-depth look at delay pools. While they'll be
sufficient at the beginning, they could be vastly improved with (I
hope) a not-too-vast effort.

Here is a modest proposal on how they could be improved. I won't start
coding right away on this, but it might be my next project. Notice,
there might be gross inaccuracies in the presented facts since I
haven't looked at the code in-depth, just a cursory glance.

SPECS
=====

1)
There should be two types of pools: "simple" delay pools and
"class" delay pools.
The former should be a single pool of a given depth, fill rate and
initial fill. The latter should be a group of pools that depend on
some requests' attribute, such as the source IP, destination IP or
authenticated username. All pools in the class should have the same
parameters. When a request comes in, the defining parameter is matched
against already-defined pools in the class. If a pool is found, the
request is subject to it. If not, a new "simple" pool is defined and
initialized and the request is made subject to it.

2)
Pool definition and request assignment should be separate. A pool
should be identified by an unique name.

3)
Pools are assigned to requests by ACL matches. Since inaccuracies are
acceptable in bandwidth management, fast acl matches can be used thus
avoiding to impact request processing flow

4)
A request can be impacted by many different pools. If so, the
bandwitdh it gets assigned is the least of all the pools it must
obey. The bandwidth it uses is subtracted by all the pools it is
subject to.

5)
Bandwidth management need not be very strict. Granted bandwidth
packets could be so arranged:
pool <= 0: grant 0 and wait
pool > 0: grant a minimum value (i.e. 1 Kb) for network efficiency
        reasons, and cause pool to go sub-zero
pool > minimal packet: grant whatever available.

CONFIGURATION
=============

Configuration format and parameters which match the specs could be:

-delay_pool pool_name depth fill_rate initial_fill

defines a new pool and assigns parameters to it

-delay_pool_class pool_name by_attribute depth fill_rate initial_fill

defines a new pool class. The namespace is shared by the simple and
class delay pools by_attribute can be one of "by_src", "by_user",
"by_dst", "by_dstdomain", "by_dstregexp" etc. Attributes can initially
be a subset of the acl types, and expand as development proceeds.

-delay_pool_assign pool_name acl [acl ...]

Assigns a request matching ALL the mentioned ACLs to a given delay
pool. All conditions are evaluated for each request
enable assigning a request to multiple pools.

IMPLEMENTATION
==============

simple delay pools could come for free or almost. Only caveat is that
they should be refcounted to correctly handle pools undefined on
reconfiguration.

class delay pools are quite more complex, but should be rather
modular. Optimization could lead to lots of differences in
implementation of the locator algorithms for the different pool
defining attributes. Those pools should obviously also be refcounted,
and pose two extra issues: garbage collection and reconfiguration. A
pool in a class can be garbage-collected when it's completely filled
and it's not referenced by any active connection. Reconfiguration
could be handled by moving all active pools to a "temporary" and
undifferentiated storage area where they'll be garbage-collected when
their refcount goes to 0.

The request flow path should be altered to match acls and to determine
what pools it must be subject to. A request should contain a list of
pointers to pools it's subject to and take care to properly refcount
them. When sending data it should scan the pools list twice: one to
discover what is the bandwidth it has available, and another to
adjourn the pools' contents.

Ideas? Thoughts? Am I just on too much wine?

-- 
     /kinkie (kinkie [at] tiscalinet [dot] it)
Random fortune, unrelated from the message above:
I met a wonderful new man.  He's fictional, but you can't have everything.
		-- Cecelia, "The Purple Rose of Cairo"