[Click] How to implement variable number of input queues for roundrobin scheduler?

[Cliff Frey]

If you do not require completely exact behavior, you can do something where
you just use hashing and a fixed number of Queues.

elementclass SuperQueue {
  input -> hs :: HashSwitch(16, 4);
  rrs :: RoundRobinSched -> output;

  hs [0] -> Queue -> [0] rrs;
  hs [1] -> Queue -> [1] rrs;
  hs [2] -> Queue -> [2] rrs;
  hs [3] -> Queue -> [3] rrs;
}

Would give you something approximating fairness between destination IPs.
You could use more than 4 Queues if you wanted more fairness.  You could
even go one step more and make HashSwitch be able to change hashing
functions, and have a Script element that changed the HashSwitch's function
every few seconds.

Cliff

On Tue, Apr 14, 2009 at 8:02 AM, Bart Braem <bart.braem at ua.ac.be> wrote:

> Hi,
>
> On 11 Mar 2009, at 00:22, Ashish Sharma wrote:
>
> > I am interested in a scheme that allows round robin transmission of
> > packets
> > for each outgoing destination ip. The problem is that the number of
> > destination hosts cannot be known pre-hand. So is there a way to
> > dynamically
> > create a new queue for each destination host (thereby queueing all
> > packets
> > to that host in a separate destination queue), and then link the
> > output to
> > the round-robin scheduler which now includes this new queue in its
> > schedule?
> >
> > I am thinking of wrapper queue element that internally maintains a
> > dynamic
> > set of notifier_queues and for each pull call, dequeues packets from
> > an
> > internal queue in sequence. But the solution seems a bit messy
> > because of
> > empty_queue active notifiers management.
> >
> > Could someone comment on this approach or suggest an alternative
> > one? I am
> > wondering if this could be done using the Script element, but I am
> > less than
> > familiar with Script. Any ideas/help would be greatly appreciated.
>
>
> We have thought about this problem too and it does not seem easy to
> solve. Implementing a variable (part of the) Click graph seems very
> hard, as all optimizations and inner logic is based on fixed graphs.
> The classical tricks with painting packets do not work if paths are
> very dynamic.
> Does anyone else have thoughts about this? How do you manage similar
> problems, apart from having a SuperQueue element?
>
> Regards,
> Bart Braem
> --
> Bart Braem
> PATS research group - IBBT
> Dept. of Mathematics and Computer Sciences
> University of Antwerp
> Campus Middelheim, G3.30
> Middelheimlaan 1
> B-2020 Antwerpen, Belgium
> Phone: +32 (0)3 265.32.91
> Fax: +32 (0)3 265.37.77
> Web: www.pats.ua.ac.be
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>