[RFC] setting up throughput threshold indications to userspace

[RFC] setting up throughput threshold indications to userspace

[Luciano Coelho]

Hi all,

I've been trying to set up some rules that will send indications to the
userspace about the current throughput of a certain interface.  The idea
is to let the userspace enable or disable WLAN PS mode accordingly (the
validity of this idea is another subject ;).

This is related to the discussion we had in the thread about the NFNOTIF
thread.

I'm thinking about having this kind of ruleset:

-A INPUT -j throughput 
-A above -m connmark --mark 0x1 -j RETURN 
-A above -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-gt -j LOG --log-prefix "ABOVE" 
-A above -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-gt -j CONNMARK --set-xmark 0x1/0xffffffff 
-A below -m connmark --mark 0x2 -j RETURN 
-A below -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-lt -j LOG --log-prefix "BELOW" 
-A below -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-lt -j CONNMARK --set-xmark 0x2/0xffffffff 
-A throughput -j RATEEST --rateest-name throughput --rateest-interval 250.0ms --rateest-ewmalog 500.0ms 
-A throughput -j above 
-A throughput -j below 

I'm using a normal LOG just for simplicity reasons, in real life I'd use
NFLOG instead.

The idea here is that all packets would be collected by RATEEST for rate
estimation and then I'd check whether the throughput is above the
threshold.  If it is, I mark it as such and print the log.  Same thing
for below the threshold.  The RETURN rules are there to prevent more LOG
messages from being printed (what I need is to know only when the
throughput "crosses" the threshold).

Do you think this works?

There is one problem with this solution, which is that it works in a
per-connection basis (due to CONNMARK).  This is not exactly what I
want.  I need to have this on a per-ruleset basis.  For that, I need to
have a MARK (variable?) which can be set independently of connections or
packets.  This is similar to the proposed condition match, but what is
missing there is a way to set the condition with iptables itself,
without requiring the userspace to change the procfs file.  This could
probably be achieved with a "CONDITION" target or something similar.
Any ideas?


-- 
Cheers,
Luca.

Re: [RFC] setting up throughput threshold indications to userspace

[Patrick McHardy]

Am 16.07.2010 10:20, schrieb Luciano Coelho:
> Hi all,
> 
> I've been trying to set up some rules that will send indications to the
> userspace about the current throughput of a certain interface.  The idea
> is to let the userspace enable or disable WLAN PS mode accordingly (the
> validity of this idea is another subject ;).
> 
> This is related to the discussion we had in the thread about the NFNOTIF
> thread.
> 
> I'm thinking about having this kind of ruleset:
> 
> -A INPUT -j throughput 
> -A above -m connmark --mark 0x1 -j RETURN 
> -A above -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-gt -j LOG --log-prefix "ABOVE" 
> -A above -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-gt -j CONNMARK --set-xmark 0x1/0xffffffff 
> -A below -m connmark --mark 0x2 -j RETURN 
> -A below -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-lt -j LOG --log-prefix "BELOW" 
> -A below -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-lt -j CONNMARK --set-xmark 0x2/0xffffffff 
> -A throughput -j RATEEST --rateest-name throughput --rateest-interval 250.0ms --rateest-ewmalog 500.0ms 
> -A throughput -j above 
> -A throughput -j below 
> 
> I'm using a normal LOG just for simplicity reasons, in real life I'd use
> NFLOG instead.
> 
> The idea here is that all packets would be collected by RATEEST for rate
> estimation and then I'd check whether the throughput is above the
> threshold.  If it is, I mark it as such and print the log.  Same thing
> for below the threshold.  The RETURN rules are there to prevent more LOG
> messages from being printed (what I need is to know only when the
> throughput "crosses" the threshold).
> 
> Do you think this works?

Looks reasonable, but you could probably simplify it a bit by adding
RETURN rules to the above/below chains when the threshold is below/
above the specified value. That way you only need a single rateest
match.

> There is one problem with this solution, which is that it works in a
> per-connection basis (due to CONNMARK).  This is not exactly what I
> want.  I need to have this on a per-ruleset basis.  For that, I need to
> have a MARK (variable?) which can be set independently of connections or
> packets.  This is similar to the proposed condition match, but what is
> missing there is a way to set the condition with iptables itself,
> without requiring the userspace to change the procfs file.  This could
> probably be achieved with a "CONDITION" target or something similar.
> Any ideas?

Sounds useful.

Re: [RFC] setting up throughput threshold indications to userspace

[Luciano Coelho]

On Fri, 2010-07-16 at 15:01 +0200, ext Patrick McHardy wrote:
> Am 16.07.2010 10:20, schrieb Luciano Coelho:
> > I'm thinking about having this kind of ruleset:
> > 
> > -A INPUT -j throughput 
> > -A above -m connmark --mark 0x1 -j RETURN 
> > -A above -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-gt -j LOG --log-prefix "ABOVE" 
> > -A above -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-gt -j CONNMARK --set-xmark 0x1/0xffffffff 
> > -A below -m connmark --mark 0x2 -j RETURN 
> > -A below -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-lt -j LOG --log-prefix "BELOW" 
> > -A below -m rateest --rateest throughput --rateest-bps1 0bit --rateest-bps2 1000bit --rateest-lt -j CONNMARK --set-xmark 0x2/0xffffffff 
> > -A throughput -j RATEEST --rateest-name throughput --rateest-interval 250.0ms --rateest-ewmalog 500.0ms 
> > -A throughput -j above 
> > -A throughput -j below 
> > 
> > I'm using a normal LOG just for simplicity reasons, in real life I'd use
> > NFLOG instead.
> > 
> > The idea here is that all packets would be collected by RATEEST for rate
> > estimation and then I'd check whether the throughput is above the
> > threshold.  If it is, I mark it as such and print the log.  Same thing
> > for below the threshold.  The RETURN rules are there to prevent more LOG
> > messages from being printed (what I need is to know only when the
> > throughput "crosses" the threshold).
> > 
> > Do you think this works?
> 
> Looks reasonable, but you could probably simplify it a bit by adding
> RETURN rules to the above/below chains when the threshold is below/
> above the specified value. That way you only need a single rateest
> match.

Right, that would certainly make it simpler.


> > There is one problem with this solution, which is that it works in a
> > per-connection basis (due to CONNMARK).  This is not exactly what I
> > want.  I need to have this on a per-ruleset basis.  For that, I need to
> > have a MARK (variable?) which can be set independently of connections or
> > packets.  This is similar to the proposed condition match, but what is
> > missing there is a way to set the condition with iptables itself,
> > without requiring the userspace to change the procfs file.  This could
> > probably be achieved with a "CONDITION" target or something similar.
> > Any ideas?
> 
> Sounds useful.

Okay, this was the kind of confirmation I wanted before jumping into the
implementation. ;) I'll implement this target soon.

Thanks for your comments!

-- 
Cheers,
Luca.

Re: [RFC] setting up throughput threshold indications to userspace

[Jan Engelhardt]

On Friday 2010-07-16 15:10, Luciano Coelho wrote:
>> > There is one problem with this solution, which is that it works in a
>> > per-connection basis (due to CONNMARK).  This is not exactly what I
>> > want.  I need to have this on a per-ruleset basis.  For that, I need to
>> > have a MARK (variable?) which can be set independently of connections or
>> > packets.  This is similar to the proposed condition match, but what is
>> > missing there is a way to set the condition with iptables itself,
>> > without requiring the userspace to change the procfs file.  This could
>> > probably be achieved with a "CONDITION" target or something similar.
>> > Any ideas?
>> 
>> Sounds useful.
>
>Okay, this was the kind of confirmation I wanted before jumping into the
>implementation. ;) I'll implement this target soon.

My suggestion to have it combined with xt_condition.

Re: [RFC] setting up throughput threshold indications to userspace

[Luciano Coelho]

On Fri, 2010-07-16 at 21:27 +0200, ext Jan Engelhardt wrote:
> On Friday 2010-07-16 15:10, Luciano Coelho wrote:
> >> > There is one problem with this solution, which is that it works in a
> >> > per-connection basis (due to CONNMARK).  This is not exactly what I
> >> > want.  I need to have this on a per-ruleset basis.  For that, I need to
> >> > have a MARK (variable?) which can be set independently of connections or
> >> > packets.  This is similar to the proposed condition match, but what is
> >> > missing there is a way to set the condition with iptables itself,
> >> > without requiring the userspace to change the procfs file.  This could
> >> > probably be achieved with a "CONDITION" target or something similar.
> >> > Any ideas?
> >> 
> >> Sounds useful.
> >
> >Okay, this was the kind of confirmation I wanted before jumping into the
> >implementation. ;) I'll implement this target soon.
> 
> My suggestion to have it combined with xt_condition.

Yes, I also think that is the best idea.  I'll implement a CONDITION
target that will work together with the condition match.  For now I'll
use the non-final version you submitted some time ago.


-- 
Cheers,
Luca.

Re: [RFC] setting up throughput threshold indications to userspace

[Luciano Coelho]

Hello,

On Mon, 2010-07-19 at 07:30 +0200, Coelho Luciano (Nokia-MS/Helsinki)
wrote:
> On Fri, 2010-07-16 at 21:27 +0200, ext Jan Engelhardt wrote:
> > On Friday 2010-07-16 15:10, Luciano Coelho wrote:
> > >> > There is one problem with this solution, which is that it works in a
> > >> > per-connection basis (due to CONNMARK).  This is not exactly what I
> > >> > want.  I need to have this on a per-ruleset basis.  For that, I need to
> > >> > have a MARK (variable?) which can be set independently of connections or
> > >> > packets.  This is similar to the proposed condition match, but what is
> > >> > missing there is a way to set the condition with iptables itself,
> > >> > without requiring the userspace to change the procfs file.  This could
> > >> > probably be achieved with a "CONDITION" target or something similar.
> > >> > Any ideas?
> > >> 
> > >> Sounds useful.
> > >
> > >Okay, this was the kind of confirmation I wanted before jumping into the
> > >implementation. ;) I'll implement this target soon.
> > 
> > My suggestion to have it combined with xt_condition.
> 
> Yes, I also think that is the best idea.  I'll implement a CONDITION
> target that will work together with the condition match.  For now I'll
> use the non-final version you submitted some time ago.

Now that I have implemented the changes needed in the condition module
so that it has a target which can be used to set the condition, I came
up with the following rules to inform the userspace about the throughput
of a specific interface (in this case wlan0):

iptables -N throughput
iptables -N test_above
iptables -N test_below
iptables -A INPUT -i wlan0 -j throughput
iptables -A OUTPUT -o wlan0 -j throughput
iptables -A throughput -j RATEEST --rateest-name throughput --rateest-interval 250.0ms --rateest-ewmalog 500.0ms 
iptables -A throughput -m condition --name throughput ! --value 1 -j test_above
iptables -A throughput -m condition --name throughput ! --value 2 -j test_below
iptables -A test_above -m rateest --rateest1 throughput --rateest-bps1 0 --rateest-bps2 512bps --rateest-gt -j CONDITION --value 1 --name throughput
iptables -A test_above -m condition --name "throughput" --value 1 -j NFLOG --nflog-prefix "ABOVE "
iptables -A test_below -m rateest --rateest1 throughput --rateest-bps1 0 --rateest-bps2 512bps --rateest-lt -j CONDITION --value 2 --name throughput
iptables -A test_below -m condition --name "throughput" --value 2 -j NFLOG --nflog-prefix "BELOW "

This is just a proof of concept and I'm sure it can be optimized (I'll
look into it once it works fully).

Anyway, my problem now, is that the rate estimator targets are only
reached when there are packets coming through (for obvious reasons).
What is happening is that, if the last packet sent through this
interface is sent as part of a high throughput burst, the last signal
the userspace will get is "ABOVE".  After that, the interface becomes
idle and the "BELOW" signal is never sent, even though we will be
transmitting at 0 bps.

Does anyone have an idea on how I could solve this problem?

I have been considering using the IDLETIMER target and activate it when
the throughput goes to HIGH.  Then if this timer expires, it would
inform the userspace that now there's no data going through.  But this
sounds very artificial to me and will add one more dependency on the
userspace, since the IDLETIMER is using sysfs to inform userspace,
instead of netlink.

Any other suggestions?


-- 
Cheers,
Luca.

Re: [RFC] setting up throughput threshold indications to userspace

[Changli Gao]

On Mon, Aug 16, 2010 at 9:40 PM, Luciano Coelho
<luciano.coelho@nokia.com> wrote:
> Hello,
>
> On Mon, 2010-07-19 at 07:30 +0200, Coelho Luciano (Nokia-MS/Helsinki)
> wrote:
>> On Fri, 2010-07-16 at 21:27 +0200, ext Jan Engelhardt wrote:
>> > On Friday 2010-07-16 15:10, Luciano Coelho wrote:
>> > >> > There is one problem with this solution, which is that it works in a
>> > >> > per-connection basis (due to CONNMARK).  This is not exactly what I
>> > >> > want.  I need to have this on a per-ruleset basis.  For that, I need to
>> > >> > have a MARK (variable?) which can be set independently of connections or
>> > >> > packets.  This is similar to the proposed condition match, but what is
>> > >> > missing there is a way to set the condition with iptables itself,
>> > >> > without requiring the userspace to change the procfs file.  This could
>> > >> > probably be achieved with a "CONDITION" target or something similar.
>> > >> > Any ideas?
>> > >>
>> > >> Sounds useful.
>> > >
>> > >Okay, this was the kind of confirmation I wanted before jumping into the
>> > >implementation. ;) I'll implement this target soon.
>> >
>> > My suggestion to have it combined with xt_condition.
>>
>> Yes, I also think that is the best idea.  I'll implement a CONDITION
>> target that will work together with the condition match.  For now I'll
>> use the non-final version you submitted some time ago.
>
> Now that I have implemented the changes needed in the condition module
> so that it has a target which can be used to set the condition, I came
> up with the following rules to inform the userspace about the throughput
> of a specific interface (in this case wlan0):
>
> iptables -N throughput
> iptables -N test_above
> iptables -N test_below
> iptables -A INPUT -i wlan0 -j throughput
> iptables -A OUTPUT -o wlan0 -j throughput
> iptables -A throughput -j RATEEST --rateest-name throughput --rateest-interval 250.0ms --rateest-ewmalog 500.0ms
> iptables -A throughput -m condition --name throughput ! --value 1 -j test_above
> iptables -A throughput -m condition --name throughput ! --value 2 -j test_below
> iptables -A test_above -m rateest --rateest1 throughput --rateest-bps1 0 --rateest-bps2 512bps --rateest-gt -j CONDITION --value 1 --name throughput
> iptables -A test_above -m condition --name "throughput" --value 1 -j NFLOG --nflog-prefix "ABOVE "
> iptables -A test_below -m rateest --rateest1 throughput --rateest-bps1 0 --rateest-bps2 512bps --rateest-lt -j CONDITION --value 2 --name throughput
> iptables -A test_below -m condition --name "throughput" --value 2 -j NFLOG --nflog-prefix "BELOW "
>
> This is just a proof of concept and I'm sure it can be optimized (I'll
> look into it once it works fully).
>
> Anyway, my problem now, is that the rate estimator targets are only
> reached when there are packets coming through (for obvious reasons).
> What is happening is that, if the last packet sent through this
> interface is sent as part of a high throughput burst, the last signal
> the userspace will get is "ABOVE".  After that, the interface becomes
> idle and the "BELOW" signal is never sent, even though we will be
> transmitting at 0 bps.
>
> Does anyone have an idea on how I could solve this problem?
>
> I have been considering using the IDLETIMER target and activate it when
> the throughput goes to HIGH.  Then if this timer expires, it would
> inform the userspace that now there's no data going through.  But this
> sounds very artificial to me and will add one more dependency on the
> userspace, since the IDLETIMER is using sysfs to inform userspace,
> instead of netlink.
>
> Any other suggestions?
>

You can implement a daemon: which samples the statistics data of NIC
periodically, calculates the average bandwidth in a period, and change
the condition variables accordingly.


-- 
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] setting up throughput threshold indications to userspace

[Luciano Coelho]

On Mon, 2010-08-16 at 15:51 +0200, ext Changli Gao wrote:
> On Mon, Aug 16, 2010 at 9:40 PM, Luciano Coelho
> <luciano.coelho@nokia.com> wrote:
> > Hello,
> >
> > On Mon, 2010-07-19 at 07:30 +0200, Coelho Luciano (Nokia-MS/Helsinki)
> > wrote:
> >> On Fri, 2010-07-16 at 21:27 +0200, ext Jan Engelhardt wrote:
> >> > On Friday 2010-07-16 15:10, Luciano Coelho wrote:
> >> > >> > There is one problem with this solution, which is that it works in a
> >> > >> > per-connection basis (due to CONNMARK).  This is not exactly what I
> >> > >> > want.  I need to have this on a per-ruleset basis.  For that, I need to
> >> > >> > have a MARK (variable?) which can be set independently of connections or
> >> > >> > packets.  This is similar to the proposed condition match, but what is
> >> > >> > missing there is a way to set the condition with iptables itself,
> >> > >> > without requiring the userspace to change the procfs file.  This could
> >> > >> > probably be achieved with a "CONDITION" target or something similar.
> >> > >> > Any ideas?
> >> > >>
> >> > >> Sounds useful.
> >> > >
> >> > >Okay, this was the kind of confirmation I wanted before jumping into the
> >> > >implementation. ;) I'll implement this target soon.
> >> >
> >> > My suggestion to have it combined with xt_condition.
> >>
> >> Yes, I also think that is the best idea.  I'll implement a CONDITION
> >> target that will work together with the condition match.  For now I'll
> >> use the non-final version you submitted some time ago.
> >
> > Now that I have implemented the changes needed in the condition module
> > so that it has a target which can be used to set the condition, I came
> > up with the following rules to inform the userspace about the throughput
> > of a specific interface (in this case wlan0):
> >
> > iptables -N throughput
> > iptables -N test_above
> > iptables -N test_below
> > iptables -A INPUT -i wlan0 -j throughput
> > iptables -A OUTPUT -o wlan0 -j throughput
> > iptables -A throughput -j RATEEST --rateest-name throughput --rateest-interval 250.0ms --rateest-ewmalog 500.0ms
> > iptables -A throughput -m condition --name throughput ! --value 1 -j test_above
> > iptables -A throughput -m condition --name throughput ! --value 2 -j test_below
> > iptables -A test_above -m rateest --rateest1 throughput --rateest-bps1 0 --rateest-bps2 512bps --rateest-gt -j CONDITION --value 1 --name throughput
> > iptables -A test_above -m condition --name "throughput" --value 1 -j NFLOG --nflog-prefix "ABOVE "
> > iptables -A test_below -m rateest --rateest1 throughput --rateest-bps1 0 --rateest-bps2 512bps --rateest-lt -j CONDITION --value 2 --name throughput
> > iptables -A test_below -m condition --name "throughput" --value 2 -j NFLOG --nflog-prefix "BELOW "
> >
> > This is just a proof of concept and I'm sure it can be optimized (I'll
> > look into it once it works fully).
> >
> > Anyway, my problem now, is that the rate estimator targets are only
> > reached when there are packets coming through (for obvious reasons).
> > What is happening is that, if the last packet sent through this
> > interface is sent as part of a high throughput burst, the last signal
> > the userspace will get is "ABOVE".  After that, the interface becomes
> > idle and the "BELOW" signal is never sent, even though we will be
> > transmitting at 0 bps.
> >
> > Does anyone have an idea on how I could solve this problem?
> >
> > I have been considering using the IDLETIMER target and activate it when
> > the throughput goes to HIGH.  Then if this timer expires, it would
> > inform the userspace that now there's no data going through.  But this
> > sounds very artificial to me and will add one more dependency on the
> > userspace, since the IDLETIMER is using sysfs to inform userspace,
> > instead of netlink.
> >
> > Any other suggestions?
> >
> 
> You can implement a daemon: which samples the statistics data of NIC
> periodically, calculates the average bandwidth in a period, and change
> the condition variables accordingly.

We don't want to use polling from userspace.  That's the reason why we
decided to use iptables instead.  The idea is that we will only notify
the userspace when the throughput crosses the threshold line.  And the
rules I defined above are working rather well, except for this "detail"
that the BELOW signal is not sent when there's no data flowing.

Thanks for your suggestion anyway, we will reconsider the idea of
polling, but still I would prefer to fix the 0 bps problem (if
possible). ;)


-- 
Cheers,
Luca.

Re: [RFC] setting up throughput threshold indications to userspace

[Changli Gao]

On Mon, Aug 16, 2010 at 10:01 PM, Luciano Coelho
<luciano.coelho@nokia.com> wrote:
> On Mon, 2010-08-16 at 15:51 +0200, ext Changli Gao wrote:
>>
>> You can implement a daemon: which samples the statistics data of NIC
>> periodically, calculates the average bandwidth in a period, and change
>> the condition variables accordingly.
>
> We don't want to use polling from userspace.  That's the reason why we
> decided to use iptables instead.  The idea is that we will only notify
> the userspace when the throughput crosses the threshold line.  And the
> rules I defined above are working rather well, except for this "detail"
> that the BELOW signal is not sent when there's no data flowing.
>

There is a daemon watching the ABOVE signal in any way. How about
staring a timer, which is used to check if there is no packet
transfered in a period, in this daemon when receiving the ABOVE
signal, and stopping this timer when receiving the BELOW signal? It is
like the implementation of IDLETIMER in user space.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] setting up throughput threshold indications to userspace

[Luciano Coelho]

On Mon, 2010-08-16 at 16:13 +0200, ext Changli Gao wrote:
> On Mon, Aug 16, 2010 at 10:01 PM, Luciano Coelho
> <luciano.coelho@nokia.com> wrote:
> > On Mon, 2010-08-16 at 15:51 +0200, ext Changli Gao wrote:
> >>
> >> You can implement a daemon: which samples the statistics data of NIC
> >> periodically, calculates the average bandwidth in a period, and change
> >> the condition variables accordingly.
> >
> > We don't want to use polling from userspace.  That's the reason why we
> > decided to use iptables instead.  The idea is that we will only notify
> > the userspace when the throughput crosses the threshold line.  And the
> > rules I defined above are working rather well, except for this "detail"
> > that the BELOW signal is not sent when there's no data flowing.
> >
> 
> There is a daemon watching the ABOVE signal in any way. How about
> staring a timer, which is used to check if there is no packet
> transfered in a period, in this daemon when receiving the ABOVE
> signal, and stopping this timer when receiving the BELOW signal? It is
> like the implementation of IDLETIMER in user space.

Yeah, we do have a daemon listening to it.  This idea is actually good
and might work.  As you say, it's very similar to IDLETIMER, but in
userspace.  I'll ask our userspace guy which one he prefers to use (ie.
either making the timer himself, or listening to IDLETIMER's sysfs
indication).

Of course, it is also possible to implement a netfilter interface for
the idletimer target as well (as Samuel has already suggested), so that
dependencies in userspace would be simplified. ;)


-- 
Cheers,
Luca.

Re: [RFC] setting up throughput threshold indications to userspace

[Jan Engelhardt]

On Monday 2010-08-16 16:01, Luciano Coelho wrote:
>> You can implement a daemon: which samples the statistics data of NIC
>> periodically, calculates the average bandwidth in a period, and change
>> the condition variables accordingly.
>
>We don't want to use polling from userspace.  That's the reason why we
>decided to use iptables instead.  The idea is that we will only notify
>the userspace when the throughput crosses the threshold line.  And the
>rules I defined above are working rather well, except for this "detail"
>that the BELOW signal is not sent when there's no data flowing.

Without data, the turing machine won't finish, so you can't say for
sure that you reached below. That is sort of a halting problem, which
is known to be unsolvable.

Re: [RFC] setting up throughput threshold indications to userspace

[Luciano Coelho]

On Mon, 2010-08-16 at 17:19 +0200, ext Jan Engelhardt wrote:
> On Monday 2010-08-16 16:01, Luciano Coelho wrote:
> >> You can implement a daemon: which samples the statistics data of NIC
> >> periodically, calculates the average bandwidth in a period, and change
> >> the condition variables accordingly.
> >
> >We don't want to use polling from userspace.  That's the reason why we
> >decided to use iptables instead.  The idea is that we will only notify
> >the userspace when the throughput crosses the threshold line.  And the
> >rules I defined above are working rather well, except for this "detail"
> >that the BELOW signal is not sent when there's no data flowing.
> 
> Without data, the turing machine won't finish, so you can't say for
> sure that you reached below. That is sort of a halting problem, which
> is known to be unsolvable.

Yes, that's the theoretical way to put it.  :) In practice I see that
without data the rules won't be traversed and therefore we can't make
any rate calculations.

But if I add an idletimer (which uses a timer to trigger execution,
regardless of the availability of packets to process) with a timeout
equal to the estimator's measurement averaging interval (ewmalog), I can
be sure that the rate went to 0 bps if the timer expires.  Ie. no
packets at all during the measurement interval means 0 bps, right?

-- 
Cheers,
Luca.

Re: [RFC] setting up throughput threshold indications to userspace

[Changli Gao]

On Mon, Aug 16, 2010 at 9:40 PM, Luciano Coelho
<luciano.coelho@nokia.com> wrote:
>
> Now that I have implemented the changes needed in the condition module
> so that it has a target which can be used to set the condition, I came
> up with the following rules to inform the userspace about the throughput
> of a specific interface (in this case wlan0):
>
> iptables -N throughput
> iptables -N test_above
> iptables -N test_below
> iptables -A INPUT -i wlan0 -j throughput
> iptables -A OUTPUT -o wlan0 -j throughput
> iptables -A throughput -j RATEEST --rateest-name throughput --rateest-interval 250.0ms --rateest-ewmalog 500.0ms
> iptables -A throughput -m condition --name throughput ! --value 1 -j test_above
> iptables -A throughput -m condition --name throughput ! --value 2 -j test_below
> iptables -A test_above -m rateest --rateest1 throughput --rateest-bps1 0 --rateest-bps2 512bps --rateest-gt -j CONDITION --value 1 --name throughput
> iptables -A test_above -m condition --name "throughput" --value 1 -j NFLOG --nflog-prefix "ABOVE "
> iptables -A test_below -m rateest --rateest1 throughput --rateest-bps1 0 --rateest-bps2 512bps --rateest-lt -j CONDITION --value 2 --name throughput
> iptables -A test_below -m condition --name "throughput" --value 2 -j NFLOG --nflog-prefix "BELOW "
>
> This is just a proof of concept and I'm sure it can be optimized (I'll
> look into it once it works fully).
>
> Anyway, my problem now, is that the rate estimator targets are only
> reached when there are packets coming through (for obvious reasons).
> What is happening is that, if the last packet sent through this
> interface is sent as part of a high throughput burst, the last signal
> the userspace will get is "ABOVE".  After that, the interface becomes
> idle and the "BELOW" signal is never sent, even though we will be
> transmitting at 0 bps.
>
> Does anyone have an idea on how I could solve this problem?
>
> I have been considering using the IDLETIMER target and activate it when
> the throughput goes to HIGH.  Then if this timer expires, it would
> inform the userspace that now there's no data going through.  But this
> sounds very artificial to me and will add one more dependency on the
> userspace, since the IDLETIMER is using sysfs to inform userspace,
> instead of netlink.
>

Read the code of IDLETIMER again, and I notice that IDLETIMER will
wake up all the sleepers on the corresponding sysfs files. So no
polling is needed, what you need do is watching another files for
read. You can use select/poll/epoll. It should be no very difficult.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] setting up throughput threshold indications to userspace

[Luciano Coelho]

On Mon, 2010-08-16 at 16:26 +0200, ext Changli Gao wrote:
> On Mon, Aug 16, 2010 at 9:40 PM, Luciano Coelho
> <luciano.coelho@nokia.com> wrote:
> > Does anyone have an idea on how I could solve this problem?
> >
> > I have been considering using the IDLETIMER target and activate it when
> > the throughput goes to HIGH.  Then if this timer expires, it would
> > inform the userspace that now there's no data going through.  But this
> > sounds very artificial to me and will add one more dependency on the
> > userspace, since the IDLETIMER is using sysfs to inform userspace,
> > instead of netlink.
> >
> 
> Read the code of IDLETIMER again, and I notice that IDLETIMER will
> wake up all the sleepers on the corresponding sysfs files. So no
> polling is needed, what you need do is watching another files for
> read. You can use select/poll/epoll. It should be no very difficult.

Yes, I know.  I have reworked the IDLETIMER for upstream inclusion, so I
should know this after all. ;) It was just the idea of having the daemon
have one more interface with the kernel that seemed a bit ugly...


-- 
Cheers,
Luca.