Re: dummy as IMQ replacement

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

jamal wrote:
> On Mon, 2005-01-31 at 17:39, Andy Furniss wrote:
> 
>>Jamal Hadi Salim wrote:
> 
> 
>>>2) Allows for queueing incoming traffic for shaping instead of
>>>dropping. I am not aware of any study that shows policing is 
>>>worse than shaping in achieving the end goal of rate control.
>>
>>I would say the end goal is shaping not just rate control. Shaping 
>>meaning different things to different people and ingress shaping being 
>>different from egress.
> 
> 
> I know for a while the Bart howto was mislabeling the meaning of
> policing - not sure about shaping. 
> Shaping has a precise definition that involves a queue and a
> non-working-conserving scheduler in order to rate control. This doesnt
> matter where it happens (egress or ingress). Policing on the other hand
> is work conserving etc.

Ok, but shaping to LARTC posters means being able to classify traffic 
and set up sharing/priorotising of classes. This is the reason most need 
to be able to queue - they want to use htb/hfsc for complicated setups 
and until now were not aware that it was even possible to replicate this 
in policers and if it becomes feasable it will probably appear daunting 
to do compared with HTB and all the existing docs/scripts.

For me, I think queuing and dropping is better than just dropping, you 
can affect tcp by delaying eg. 1 ack per packet rather than delayed acks 
and clocking out the packets helps smooth burstiness, which hurts 
latency if you are doing traffic control from the wrong end of the 
bottleneck.

> 
>>For me it's from the wrong end of a relativly narrow (512kbit) 
>>bottleneck link that has a 600ms fifo at the other end. My aim to 
>>sacrifice as little bandwidth as possible while not adding latency 
>>bursts for gaming and per user bandwidth allocation (with sharing of 
>>unused) and sfq within that for bulk tcp traffic.
>>
>>If I was shaping LAN traffic, then policers/drops would be OK for me - 
>>but for a slow link I think queueing and dropping are better/give more 
>>control eg. I get to use sfq which should not drop the one packet a 56k 
>>user has managed to send me in the face of lots of incoming from low 
>>latency high bandwidth servers.
>>
>>Even if it's possible I bet few can easily get policers to setup the 
>>complex sharing/prioritisations that you can with HTB or HFSC.
> 
> 
> sfq has a built in classifier that can efficiently separate those
> flows so you can achieve semi-fairness; so its not the shaping perse
> that helps, rather you ended up using a clever scheme that can isolate
> flows and benefited from shaping as a result; the hashing function
> should prove weak when a lot of flows start showing up.
> You could write some interesting classifier (as an example steal the one
> that sfq has) and achieve the same end results with policing. This would
> be easier now with ematches .. 

The idea of loosing the s from sfq and doing multilevel hash/mapping is 
attractive - of course I would want to queue each flow and have the 
queue be variable length for each flow depending on occupancy of other 
flows. I suppose a per flow intelligent dropping scheme would be even 
better. It would be nice to be able to set/control queuelength for link 
bandwidth, nothing classful in linux tc does this.


> 
> 
>>>But i wont go back to putting netfilter hooks in the device to satisfy
>>>this.  I also dont think its worth it hacking dummy some more to be 
>>>aware of say L3 info and play ip rule tricks to achieve this.
>>>--> Instead the plan is to have a contrack related action. This action
>>>will selectively either query/create contrack state on incoming packets.
>>
>>I don't understand exactly what you mean here - for my setup to work I 
>>need to see denatted addresses and mark (connbytes - it helps me be 
>>extra nasty to multiple simoultaneous connections in slowstart and 
>>prioritise browsing over bulk) in prerouting mangle. Of course if I can 
>>use netfilter to classify and save into contrack then I could do 
>>evrything in netfilter and then use something like connmark to save it 
>>per connection.
>>
> 
> 
> You may be refering to requirement #3 then? 
> In other words what you are doing is best served by knowing the state?

As long as I could use netfilter to mark/classify connections then I 
think I can sort my setup, don't know about others.


> Are pre/post routing sufficient as netfilter hooks for your case?

Yes but depends on where in pre/postrouting. For me after/before nat, as 
I say above though I could workaround if I classify connections with 
netfilter. For others as long as they can filter on a mark/classify set 
in forward, then I think it will be OK for them.

> 
> 
>>>Packets could then be redirected to dummy based on what happens -> eg 
>>>on incoming packets; if we find they are of known state we could send to
>>>a different queue than one which didnt have existing state. This
>>>all however is dependent on whatever rules the admin enters.
>>
>>
>>How does the admin enter the rules - netfilter or other?
>>
>  
> Just like i showed in that post (It was long - so dont wanna cutnpaste
> here).
> 

I am not sure what exactly can can't be done in your example:



 ># redirect all IP packets arriving in eth0 to dummy0
 ># use mark 1 --> puts them onto class 1:1
 >$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
 >match u32 0 0 flowid 1:1 \

What I can do here depends where it hooks packets.

 >action ipt -j MARK --set-mark 1 \

I don't know what table I am using - may be OK as long as I can test for 
a mark I made earlier in the egress dummy case or test connmark/state I 
set for that connection in the ingress case.

 >action mirred egress redirect dev dummy0

Andy.


> cheers,
> jamal
> 
>