Message from discussion
PF inadequacy: queue download
Path: g2news2.google.com!news1.google.com!atl-c05.usenetserver.com!news.usenetserver.com!news-out.octanews.net!teal.octanews.net!newsfeed2.telusplanet.net!newsfeed.telus.net!edtnps82.POSTED!53ab2750!not-for-mail
Newsgroups: comp.unix.bsd.openbsd.misc
From: Steven Schneider <steven_schnei...@telus.net>
Subject: Re: PF inadequacy: queue download
References: <1146315891.156700.262960@j73g2000cwa.googlegroups.com>
Organization: Just a Guy and His Family
X-No-Alan-Connor: Yes
X-Operating-System: OpenBSD 3.9
X-Crypto: GnuPG http://www.gnupg.org/
X-GnuPG-Expiry-Date: 09 October 2007
X-GnuPG-ID: 0x4A330D06
X-GnuPG-Fingerprint: 4AB5 8738 DC7B AAE8 3795 6285 D549 80A2 4A33 0D06
X-Signature-Color: magenta black
Message-ID: <slrne5758h.eb6.steven_schneider@gemini.wss-ds.org>
User-Agent: slrn/0.9.8.1 (OpenBSD)
Lines: 59
Date: Sat, 29 Apr 2006 16:32:17 GMT
NNTP-Posting-Host: 198.166.227.91
X-Trace: edtnps82 1146328337 198.166.227.91 (Sat, 29 Apr 2006 10:32:17 MDT)
NNTP-Posting-Date: Sat, 29 Apr 2006 10:32:17 MDT
* kestas....@gmail.com <kestas....@gmail.com> [2006-04-29]:
> Why can't you queue download traffic on an interface? The reason
> openbsd.org's FAQ gives is:
>
> "Note that queueing is only useful for packets in the outbound
> direction. Once a packet arrives on an interface in the inbound
> direction it's already too late to queue it -- it's already consumed
> network bandwidth to get to the interface that just received it. The
> only solution is to enable queueing on the adjacent router or, if the
> host that received the packet is acting as a router, to enable queueing
> on the internal interface where packets exit the router."
>
> But this is wrong. It's not too late to queue it; by queueing it and
> dropping some packets of inbound traffic the sending host slows down
> the speed at which it sends.
>
Are you sure about that? Perhaps a well behaved sending host
would, but what if it isn't? Also, if you're being DDOSd, will
this even matter?
> Shaping NAT traffic downloads works fine with this hack, but I also run
> some services on the external interface. With downloads queued on the
> internal interface there's no way to queue the services' download
> traffic, which means an external service can hog up all the bandwidth
> and I can't do anything.
>
I haven't heard of any firewall that successfully could. If you're
being DDOSd, you're being DDOSd. No firewall with any special set
of rules can improve your bandwidth in that case. If the pipe is
filled, it's filled.
>
> I know this is possible because IPFW with dummynet doesn't have any
> problems.
I don't use IPFW, so I can't speak on its specific technical merits.
Maybe you should ask the IPFW devs how they're able to perform this
magic. Last I heard, the PF devs were technicians, engineers, and
scientists, not a single magic-user among them. (IRL anyhow. :-))
If everyone loves PF because of its elegance why can't it do
> something as simple as queue download traffic?
>
I think that you _can_ configure PF to do this, but I believe that
what the developers are trying to say is, `What's the point'? We're
talking about trying to control traffic _before_ it hits your
interface. Even if the remote sending host is well-behaved enough
to slow down its sending rate, it still has to interact with PF
before PF can decide whether to pass the packets, drop the packets,
or tell the sending host to `bugger off'.
So, you can queue the download traffic, but that really has a minor
to no effect on traffic outside of your firewall. The queuing
actually occurs on _your_ side of the external interface.
My $0.02 CDN. Take it for what it's worth, or exchange it for
better currency. :-)
--
W. Steven Schneider <steven_schnei...@telus.net>
|
