jamal wrote:

On Tue, 2005-02-01 at 09:53, Andy Furniss wrote:

quoted

jamal wrote: 

quoted

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 

Close - but you are missing the rate control requirement. 
You can do the above with prio qdisc for example but that does not
equate to shaping. Understood about Lartc users definitions. However,
note that they are influenced by what people tell them or what people
write in docs. Help in making sure the redefinition doesnt propagate.
Theres a very precise meaning to shaping and it is _exactly_ the way i
described it above. Clue people who ask questions.

I see your point.

quoted

and until now were not aware that it was even possible to replicate this 
in policers 

I am sure i have written about 50 emails on this topic over the last 5
years;->  look at the archives. I even joked about it here:
http://www.cyberus.ca/~hadi/patches/action/README over 2 years ago.
look at the text reading "it must be the summer heat again; weve had
someone doing that every year around summer"
Unfortunately people who are writting docs havent picked it up for
whatever reasons. I am hoping we finaly get this documented somewhere.
Can you help fix this?

I could write up some what I did type stuff. Once I work out what to do 
and how to do it :-)

quoted

and if it becomes feasable it will probably appear daunting 
to do compared with HTB and all the existing docs/scripts.

quoted

From a usability perspective i agree with you. 

Its still doable is all i can say ;-> (but you are correct in that it
may not be for the weak hearts)
As a reminder of some of the big discussions on shared and hierachical
policing - look at the many many discussions I had with devik on this
topic a few years back.
It resulted in the birth of HTB (which is essentially a hierachy of the
same token bucket meters used in policers; hierachical shared policers
are doable - look at iproute2/examples/diffserv). HTB otoh has proven
useful due to simplicty - so it stands on its own merit now.
I think there may be peculiar occasions where you may need to have
queues to shape traffic to a local app - but thats peculiar. 

I'll have to read up abit.

quoted

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, 

True - but i question the usefulness of localy terminating TCP packets
being shaped. For packets being forwarded, the shaping happens on
egress.

I know it's a bit odd, but then if I had just one PC I would want to 
rather than police for reasons below.

quoted

which hurts 
latency if you are doing traffic control from the wrong end of the 
bottleneck.

Not sure i followed the latency connection.

I am shaping a relativly slow link from the wrong end. My objective is 
to avoid the 600ms buffer at ISP/Teleco getting filled as it adds 
latency for my interactive traffic. If I have a dozen bulk tcp 
connections running then policing encourages each to send data in bursts 
at link speed, because delayed acks will pair packets and say a group of 
four passes without dropping it causes another group of four from that 
connection at link speed. Add to that the different or variable rtts of 
the 12 connections it means that there will be times when large bunches 
of big packets arrive together and delay the interactive traffic.

If I shape and dequeue each connection round robin and the aggeragate 
rate is below link speed then the aggregate flow is smoothed better. If 
the rates are low enough I will delay longer than delayed ack timers and 
get one packet per ack aswell. It's still not perfect of course.

quoted

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

Great. yes, you can.

quoted

quoted

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.

You can mark in netfilter or even in tc and use those marks in both
places.

Great.

quoted

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

quoted

# 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.

quoted

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.

That would be doable. Thanks for taking the time Andy.

Glad I can help.

Andy.

cheers,
jamal