Re: RFC: per-socket statistics on received/dropped packets

It sounds like what you want is socket accounting which works like
process accounting.  I.e when a socket lifetime ends, put out a record
with number of packets/bytes sent/received.

On Thu, 2002-06-13 at 17:24, Lincoln Dale wrote:

At 09:00 AM 12/06/2002 -0400, jamal wrote:

quoted

quoted

quoted

quoted

i know of many many folk who use transaction logs from HTTP caches for
volume-based billing.
right now, those bills are anywhere between 10% to 25% incorrect.

you call that "extremely limited"?

Surely, you must have better ways to do accounting than this -- otherwise
you deserve to loose money.

many people don't have better ways to do accounting than this.

Then they dont care about loosing money.
There's nothing _more important_ to a service provider than ability to do
proper billing. Otherwise, they are a charity organization.

on this side of the planet (Australia), just about *all* service-providers 
offer differentiated-billing baed on a volume-usage basis.
that includes Worldcom, Telstra, Optus (SingTel), connect.com.au (AAPT).
some of these differentiate themselves by using caching to provide faster 
access and/or mitigate the latency overhead of simplex satellite.
this has been ongoing for many many many years now.  please just accept 
that HTTP caching is almost a necessity with the pricing models in use!

quoted

There's nothing _more important_ to a service provider than ability to do
proper billing. Otherwise, they are a charity organization.

we're almost talking about the same thing here -- and this is my point!  i 
agree that is is important - hence why i've added a getsockopt() option to 
provide octet counters from the ip+tcp level!

quoted

quoted

in the case of Squid and Linux, they're typically using it because its
open-source and "free".

I am hoping you didnt mean to say squid was only good because it has
these perks.

not at all.  they're using it because it meets their requirements.
once again, this is not a discussion about religion or politics!

quoted

quoted

they want to use HTTP Caching to save bandwidth (and therefore save money),
but they also live in a regime of volume-based billing.  (not everywhere on
the planet is fixed-$/month for DSL).

the unfortunate solution is to use HTTP Transaction logs, which count
payload at layer-7, not payload+headers+retransmissions at layer-3.

Look at your own employers eqpt if you want to do this right.
And then search around freshmeat so you dont reinvent the wheel.

once again, i respectfully disagree.  while there are numerous technologies 
for accounting out there (e.g. netflow), they all break down when you have 
things like HTTP Persistent connections which may share a single 
[server-side] connection with multiple [client-side] connections.

quoted

And until you prove it is worth it and useful to other people then
forever thats where it belongs. I now of nobody serious about billing
who is using sockets stats as the transaction point.

you live in a country where the billing regeme is different.

quoted

quoted

lawn-mower support sounds like a userspace application to me.

But we need a new system call support

(yes, i did take that comment as humerous before :-)).

if what i was proposing involved a new system-call then i agree that there 
would be signficant pushback.  what i have is a new getsockopt() 
option.  ie. in reality, no worse than getsockopt(..,TCP_INFO).


cheers,

lincoln.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/