jamal wrote:

On Mon, 2005-01-31 at 17:39, Andy Furniss wrote:

quoted

Jamal Hadi Salim wrote:

quoted

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

quoted

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