[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using state and routing inbound traffic



On Fri, Aug 05, 2005 at 08:48:19PM +0000, Karl O. Pinc wrote:
> But all this is already true when you've saturated your WAN
> link so there's no harm in trying to shape the traffic anyway.
Yes, there is the effect of your TCP peer "backing off" (pausing,
retransmitting, using smaller windows, generally "slowing down sending")
when a reply from you is lost (for instance because you dropped it with
a queue).
What I was trying to say is that this effect is not very reliable. For
instance, HOW MUCH slower will the peer send when you drop WHICH
packets?
The queue that is dropping your outgoing packets will have some rule
like "pass at most 128kbps out, drop excess randomly". That doesn't
translate very well to something like "drop just enough outgoing replies
so the peer will backoff and send at most 128kbps back, subsequently".
There is no logic in altq or pf which does any such estimate or
calculation, there is not even a way to somehow connect two queues in a
way that like "start dropping packets from queue A when queue B gets
full", afaik.
So, ignoring the "route through loopback" scheme for now, assuming a
very simple setup with only one internal and one external interface, how
would you configure the queue on the internal interface (dropping
packets coming in on the external interface, getting IP forwarded/routed
to the internal interface, and leaving out there), to get a steady
stream of incoming packets on the external interface of "at most x
kbps"?
Daniel