[LARTC] RE: packet marking: only a ratio, not all

[LARTC] RE: packet marking: only a ratio, not all

[pfer]

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.

(
Why I need this:
A protocol (RMD-QoS-NSLP) I want to implement has this
syntax to signal if a link is congested to some edge
nodes at the border of a domain.
)

Do you have a solution for this? I believe what you
suggested is not this, is it?

And I already found a 'somewhat' solution: 

filter actions

See my mail with subject: 
"action pass random determ/netrand reclassify
-value-": granularity problems

With:

tc filter add dev eth0 parent X protocol ip prio Y u32
match ip src 0/0 flowid Z action continue random
determ pass 5

I believe I am able to send every 5th package to class
Z (for remarking with dsmark) and the other 4/5 to the
next filter (with continue), which can send the packet
to the link.

This results in marking 20% of all the packets this
interface gets (via u32 match ip src 0/0).

Do you think this works? I still have not tried.
I believe "continue" gives the packet to the next
filter (order determined by filter command sequence)
and "pass" gives it to the "flowid Z".

Or, does "pass" actually sends the packet to the wire?


Thanks for the info,

Ferenc

--- Andy Furniss <andy.furniss@dsl.pipex.com> wrote:

> pfer wrote:
> > Hi all!
> >  
> >  In short: 
> >  
> >  Anybody wrote a patch for DSMARK to make it
> capable of marking
> >  only a ratio (a given arg to the tc command) of
> the packets it gets?
> >  Say, 20%? Or, do I have to hack into the source?
> Alternatives,
> >  like a filter spitting packets to 2 different
> DSMARK based on this ratio?
> >  
> >  In long:
> >  
> >  I'm a hungarian univ student involved in a
> project (RMD-QoS stuff)
> >  which needs the following:
> >  
> >   \                    This node has 3 ingress and
> 1 egress link, all have for ex. 10 Mbit
> >     \                  limit to their traffic.
> >       \
> >    ---  node -----  Suppose ingress traffic is: 8
> + 3 +5 = 16 while the egress
> >      /                 link will be congested with
> 10. Because this node is a simple,
> >    /                   intradomain router, we
> would like to notify the downstream 
> >  /                    edge node about this
> congestion, to tear down some of the flows
> >                       causing it. (Congestion
> occured via for. ex. a net failure)
> >  
> >  What the protocol (draft) says, is that the edge
> will be notified of the level of the congestion,
> which will be calculated by this proportional data
> packet marking method, to avoid additional
> signaling.
> >  Say, if 16 would go on a link with 10 capacity,
> congested core-node will mark
> >  60% of the packets it sends to the output of the
> link to another DSCP.
> >  
> >  I thought about DSMARK first, but that is
> incapable of doing this stuff.
> >  (or I think so :)
> >  Ideas?
> >  
> >  PS: I did not check the archives rigorously, so
> sorry if I am asking trivial things.
> >  
> >  PS2: Since I checked not to get mails from this
> list, please send your answer
> >  to forgamedev@yahoo.com.
> 
> I am not sure I get the logic of what you are trying
> to do for this 
> paticular setup, but there are examples of using
> policers with meters 
> shared across ingress links to dsmark overlimits
> packets in the iproute2 
> sources.
> 
> Andy.
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] Re: packet marking: only a ratio, not all

[Andy Furniss]

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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] Re: packet marking: only a ratio, not all

[pfer]

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@dsl.pipex.com> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[LARTC] Re: packet marking: only a ratio, not all

[Andy Furniss]

pfer wrote:
> 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.

OK I guess you know what you want - just thinking there wouldn't be much 
overload% if tcp was about and you were dropping.

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

If that's userspace tc it may be OK - no floats in kernel code AFAIK.


> 
> Could you point me to someone who will probably help
> me with this?

I think netdev is the right place.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc