NNSquad - Network Neutrality Squad
[ NNSquad ] Working Groups (was: Re: Visualizing your bandwidth)
Clearly there's no foolproof way to handle this. My gut feeling is that asking people to open up their SNMP interfaces to the outside world and moving non-encrypted data around would be asking for trouble. It seems like one of those situations where things would probably be OK 95% of the time, but that remaining 5% could be a real hassle and a half when something goes wrong. I agree that the problem of data discontinuities is very real when dealing with programs that need to run on user machines. But this still seems like a safer approach since it gives the users more control (remember we're talking about open source, not proprietary code) in addition to the security considerations -- plus it could provide metrics such as when particular machines are up or down that would provide additional insights. The discontinuity issue would seem to be minimized to the extent that we can encourage people to run the data collection code on all associated systems behind the WAN router (or, whenever the Internet was being used, on at least one live machine, even if it wasn't the "active" system at that time). As I mentioned, on some WAN routers enabling WAN access to SNMP also enables TELNET/HTTP access. Given the typical password quality out there, this could be a disturbing prospect. This all seems like a good topic for a working group -- see below. As for custom router firmware, I like the idea of deploying highly instrumented routers in strategic locations around the world, so long as they are only used by persons who have the technical skill to deal with such firmware operations and fully understand the associated risks -- including but not limited to bricking. The scenario I'd like to avoid is an ordinary family (for example) trying to flash one of these things, then complaining to the project that they ruined their router and couldn't access the Net. As a result (they assert) they lost a fortune in potential income on eBay, missed out on their chance to buy Google while it was still under $1K/share ... and so on. That kind of trouble we don't need. Perhaps it's time to establish a few working groups -- I could manage the lists manually for now so long as there isn't too much churn. Three groups to start? - SNMP group: This could evolve to include other developed user measurement systems and software as we go along and would provide us with our first real data as quickly as possible. - Router firmware group: For those intrepid souls ready to dig in to that code and/or willing to run the result. No complaints about bricks, though. - Transport - server - back-end group: Planning and design of the data collection transport system, scalable servers and databases for the collected data, and processing of that data. Initially, I suspect that some broader project policy issues (such as who has access to the raw data? How is the data presented to the public? What sorts of analysis is provided with the data?) will be most entangled with this group. All thoughts appreciated. Thanks. --Lauren-- NNSquad Moderator > > Yup, I had originally thought of just polling from the inside, but my > issue with that was that the data collection only happens when the > collector machine is turned on, etc. I imagined a scenario where > little Johnny is doing huge amounts of PtP, but only at night after > Mom and Dad have turned of their office PC -- this would skew the > results horribly. > > I had also considered the open source firmware idea, but I have seen > too many bricked routers to feel comfortable doing that (I once bought > a pile of 12 WRT-54s from some bloke for $4. Seems he worked at a > school that handed them out to students and these were the ones that > the students had returned as defective -- of the 12, 1 of them looked > like it had soda poured in and the other 11 seemed to have failed a > firmware upgrade -- I managed to get them all working again and gave > them away, used them as low power machines, etc.) > > W