Wow, long time since the blog has seen an honest to goodness post. I'll just make a mental note that teaching a second course, even if it is a boutique course, and serving on a few university level committees are an amazing time sink.
Anyway, a few interesting updates since the last time I posted:
INFOCOM TPC: Whoot! Finally made it in which was nice and just in time for the promotion and tenure package for the fall. Special thanks to the anonymous individuals who pulled me in :)
RIPPS Demo We did a slightly working of RIPPS (our work on detecting rogue wireless access points) at INFOCOM 2008. USB and Mac Mini's do not play that well together when you toss libpcap into the mix.
Travel, travel, travel Per the recommendations of Azer Bestavros, I did the first leg of my CAREER evangelization tour visiting Univ. of Connecticut, Boston University, MIT, and Univ. of Kentucky in a one week span. Plenty of wonderful feedback and comments on the two works presented (RIPPS and my CAREER work).
Now that the semester is almost winding down, my goal is to bring the inter-post time way, way down and to muse on our weekly papers. We tried an experiment of discussion topics and papers which did not fare nearly as well.
Sunday, May 4, 2008
Friday, February 22, 2008
USB Flash Drive Characteristics
We recently had two papers accepted at the upcoming IEEE WoWMoM, one on loss sourcing in 802.11 (more info in a later post) and the other on USB flash drive performance characteristics with respect to read/write speeds and power consumption. The work itself was done in large part by one of my summer REU students which is very cool to see those results turn into a tangible research output.
The paper in itself was an outgrowth of discussions related to a DARPA WAND proposal from last year. While we weren't funded, we had proposed the usage of USB flash to provide a cheap and easy method for significant on-demand storage for our packet caching architecture. There were some discussions that the flash drives would be too expensive power-wise and we were at a loss to directly respond to that. Long story short, that led to the above REU project to pin down the energy costs and performance of the drives which would be a necessity if the grant got funded (it was not, unfortunately).
The net result was that our initial hypothesis was correct, i.e. the cost of the flash drive in terms of power was dwarfed by the cost of the wireless adapter itself, especially in a USB 1.1 setup that would have likely been in place. We were not entirely vindicated as we discovered that by in large, the flash drive itself would never enter a low power mode when not in use, i.e. the file system is in essence permanently mounted which in turn triggered periodic "Keep Alive" messages across the USB bus, never allowing the flash drive to enter suspend mode. The REU student did a nice job diving into the ugly innards of the Linux kernel USB module to hacking up a suspend API for some basic testing. While it did offer the option to manually force a suspend, the performance results that could certainly use some tweaking as it would be ill-suited for significant amounts of suspend/resume operations.
All in all, a neat project for a REU. We posted a Wiki form version of the original submission here if anyone would care to peruse it. The final camera version of the paper (accepted as a short paper) will be posted in the next month or so to the website and will be available on the same link. The USB flash profiling tool is also posted on-line available via the same link or the above direct link.
Finally, I am finally taking the plunge and starting a policy of putting reviews from accepted papers on-line when I can. The nice part is that it gives us a chance to do a minor rebuttal but also it gives some nice transparency to the review process which in my opinion is a very good thing. The review / response notes for the paper can be found here.
The paper in itself was an outgrowth of discussions related to a DARPA WAND proposal from last year. While we weren't funded, we had proposed the usage of USB flash to provide a cheap and easy method for significant on-demand storage for our packet caching architecture. There were some discussions that the flash drives would be too expensive power-wise and we were at a loss to directly respond to that. Long story short, that led to the above REU project to pin down the energy costs and performance of the drives which would be a necessity if the grant got funded (it was not, unfortunately).
The net result was that our initial hypothesis was correct, i.e. the cost of the flash drive in terms of power was dwarfed by the cost of the wireless adapter itself, especially in a USB 1.1 setup that would have likely been in place. We were not entirely vindicated as we discovered that by in large, the flash drive itself would never enter a low power mode when not in use, i.e. the file system is in essence permanently mounted which in turn triggered periodic "Keep Alive" messages across the USB bus, never allowing the flash drive to enter suspend mode. The REU student did a nice job diving into the ugly innards of the Linux kernel USB module to hacking up a suspend API for some basic testing. While it did offer the option to manually force a suspend, the performance results that could certainly use some tweaking as it would be ill-suited for significant amounts of suspend/resume operations.
All in all, a neat project for a REU. We posted a Wiki form version of the original submission here if anyone would care to peruse it. The final camera version of the paper (accepted as a short paper) will be posted in the next month or so to the website and will be available on the same link. The USB flash profiling tool is also posted on-line available via the same link or the above direct link.
Finally, I am finally taking the plunge and starting a policy of putting reviews from accepted papers on-line when I can. The nice part is that it gives us a chance to do a minor rebuttal but also it gives some nice transparency to the review process which in my opinion is a very good thing. The review / response notes for the paper can be found here.
Tuesday, February 19, 2008
Sunday, December 30, 2007
Yikes, long times between postings
Well, the holidays have certainly made things difficult to keep things updated as regularly as I was hoping. Toss in a family emergency to a tight schedule and all bets are off.
A few quick notes for those that do peruse this:
- The INFOCOM 2008 is now on-line and it is a monster. The inclusion of the mini-conference on the main list kept me busy noting relevant papers for my students to look at. Multicast and classical QoS (that isn't pure theory) outside of wireless are definitely minor niche research areas now. I'll certainly be out at Phoenix for the conference despite not having a paper in the main conference (sigh, yet again). Amusingly enough, we have a very good chance (nearly finalized) of getting Cisco funding for our work that was rejected so I guess I'll take money over a publication.
- NDSI 08 results are also out. By in large the reviews were very thorough (a nice trait of the USENIX arena of conferences) but a near miss for us on our Lockdown work. Unfortunately, a single reviewer whose criticisms and ratings were out of sync with the rest of the reviews pretty much doomed the paper. We certainly made the discussion phase but with only 30 out of 175 papers making it in, a killer review like that is too hard to overcome. Eh, not much one can in those cases but grin and bear it and simply note to the students that it indeed happens to everyone in the field.
Long story short, we targeted ease of use and intuitiveness (i.e. just make it work) and the reviewer wanted novelty and complexity (i.e. simplicity is bad). Certainly fair for a conference like Security and Privacy but I thought a bit too pointed for the systems-oriented nature of NSDI. Interestingly enough, a core argument in the paper is that a huge problem in security is that we are making these wonderful complex systems that are hard to use and they aren't being used because well .... they are hard to use. It makes me wonder if Ethernet were proposed today (work with me here) would ever have a chance at a major conference or grant review panel. I certainly have some strong opinions on how the networking conference track is going the wrong direction (too much gatekeeping, not enough prospecting) but that is a post for a different day (post tenure of course). Let's just say I no longer frown upon abstract only submissions like I used to that other areas of CS heavily use. If I have time, I'll post the reviews on-line with the comment/response notes that we did for the HotNets paper which I think was a good exercise.
A few quick notes for those that do peruse this:
- The INFOCOM 2008 is now on-line and it is a monster. The inclusion of the mini-conference on the main list kept me busy noting relevant papers for my students to look at. Multicast and classical QoS (that isn't pure theory) outside of wireless are definitely minor niche research areas now. I'll certainly be out at Phoenix for the conference despite not having a paper in the main conference (sigh, yet again). Amusingly enough, we have a very good chance (nearly finalized) of getting Cisco funding for our work that was rejected so I guess I'll take money over a publication.
- NDSI 08 results are also out. By in large the reviews were very thorough (a nice trait of the USENIX arena of conferences) but a near miss for us on our Lockdown work. Unfortunately, a single reviewer whose criticisms and ratings were out of sync with the rest of the reviews pretty much doomed the paper. We certainly made the discussion phase but with only 30 out of 175 papers making it in, a killer review like that is too hard to overcome. Eh, not much one can in those cases but grin and bear it and simply note to the students that it indeed happens to everyone in the field.
Long story short, we targeted ease of use and intuitiveness (i.e. just make it work) and the reviewer wanted novelty and complexity (i.e. simplicity is bad). Certainly fair for a conference like Security and Privacy but I thought a bit too pointed for the systems-oriented nature of NSDI. Interestingly enough, a core argument in the paper is that a huge problem in security is that we are making these wonderful complex systems that are hard to use and they aren't being used because well .... they are hard to use. It makes me wonder if Ethernet were proposed today (work with me here) would ever have a chance at a major conference or grant review panel. I certainly have some strong opinions on how the networking conference track is going the wrong direction (too much gatekeeping, not enough prospecting) but that is a post for a different day (post tenure of course). Let's just say I no longer frown upon abstract only submissions like I used to that other areas of CS heavily use. If I have time, I'll post the reviews on-line with the comment/response notes that we did for the HotNets paper which I think was a good exercise.
Tuesday, November 27, 2007
Weekly papers - back again
Finally, back with the weekly papers segment after a rough beginning of November. Perhaps it was dodging reactions from INFOCOM reviews and how it went with various folks. More on that later when I have time to do a length post.
Diversity and multiplexing: a fundamental tradeoff in multiple-antenna channels This paper comes from our weekly papers meeting two weeks ago from discussions regarding our INFOCOM reviews regarding the relevance of MIMO to our current work. Transactions on Information Theory is a bit out of our normal purview so kudos to Dave for taking the time to digest the paper in its entirety.
The paper looked at the tradeoffs in a multi-antenna environment with regards to reliability versus capacity. The most relevant portion of the paper is the strong dropoff with regards to either dimension, i.e. if you choose to do both, you will not get a solution that is strong in either dimension. Not exactly a shocking result but the work in the paper is quite sound and a nice discussion point to discuss why our current work on wireless reliability is very interesting.
Near as I can tell, industry has gone the route of capacity over reliability meaning that our results regarding channel reliability are especially apt. In short, our most recent work has been looking at if the reliability of the channel for nodes in close proximity. If loss is primarily from the medium, losses should be correlated in nearby spaces but not necessarily correlated across larger spaces. In contrast, if losses are not correlated in a tight area, it means that it is likely an individual device going crazy, not the medium itself. Most of the works in the literature regarding burstiness / etc. seem to trust that the device itself is good and that the packet got corrupted before arriving, not that the device itself may be a significant source of the packet errors.
While previous works such as SRD by Balakrishnan reached what would be a similar conclusion, the works reached their conclusion for quite different reasons. Put simply, the physical sensors were highly scattered (i.e. APs over 30 feet+ apart) allowing for multi-path effects for different loss probabilities. In contrast, we showed that losses tended to also show a lack of correlation in short distances regardless of orientation, small distance between, and heavy background traffic. Moreover, there were also "weird" periodicity aspects to some of the devices that bear further investigation (Intel Centrino chipset).
Diversity and multiplexing: a fundamental tradeoff in multiple-antenna channels This paper comes from our weekly papers meeting two weeks ago from discussions regarding our INFOCOM reviews regarding the relevance of MIMO to our current work. Transactions on Information Theory is a bit out of our normal purview so kudos to Dave for taking the time to digest the paper in its entirety.
The paper looked at the tradeoffs in a multi-antenna environment with regards to reliability versus capacity. The most relevant portion of the paper is the strong dropoff with regards to either dimension, i.e. if you choose to do both, you will not get a solution that is strong in either dimension. Not exactly a shocking result but the work in the paper is quite sound and a nice discussion point to discuss why our current work on wireless reliability is very interesting.
Near as I can tell, industry has gone the route of capacity over reliability meaning that our results regarding channel reliability are especially apt. In short, our most recent work has been looking at if the reliability of the channel for nodes in close proximity. If loss is primarily from the medium, losses should be correlated in nearby spaces but not necessarily correlated across larger spaces. In contrast, if losses are not correlated in a tight area, it means that it is likely an individual device going crazy, not the medium itself. Most of the works in the literature regarding burstiness / etc. seem to trust that the device itself is good and that the packet got corrupted before arriving, not that the device itself may be a significant source of the packet errors.
While previous works such as SRD by Balakrishnan reached what would be a similar conclusion, the works reached their conclusion for quite different reasons. Put simply, the physical sensors were highly scattered (i.e. APs over 30 feet+ apart) allowing for multi-path effects for different loss probabilities. In contrast, we showed that losses tended to also show a lack of correlation in short distances regardless of orientation, small distance between, and heavy background traffic. Moreover, there were also "weird" periodicity aspects to some of the devices that bear further investigation (Intel Centrino chipset).
Tuesday, October 30, 2007
Saturday, October 20, 2007
New hardware toys
Over the past month or so, I have been searching for low-cost prototype boards for exploring our RIPPS and ScaleBox work. I think I finally have a winner to play with for the near term with the Atmel NGW 100 Network Gateway kit. It has native dual Ethernet support to allow me to do pass through operations with a customized version of Linux already running. A host of other options less important for networking but very cool for tinkering (SD slot, USB, I2C, SPI, GPIO). Most important of all, the price is just about perfect at only $89. For a few more dollars, it would have been nice to see a power supply tossed in but I already had a few 12V supplies lying around from our my mass of external drive purchases in January.
The board is quite fascinating both as an implementation platform and potentially as a teaching platform. At sub-$100, it is close to tolerable to have students simply buy one for themselves. For teaching, a JTAG debugger (enabling remote GDB and recovery from hosing the flash) would be essential but at a $320 list from Digikey, it is a bit pricey but is not necessary for each and every board. I am a bit concerned about how well it could run our current RIPPS code at only a 133 MHz processor but that gives some incentive to help speed it up / streamline it anyway. Perhaps making a hardware version of the WANRay is finally in order without having to toss on a $700 Cisco PIX box.
Initial forays into the box are very promising. I was really surprised how much stuff is running. Telnet into the box worked right away with ssh and ftp already supported. The box is also running a web server as well as a DHCP server for eth1 (labeled LAN). I did not have a chance to test the serial operations as I could not dig up a serial cable amongst my bank of cables at work.
We'll be putting up a Wiki web fairly soon to collect the various information :)
The board is quite fascinating both as an implementation platform and potentially as a teaching platform. At sub-$100, it is close to tolerable to have students simply buy one for themselves. For teaching, a JTAG debugger (enabling remote GDB and recovery from hosing the flash) would be essential but at a $320 list from Digikey, it is a bit pricey but is not necessary for each and every board. I am a bit concerned about how well it could run our current RIPPS code at only a 133 MHz processor but that gives some incentive to help speed it up / streamline it anyway. Perhaps making a hardware version of the WANRay is finally in order without having to toss on a $700 Cisco PIX box.
Initial forays into the box are very promising. I was really surprised how much stuff is running. Telnet into the box worked right away with ssh and ftp already supported. The box is also running a web server as well as a DHCP server for eth1 (labeled LAN). I did not have a chance to test the serial operations as I could not dig up a serial cable amongst my bank of cables at work.
We'll be putting up a Wiki web fairly soon to collect the various information :)
Subscribe to:
Posts (Atom)
