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.
Thanks in advance,
Ferenc
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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.
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
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.
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
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..1If 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.