NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Working Groups
I can understand using existing SNMP MIBs but going forward wouldn't XML be a better approach since it opens up many more tools and it means we can experiment prior to standardization? -----Original Message----- From: nnsquad-bounces+bob19-0501=bobf.frankston.com@nnsquad.org [mailto:nnsquad-bounces+bob19-0501=bobf.frankston.com@nnsquad.org] On Behalf Of Cliff Sojourner Sent: Wednesday, November 28, 2007 02:21 To: nnsquad@nnsquad.org Subject: [ NNSquad ] Re: Working Groups (not withstanding that many SOHO routers do NOT instrument SNMP ...) easy to say "SNMP" but harder to say "which MIB objects would you poll"? MIB-2 ifTable gives total rates for the interfaces, but that's not what regular people need to know. regular people need to know their total bandwidth, and fraction of it consumed by each "application". in the SNMP world, RMON-2 specifies MIB instrumentation intended to identify "applications" and packet rates and bandwidth, but that fell apart because "applications" are not port-based any more. everything runs on port 80, all the P2P stuff hops ports, other stuff is encrypted ... etc. etc. it takes a heavy-duty software application to recognise all the "applications" or network services. Packeteer has a nifty product that shows graphs of bandwidth by application, but it runs on dedicated hardware and it's probably too much for most folks. Similar issues for the other vendors' products in the "WAN Optimization" market. y'all are on the right track; what would be most useful and easily used would be something built in to the PC's network stack. just thinking aloud, maybe a pcap-based classifier & reporter. That would probably work on the holy trinity of Linux, Mac, and Winders. Icing on the cake would be to let users configure QoS for each "application", such as guaranteed 64kbps rate for Skype, restrict BitTorrent to "33%" of bandwidth, HTTP can burst up to 90% line rate, etc. Lauren Weinstein wrote: > 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 >> > > >