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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Eric Leblond <eric@xxxxxxxxx> Blog: https://home.regit.org/ -- 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
