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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
