Hello!
Well I won't go into protocol details, but
I do not care if an intra-domain node will be
congested via packets on ingress. I will drop them,
but check with "tc .. show .." how much I get on
byte-level. Based on this, and maximum egress
transmission rate of this congested node, I calculate
Overload%, and remark leaving packets at that ratio.
Anyway this setup will serve as a demo, having
reservations thoughout the domain for UDP video packet
streams only.
I wrote to netdev-linux mailing list about how to hack
in the sources of tc something like:
for every packet
if(rand()<(percent/100))
do_action
,where rand() gives a float of 0..1
but haven't got any answer yet.
I'm pretty much confused where an "action" gets
executed, and how for.ex. "random determ 2" modifies
that.
I will check this ematch stuff, but doesn't sound me
the solution. I just thought this ratio-marking stuff
to be a little less exotic and people already doing
it.
Could you point me to someone who will probably help
me with this?
Thanks,
Ferenc
--- Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote:
> 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.
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
