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
