PF inadequacy: queue download - comp.unix.bsd.openbsd.misc

Message from discussion PF inadequacy: queue download

Steven Schneider

View profile

More options Apr 30 2006, 2:32 am

Newsgroups: comp.unix.bsd.openbsd.misc

From: Steven Schneider <steven_schnei...@telus.net>

Date: Sat, 29 Apr 2006 16:32:17 GMT

Local: Sun, Apr 30 2006 2:32 am

Subject: Re: PF inadequacy: queue download

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

* 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>

Reply to author Forward