Jason Boxman <jasonb@xxxxxxxxxx> 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.
Eventually in the egress case either you will run out of buffer and drop, or your queue is big enough for the advertised window (say 32k-64k) and tcp will only add a packet for everyone acked - you decide when the packets go so you have good control. If you drop, the sender reduces it's cwin and only slowly tries to increase until another drop.
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.
Once you have dropped the rate you release packets does controll the flow and if it's slow the cwin will only grow slowly as it's clocked by acks (I think).
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.
I think what Jason was getting at is that on egress you have total control - it doesn't matter what TCP does.
Ingress shaping is harder as packets are already headed for you - in the case of P2P possibly quite alot - it's easier to shape when peering with "real" servers. Though in both cases, the fact that TCP slow (but sort of exponential) start overshoots bandwidth hurts ingress shaping, but not egress.
Andy.
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.
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
