Re: dummy as IMQ replacement

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

Thomas Graf wrote:
>>>> X =  ----------------------------------------------------------
>>>>      R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2)))
>>>>
>>>>Where:
>>>>
>>>>    X is the transmit rate in bytes/second.
>>>>    s is the packet size in bytes.
>>>>    R is the round trip time in seconds.
>>>>    p is the loss event rate, between 0 and 1.0, of the number of loss
>>>>      events as a fraction of the number of packets transmitted.
>>>>    t_RTO is the TCP retransmission timeout value in seconds.
>>>>    b is the number of packets acknowledged by a single TCP
>>>>      acknowledgement.
>>
>>WRT policers I never figured out where you would put the effects of 
>>playing with the burst size parameter and it's effects with few/many 
>>connections and any burstiness caused into an equasion like that.
> 
> 
> A burst buffer has impact on R on later packets, it can "smooth" R
> and X and thus results in more stable rates. Depending on the actual
> burst, it can avoid retransmits which stabilizes the rate as well.

But it's not a real rate limiting buffer in the policer case is it?

> 
> 
>>This sounds cool. For me in someways I think it could be nicer (in the 
>>case of shaping from the wrong end of a slow link) to delay the real 
>>packets - that way the tcps of the clients get to see the smoothed 
>>version of the traffic and you can delay udp aswell.
> 
> 
> It's impossible to never drop anything, for udp we can either drop
> it or use ECN and hope the other ip stack takes care of it or the
> application implements its own cc algorithm. Basically you can already
> do that with (G)RED. Most UDP users which provide a continous stream
> such as video streams, implement some kind of key datagram which contains
> the number of datagrams received since the last key datagram and the
> application throttles down based on that so dropping is often the only
> way to achieve a general working solution. Delaying UDP packets and
> then drop them if the buffer is full is very dangerous, often the
> protocols based on UDP rely on the assumption that datagrams get lost
> randomly and not succcessive. We can think about precicse policing
> for UDP again once the current poor application level cc algorithms
> have failed and the industry accepted ECN as the right thing. For
> now most of them still suffer from the NIH syndrom in this area.

Interesting stuff. I was thinking of game udp where just dropping would 
simulate what the user should have done anyway, but costing you 
bandwidth. If alot of gamers share a slow link then if you lag them out 
they know it's time to turn the rate down.

> 
> 
>>How intelligent and how much, if any, per connection state do you/could 
>>you keep?
> 
> 
> I keep a rate estimator for every flow on ingress in a hash table and
> lookup it up on egress with the flow parameters reversed. It gets
> pretty expensive on huge amounts of connection usually one doesn't
> want to do per connection policing on such boxes. ;->
> 

Nice - are you planning to add anything to tweak things for the wrong 
end of the bottleneck problems?

Andy.