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

[Greg Stark <gsstark@mit.edu>]

Jason Boxman <jasonb@edseek.com> writes:

> On Tuesday 08 June 2004 23:33, Greg Stark wrote:
> >
> > 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.  

I don't think so. It may look like that's what's happening, but at least for
TCP I don't think it works that way. As long as packets aren't being dropped
then TCP will just continue to grow the window, interpreting this delay as
just a longer pipeline that needs filling. Applications will be slowed down
temporarily because it takes time to do this, but they'll eventually be
outputting data just as fast as an application without a shaper.

Only when packets get dropped or are delayed so long that the client
retransmits does TCP scale back the transmit window. And only when that
happens does the client see any reduced bandwidth. So if your shaper isn't
dropping packets it's just evening out the flow of data, not actually
affecting the net rate the clients can pump out data.

> Contrast that with ingress, where the packets you want to delay are already
> on their way.

Well on egress the packets are "already on their way" as well, after all.
They're just haven't gone as many hops. Even for locally generated traffic the
egress qdisc is being run after the data packetized and ready to go.

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

This is an interesting script. It looks like a successor to wondershaper. But
I'm a bit too deep in my own re-implementation of wondershaper now to start
over.

-- 
greg

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