netdev
[Top] [All Lists]

Re: Billing 3: WAS(Re: [PATCH 2/4] deferred drop, __parent workaround, r

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: Billing 3: WAS(Re: [PATCH 2/4] deferred drop, __parent workaround, reshape_fail , netdev@xxxxxxxxxxx ,
From: Harald Welte <laforge@xxxxxxxxxxxxx>
Date: Tue, 24 Aug 2004 20:46:36 +0200
Cc: sandr8 <sandr8_NOSPAM_@xxxxxxxxxxxx>, devik@xxxxxx, netdev@xxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1093191124.1043.206.camel@xxxxxxxxxxxxxxxx>
Mail-followup-to: Harald Welte <laforge@xxxxxxxxxxxxx>, jamal <hadi@xxxxxxxxxx>, sandr8 <sandr8_NOSPAM_@xxxxxxxxxxxx>, devik@xxxxxx, netdev@xxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxxxxxx
References: <411C0FCE.9060906@xxxxxxxxxxxx> <1092401484.1043.30.camel@xxxxxxxxxxxxxxxx> <20040816072032.GH15418@sunbeam2> <1092661235.2874.71.camel@xxxxxxxxxxxxxxxx> <4120D068.2040608@xxxxxxxxxxxx> <1092743526.1038.47.camel@xxxxxxxxxxxxxxxx> <41220AEA.20409@xxxxxxxxxxxx> <1093191124.1043.206.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
On Sun, Aug 22, 2004 at 12:12:04PM -0400, jamal wrote:
> On Tue, 2004-08-17 at 09:40, sandr8 wrote:
> > jamal wrote:
> 
> > 
> > >Yes, this is a hard question. Did you see the suggestion i proposed
> > >to Harald?
> > >  
> > >
> > if it is the centralization of the stats with the reason code that,
> > for what concerns the ACCT, says wheter to bill or unbill i
> > think it is _really_ great :)
> > still, for what concerns the multiple interface delivery of the
> > same packet i don't see how it would be solved...
> 
> Such packets are cloned or copied. I am going to assume the contrack
> data remains intact in both cases. LaForge?

Yes. But still it is a question of viewpoint what kind of behaviour is
correct.  Let's say a single packet is accounted in ct_acct, and then
sent to multiple interfaces, where on more than one of them it gets
unbilled.  So we add once, but 'unbill' (i prefer the term subtract)
more than once.   In the end the ct_acct counter will be less than when
it first encountered the packet.

> In the future we should make accounting a feature that could be turned
> on despite contracking and skbs should carry an accounting metadata with
> them. 

I don't really understand what you want to say.  You want accounting
that is not conntrack-based?  well, then you should maybe look at
one of the many methods, ranging from iptables rule counters to the ipt_acct 
match/target, nacctd, pcap-mmap, PF_RING, ULOG-based, ...

btw, they all account the amount of RX packet on inbound interface and
do not 'unbill' ;)

-- 
- Harald Welte <laforge@xxxxxxxxxxxxx>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>