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

[Andy Furniss <andy.furniss@dsl.pipex.com>]

Greg Stark wrote:
> 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.

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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/