"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.

I'm using pf to do NAT on my box, and I can shape download traffic
using the 'queueing on the internal interface' hack; so why can't I do
it elegantly on one interface?
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 know this is possible because IPFW with dummynet doesn't have any
problems. If everyone loves PF because of its elegance why can't it do
something as simple as queue download traffic?

Regards,
Kestas