The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
Newsgroups: comp.unix.bsd.openbsd.misc
From: Marco S Hyman <m...@snafu.org>
Date: 30 Apr 2006 14:39:02 -0700
Local: Mon, May 1 2006 7:39 am
Subject: Re: PF inadequacy: queue download
kestas....@gmail.com writes: No, there is plenty of good reason to not do so. Spending extra > Thanks for the help, but I still don't think you understand. This isn't > a limitation in my understanding of PF and ALTQ, this is a limitation > of PF and ALTQ itself; you cannot shape traffic coming in on an > interface. There's no good reason why you shouldn't be able to do this. processor cycles queuing (i.e. delaying) packets that have already been received, e.g. have already used network bandwidth, is not a good thing. What you are asking is "please make my network slower so well-behaved peers will throttle their long lived TCP connections" The cost of doing that will slow *everything else* down, too. It buys you nothing with UDP, ICMP, and mis-behaved TCP hosts (of which there are all too many). It exacerbates DOS scenarios. It makes things like popular web servers slower -- http requests are too short lived to get much benefit from TCP congestion control. > I want to know how I can get this added to a todo list, everyone who Since you appear to be the only person who is eager to slow down your > has a firm grasp of PF and ALTQ, and isn't a zealot, agrees that this > is an important feature which PF lacks, and should be implemented asap. network processing for minimal benefit (if any at all) you will probably have to do the work yourself. // marc You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| ||||||||||||||