2009/5/28 SJP Lists <sjp.li...@flashbsd.net>:
> In other words, doing it on the incoming is pointless. Thus, as in
> your examples, the logic behind shaping only on the outbound.
>
> i.e.You can easily delay sending something you have, but you have
> little to no control over the ingress traffic of a link where only the
> local host you have control of.
Partially agree... Shaping incoming packets is useless. But _dropping_
incoming packets (when they reach some rate limit) seemed meaningful.
My opinion is that we can save some power (performance) when we drop
packets early instead of allowing them to go through full stack
(routing, and pf also, as I think).
Just think about DOS. And all interrupts processed on one cpu. They
can put down your machine to it's knees, while others processors will
stay cold.
But as Henning Brauer says: "there is no suitable queue inbound to do
any queueing on. the ipintrq is way too early".
So, if we want to drop packets "early" we must implement some ugly
hacks ("incoming" counters somewhere, partly mirroring ALTQ; and some
hooks needed for they manage).
Is seems that such diff's will never be commited...
Let's see from other side.
What if my machine has 3 or more interfaces - 1st to LAN, 2d and 3d
are my internet uplinks (used simultaneously). One of my clients (in
LAN) pays for 256k/256k "unlim". When I setup ALTQ queues with 256k on
2d interface, and same on 3d interface (client's outgoing...), my
client can achieve 512k upload in some cases: imagine 2 flows - one
flow is from client to somewhere through 2d interface and another flow
is from client to somewhere through 3d interface. That's wrong.
I think that solution can be implemented using "outgoing" queues with
some kind of summary counters (count outgoing packets on all "other"
interfaces but one where packet was received on). Isn't it?
--
antonvm
