:There is a WFQ discipline for ALTQ: 
:http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/altq/ altq_wfq.{h,c}
:
:It has never been integrated with pf, but I think using your approach of 
:passing a hash in the pkthdr this should be rather straight forward.

    Ah, there we go.  Wow, way back in 1997.  The core of that code is
    definitely fair-queue.  I'm not sure what they are doing at the top
    level, though, I don't see any prioritization or bandwidth control.
    There's a queue->quota and a queue->weight that looks like it has
    been partially coded but not finished.  They are using a list of queues
    instead of an array which I think is somewhat superior to what I'm
    doing (bitmap of active queues with an iterator), but I think my
    bandwidth and prioritization algorithm is a bit more advanced.

    One thing I can theorize would be beneficial would be to record the
    bandwidth being used by each sub-queue and then allow low bandwidth queues
    to 'burst' data by moving the queue to the head of the list if it is
    recognized as having low bandwidth and is otherwise empty.  To prevent
    starvation from having many low bw connections you'd keep another
    counter which is reset when the round-robin encounters the queue normally
    without it having been moved.

    So, e.g.  if you do a 'pounding the keyboard' test on an interactive
    connection you would get interactive response.  Right now with my
    implementation if you pound the keyboard you get intermediate
    responsiveness because the round-robin has to cycle around to that
    queue before the packet gets sent.  Maybe that is what they were trying
    to control with the weighting variable.

    I am going to research it a bit more.  I kinda like my base better (well,
    that's no surprise), but the list of queues approach WFQ takes has a lot
    more flexibility.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>