On Sat, Aug 14, 2004 at 05:21:31PM -0400, jamal wrote:
> > the conntrack stuff (actually that little part of code that adds
> > unbilling to ACCT in case of a drop) is something that comes later
> > (patch 4) and is not in the pkt sched part. please, don't let it
> > divert your mind from the real point. just forget it for the moment...
> > [in any case it is _not_ in the pkt sched area and as i said in mail
> > 4/4 i don't like to put the variables into dev.c, that's why i am
> > there asking for alternatives]
>
> This actually seems to be the core issue.
> Correct me if i misunderstood what you are trying to achieve:
> Somewhere above, the netfilter code bills some packet. Packet gets
> all the way to the scheduler on egress.
> Scheduler drops packet although it has been billed already.
> You being a man looking for justice ;-> decides that was unfair and
> you are trying to undo it. Is this accurate?
Yes, that's how I understoo Allesandro's efforts. While I don't think
it's worth being that precise (and rather change the definition of what
is being accounted to 'number of packets/bytes recevived in this flow').
> Also is their a corrective factor that happens once the _accounting_
> data has been shipped? Example:
> - account for packet
> - ship accounting data to some billing server
> - oops, unbill
> - what now?
Yes, this is a race condition. However, I don't this is not very likely
to occurr, since the accounting data is by default only sent to
userspace via ctnetlink once the connection tracking entry is deleted.
Yes, you can read it while the connection is still alive, but this will
not reset/update the counters, but rather give you a current snapshot.
If you send this to your accounting server, the accounting server has to
cope with the fact that this intermediate snapshot can be updated by
some later data. It SHOULD not care whether this later data for the
same flow has bigger or smaller byte/packet counters. [and
it is very unlikely that the total will be lower, since then in the
timeframe [snapshot, terminations] more packets have to be dropped than
accepted. Still, if this is documented with ctnetlink I'm perfectly
fine which such behaviour.
> BTW, what happens if you clone the packet below netfilter and send
> several copies of it possibly over several different interfaces? This
> may happen with tc extensions.
oh yes, I think somebody has written a similar iptables target, too. I'm
not sure whether there is a good solution for the 'unbill' feature. Do
you have any thoughts/recommendations for this?
> I think accounting is important - especially if it is almost free with
> contracking.
Totally agreed.
The reason for not delaying accounting update until qdisc has happened
is locking. Then we would have to re-grab the conntrack write lock to
make the counter update... whrereas in my patch counter updates happen
while we are already under write lock for the timer/timeout update.
> Lets talk about this issue first instead of confusing it with everything
> else you have in other patches.
Also, if this 'unbill' feature gets into the kernel in some form, I
would definitely make it a CONFIG_ or sysctl... after all people could
be interested in the Rx side only...
> cheers,
> jamal
--
- 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
signature.asc
Description: Digital signature
|