[Top] [All Lists]

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

To: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Subject: Re: RFC: per-socket statistics on received/dropped packets
From: Lincoln Dale <ltd@xxxxxxxxx>
Date: Sun, 23 Jun 2002 12:05:44 +1000
Cc: vonbrand@xxxxxxxxxxxx (Horst von Brand), davem@xxxxxxxxxx (David S. Miller), greearb@xxxxxxxxxxxxxxx (Ben Greear), linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <E17LwjD-0003hT-00@xxxxxxxxxxxxxxxxx>
References: <>
Sender: owner-netdev@xxxxxxxxxxx
g'day Alan,

At 03:03 AM 23/06/2002 +0100, you 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"?

It wouldnt help you anyway. Prove which frames were not due to the
overloading and congestion/errors on your network which therefore the customer should
not have a duty to pay. Account for bitstuffing on HDLC links...

sure - but these are all Layer-8 (politics) and layer-9 (religion) issues.

typically Service Providers on this side of the planet handle that side of things via SLAs internal to their own network. i.e. "we guarantee X% uptime, less than Y% packet-loss across our own core network as measured using XXYYZZ method".

the fact that an IP packet may have a PPP header on it across one hop, a HDLC header across another, perhaps some MPLS labels across another, 802.1q-in-802.1q across another is generally immaterial. if you did want to get fancy and account for it, at least you have packet-counters on a per-socket basis from which to do that with.
without per-socket accounting, you just don't have that anyway.



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