Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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.


Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.