[Click] 'adaptive' QoS

[Thomer M. Gil]

I'll answer my own question.

The answer---original question at the bottom of this email---is yes,
using Queues, RatedUnqueues, Counters, and a user-level program.

Packets get dumped in different queues based on how 'important' they are
to me.  A user-level program continuously checks the packet rates using
the Counter elements and can adjust the rate of the RatedUnqueue
elements.  The not so important traffic gets free reign as long as no
other traffic is present.  As soon as there is other, more important
traffic, the rate of the appropriate RatedUnqueue elements is adjusted
by poking the rate handler.

I'm still curious to hear better ideas.

Thanks,

Thomer

> My setup at home is: internal network <-> NAT <-> outside world.
> Click is running on the NAT box and I have a DSL link to the outside
> world.  I want to implement 'adaptive  QoS', i.e., I want to allow
> Application One (running on the NAT itself) to saturate my upload and
> download link, but as soon as Application Two (running on the internal
> network) starts to send/receive traffic through the NAT, Application
> One's traffic should yield, even if that means starving Application
> One completely.
> 
> Both Application One and Two use TCP and let's assume I can
> differentiate them by port number.  Obviously, the NAT sees all
> packets going to and coming from the internal network for Application
> Two, but I don't think I can make Click see the packets that
> Application One is sending OUT, but of course I do see the packets
> going TO it.
> 
> My first (failed) approach was two Queues and a PrioSched element.
> But that didn't work.  The end result (how fast is Application Two?)
> was basically the same as before.
> 
> Is there a set of elements that allow me to do this, even if that
> means writing a user-level program that peaks and pokes handlers
> continuously, or even hotswaps new configs?