Re: dummy as IMQ replacement

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

jamal wrote:
> On Tue, 2005-02-01 at 09:53, Andy Furniss wrote:
> 
>>jamal wrote: 
>>
>>>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.

> 
> 
>>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 :-)

> 
> 
>>and if it becomes feasable it will probably appear daunting 
>>to do compared with HTB and all the existing docs/scripts.
>>
> 
> 
>>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.

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

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

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

> 
> 
> 
>>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.
>>
> 
> 
> That would be doable. Thanks for taking the time Andy.

Glad I can help.

Andy.


> 
> cheers,
> jamal
> 
>