[Click] 'adaptive' QoS

[Giorgio Calarco]

hi,

I'm not sure if I have understood your problem completely,
but I think we had the similar problem of modulating the aggregated
bandwidth of a service class (real time traffic) which
we have solved in this way:

http://www3.deis.unibo.it/Staff/TechAdm/GCalarco/icn04.pdf


That is, we have introduced in the click configuration a dummy
source of packets (a TimedSource element) to stimulate
synchronous time-window bandwidth measurements (see fig,4).
Then, to avoid sudden queues congestion,
we have more recently modified the "metershaper" element
described in the paper to make a "context flow"
discovering of the upstream queues to keep them monitored.
Depending of the queues state, the shaper capacity is enlarged or
restricted to optimize the efficiency in the bandwidth usage.


Thus, in general, contex-flow Click mechanism  allows you to insert your own
element
inside the click config to discover and read/write other elements handlers,
instead of
using a user-level daemon to do the job. If such a check must be
syncronuos, you can use a dummy source of packets to stimulate the process.

Hope this can help or give you new ideas


ciao
giorgio





----- Original Message ----- 
From: "Thomer M. Gil" <click at thomer.com>
To: "Thomer M. Gil" <click at thomer.com>
Cc: <click at amsterdam.lcs.mit.edu>
Sent: Sunday, August 22, 2004 12:27 AM
Subject: Re: [Click] 'adaptive' QoS


> 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?
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click