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

[Jason Boxman <jasonb@edseek.com>]

On Tuesday 08 June 2004 23:33, Greg Stark wrote:
> Damion de Soto <damion@snapgear.com> writes:
<snip>
> >
> > 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.

Ultimately, packets from a misbehaving flow can be dropped, but it does not 
always come to a drop.  When you shape on egress, you force applications on 
the local network to throttle back, believing they're sending as fast as the 
receiver can receive.  As you delay, TCP figures it out.  Contrast that with 
ingress, where the packets you want to delay are already on their way.

> 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.

If you're curious about RED, here's a possible example implementation for 
ingress policing:

http://digriz.org.uk/jdg-qos-script/

<snip>

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/