pfer wrote:
Hi Andy!
I haven't checked the iproute sources for that,
but maybe I was not clear:
What I need is not having ALL packets re-marked when
they are overlimit, or sent to any class, etc..
I want them to be remarked at a ratio. (eg. 2%)
And granularity is important, if I have to re-mark
with
a 20% ratio, I wish to remark every 5th, and not mark
20 continously at not mark other 80 continously.
Hmm with the example you give of 3x10 feeding 1x10 egress I don't see
how it's going to work as is - I googled RMD-QoS-NSLP and have to admit
I know zero about that - so you are alot more qualified than me WRT that.
I can't really do more than list a few thoughts.
What happens if ingress > 2x egress.
You want to mark every nth packet on egress but this will be before the
flooded bottleneck - so you will then have to drop some of them.
The example of 16mbit ingress going to 10mbit egress will not happen for
long if tcp is involved - it will back off.
Relating bandwidth use to packet counting will need the packets to all
be the same size. (maybe doesn't matter for you)
It may be doable - I just don't know and haven't played with actions
enough to answer questions on that.
One thought you could use IFB/IMQ or something to double queue so that
the egress marker sees the traffic already cut down to 10mbit and there
will be no further dropping. You'll still need to use state from ingress
meters - or maybe your code for that.
Thomas Graf wrote ematch which is in kernel (I don't know of any
examples of usage, but the code has comments on how to write your own).
He eventually wanted them to be able to do clever things like use meta
data to control tc/classification I beleive.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
