Re: How to modify conntrack accounting?

[Eric Leblond <eric@regit.org>]

Hi,

On Tue, 2013-04-02 at 23:45 +0100, Ed W wrote:
> On 02/04/2013 21:46, Eric Leblond wrote:
> > Hello,
> >
> > Le mardi 02 avril 2013 à 20:11 +0100, Ed W a écrit :
> >> Hi, I have a requirement to account for "bytes I pay for" over some
> >> link, and conntrack very nearly gives me the right answer...  This link
> >> uses accounting somewhat like ATM, where the IP data is sliced into
> >> fixed size cells and you have to pay for the overhead per cell, plus the
> >> wasted space in the extra cell.
> > I'm not sure I really understood your ATM comparison but why not use the
> > new accounting system like described here:
> >
> > https://home.regit.org/2012/07/flow-accounting-with-netfilter-and-ulogd2/
> >
> 
> Thanks - I really need the raw conntrack detail so that I can do my own 
> aggregations (its quite a complex requirement for accounting)
> 
> Apologies for the ATM assumptions.  OK, ATM works by encapsulating the 
> data into small fixed sized packets of 48 bytes with a 5 byte header.  
> So for example if you send a 1000 byte IP packet then it will consume 21 
> ATM cells, which means a total bandwidth you pay for of 21 x (48+5) = 
> 1,113 bytes.   Annoyingly even the last (part filled) packet still has 
> to be 48 bytes, plus you have that 5 byte header on each packet.
> 
> The above is how ADSL connections work, and why using standard QOS fails 
> to work as expected when you have a bunch of small packets (ATM 
> bandwidth becomes large compared with IP bandwidth).

OK that is what I was fearing. You want to do ATM accounting at the IP
level ;)

> I believe newer kernels have some options to correctly compute the 
> overheads for ATM encapsulation, effectively I need to implement 
> something similar for conntrack
> 
> Thanks for further thoughts

You said you want a per-interface accounting but conntrack is not
interface aware. So a better solution may be to update nfacct modue to
increment counter with ATM-rounded value at each packet. Given the type
of patch this will require, it should be easy to maintain other time.
This will provide a more performant and easy to use framework.

By the way, if you want consulting time, I've got some available ;)

BR,
> 
> Ed W
> 
> --
> 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

-- 
Eric Leblond <eric@regit.org>
Blog: https://home.regit.org/

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