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

From: Lincoln Dale (ltd@cisco.com)
Date: Thu Jun 13 2002 - 19:24:13 EST


At 09:00 AM 12/06/2002 -0400, jamal wrote:
> > > > 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!

>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!

> > 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!

> > 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.

>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.

> > 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/



This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:30 EST