North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: 95th Percentile again (was RE: C&W Peering Problem?)
- From: Joe Abley
- Date: Mon Jun 04 01:25:07 2001
On Sat, Jun 02, 2001 at 09:58:49PM -0400, Joe Abley wrote:
> On Sat, Jun 02, 2001 at 05:28:52PM -0400, Timothy Brown wrote:
> > As an interesting aside to this discussion, Digital Island bills for
> > total traffic transmitted per month (in GB increments). Does anyone
> > using them have any comments on this approach besides the obvious? Does
> > anyone else do a similar deal?
> This may be obvious, but billing by volume (bytes transferred) places far
> greater availability requirements on the measurement system than rate-based
> charging schemes.
> If I am charging by the byte, I have to count every packet. If my measurement
> system breaks, I lose money until it is fixed.
> If I am charging by the 95%tile of five-minute average throughput measurements
> obtained during a calendar month, I can make do with much more coarse-grained
> sampling. Measurement system breaks, I'm quite possibly going to bill the
> same amount as if it hadn't broken.
[summarising some off-list conversations]
For those that see this logic as reversed because they are polling
interface counters (and hence calculating 5-minute average rates
involves more polling than recording simple bytes past), consider the
"measurement system" above to consist not only of your SNMP poller,
but also of the firmware on your router or switch that counts packets.
Having router/switch vendors provide part of the measurement system
(by implementing interface counters on their products) is something that
some people are saying works well for them. It's also something that
some people say causes them pain and is hard to do well:
+ devices reboot when receiving apparently legal SNMP GETs
+ interface counters become corrupt or reset non-deterministically
+ interface counters reset on reboot
+ interface OIDs change on OIR
+ SNMP GETs cause high CPU load which affects performance or
stability or both
+ polling code that works with vendor A doesn't work with vendor B,
C, E or F
+ apparently-resolved SNMP issues reappear as if by magic when
firmware is upgraded
Other people choose not to use interface counters, but count packets
in other ways (Jim's ipf counters and NetFlow collectors, the
NeTraMeT/RTFM meters we used to use in New Zealand).
This is not an argument in favour of any particular method of
measurement. My point is that, in both cases, the stability of the
measurement system as a whole needs to be weighed against the
availability requirements of the billing model.
Of the traffic-based charging regimes I have heard of, it seems to
me that simple pay-by-the-byte places one of the highest availability
requirements on the measurement infrastructure, and hence is probably
one of the hardest to do well.