[LARTC] Re: how flexible is ingress traffic policing to bandwidth limit?

[Greg Stark <gsstark@mit.edu>]

Damion de Soto <damion@snapgear.com> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/