Damion de Soto <damion@xxxxxxxxxxxx> writes: > Greg, > > For some reason that hadn't occurred to me. That should work just fine. I > > guess I should mark the packets in iptables to avoid throttling traffic from > > gateway itself, or does match see the external ip? > > The only (common) time you need to use iptables to mark traffic, is when > you're using egress qdiscs on your outbound (WAN) interface (to shape upload > speeds) and want to filter based on private (LAN) IP address. Well I'll be doing the opposite here, putting an egress qdisc on my LAN interface limiting the downstream bandwidth. So I would have the equivalent need, to distinguish traffic originating from outside vs traffic originating from the router so I can still scp kernels over to the router without being limited. Hm, though in practice I hardly ever scp things _from_ the router so perhaps I don't care. > > IMQ does seem like a handy tool, but why is there a distinction at all between > > egress and ingress qdiscs at all? Why not just allow people to attach HTB as > > an ingress qdisc directly? > > because you can't shape inbound traffic. Shaping works by delaying the > transmission, and you can't delay packets that haven't arrived yet. Ingress > policing just drops packets, and hopes the sender will slow down. Well ultimately all shaping works by dropping packets. Merely delaying transmission isn't going to slow down anything in the long run, just increase the pipeline. You can delay and/or drop them after they've arrived just as easily. Though it would have to be before they're ack'd and delivered to the user. That's basically what IMQ does, I'm just saying perhaps that should just work instead of requiring a fake interface. Hm, I wonder if I want RED or something similar to ensure packets get dropped fast enough instead of filling HTB queues and then dropping. > > I suppose in an ideal world the best thing would be to receive the packets, > > hand them to user-space, but not mark them as received, ie, not ack them. That > > avoids introducing any loss from the user point of view but still slows the > > flow down. But that seems fiddly and would only work for TCP I guess. > > That's an interesting idea, but yeah... i think it might be a bit hard to > implement, and violate far too many RFCs... My original thought was to just drop an ACK packet, which would clearly not violate any assumptions. But if there's data in the ACK packet that could have negative effects. I suspect this lies well into Bad Idea(tm) realm, I'm just thinking out loud. -- greg _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
