Message from discussion PF inadequacy: queue download

Path: g2news2.google.com!news1.google.com!news3.google.com!newsfeed.stanford.edu!pln-w!spln!lex!newsgate.newsguy.com!newsp.newsguy.com!mdrn
From: cana...@eee.metu.edu.tr (Can Erkin Acar)
Newsgroups: bit.listserv.openbsd-pf
Subject: Re: PF inadequacy: queue download
Date: 1 May 2006 12:06:40 -0700
Organization: None
Lines: 53
Message-ID: <20060501172250.GA14246@ee.eee.metu.edu.tr>
References: <1146315947.065791.306090@i40g2000cwc.googlegroups.com> <1146410571.844098.303650@e56g2000cwe.googlegroups.com>
NNTP-Posting-Host: localhost.newsguy.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
NNTP-Posting-Date: 1 May 2006 19:06:40 GMT

On Sun, Apr 30, 2006 at 08:22:51AM -0700, kestas....@gmail.com wrote:
> I don't think time spent developing PF or ALTQ could be better spent
> developing something other than download queueing. Everyone here seems
> to agree it's PF's worst deficiency.

Intresting definition for "Everyone". It seems the definition does not
include the developers.

If you can not live without "download queueing" you can always:

1. Write and submit a patch
2. Fund a developer to do the work for you.
3. Go run something else.

I guess you would get bored after a while and choose #3.
Feel free to surprise me though.

Note that "unending trolling on the mailing lists"  
> I'm thinking perhaps there's some messy hack I can come up with using
> virtual interfaces, does anyone have any ideas?

Not that I know of.

> > and there are 'lots of people' that care deeply about this
> I said lots of people *here*, and there aren't close to 40 here, and
> $500 is very steep for an extra box which has to do so little, and this
> wouldn't require a whole hackathon to code. I'm not sure why you're
> being so resistant to a feature request.

This might surprise you but OpenBSD does not run on requests, or polls
or democracy. If a developer feels that such a feature is intresting/important
and have resources to spare, than the feature will be implemented.

The best way to get results is to 'shut up and code'.

> > By all means, try it. There are more readers (and developers) on the misc@ and tech@ lists, so I'd start there.
> I posted in misc, but no-one was biting, and I've just sent one to
> tech.
> 
> > Stock altq could put token buckets on input interfaces for rate
> > limiting purposes, referred to as the "traffic conditioner" (CDNR).
> > That capability was removed when the classifier was merged with pf.
> >
> > Old messages that might be relevant:
> > http://www.benzedrine.cx/pf/msg02871.html
> > http://www.benzedrine.cx/pf/msg07159.html (bottom)
> Interesting, I wonder how difficult it would be to get the
> functionality back. Any ideas on why it was dropped in the first place?

Input condititioners are different from queues. You would *not* have the
same amount of control over the traffic as you would have when using a separate box.

Can