[ NNSquad ] Usage metrics (was Re: Visualizing your bandwidth...)

[Wes Felter <wesley@felter.org>]

RRD graphs are cool, but I don't know what I would learn by having them.

This list previously discussed broadband connection metrics such as  
bandwidth, latency, jitter, contention, etc. What are useful metrics  
for measuring and reporting broadband *usage*? Much of the concern  
about oversubscription and transfer caps is due to customer ignorance  
about how much they are actually using and thus whether their usage  
will be affected.

Here are some strawmen:
1. Transfer per month (GB) so you know how close you are to the 90GB cap
2. Peak bandwidth usage (Mbps) so you know whether it's worth  
upgrading to faster service
3. Time that the connection was saturated
4. Percent of maximum theoretical transfer per month - to shut up the  
people who want to do away with oversubscription :-)
5. Some measure of contention - to detect whether oversubscription  
has any effect

For some of these metrics I'd want to collect data more often than  
every 5 minutes -- probably at least every minute, which may call for  
client-side software to reduce overhead. But if you're going to go  
inside the LAN, why not go into the router itself? WRT Squad, anyone?

(For a discussion of 5-minute-average as an inadequate metric for  
bandwidth measurement, see A. M. Odlyzko, Data networks are lightly  
utilized, and will stay that way. Review of Network Economics, 2 (no.  
3), September 2003, pp. 210-237. http://www.rnejournal.com/articles/ 
andrew_final_sept03.pdf)

Wes Felter - wesley@felter.org - http://felter.org/wesley/

   [ "Eeeny Meenie Chile Beanie -- The spirits are about to speak!"  It's not
     in my queue, but I feel a new posting from Bob Frankston in our near
     future on the topic of alternative router firmware.  Personally, I
     believe that such firmware is a dandy idea ... BUT... I think it's
     important to keep the focus of the project for the time being on
     hardware that people are likely to already have in their possession.

     This project is predicated on having very large numbers of persons
     providing data, and getting alternative firmware into large numbers of
     routers -- even assuming a cooperative and affordable hardware platform
     -- clearly is a longer term and in some aspects problematic route.  In
     other words, a useful idea to think about, but I urge not devoting a lot
     of time or resources to such an effort at this stage that could
     otherwise be devoted toward getting operational in common,
     off-the-shelf, commodity hardware/firmware/software environments. 

                                  -- Lauren Weinstein
                                     NNSquad Moderator ]