Re: How to modify conntrack accounting?

[Ed W <lists@wildgooses.com>]

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

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

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