[January 29th, 2020] A few interesting updates on what is going on with the work on PASS (Provider Accessible Storage Subsystem) which fits under the broader umbrella of our Redundancy Elimination at the Edge work that is funded by NSF. A bit more under the hood work but hopefully some fairly neat work down below the break.
Unified FMNC / PASS: One of the parts that I am super excited about is blending some of our work via FMNC and the PASS work. Going back to our WeHab work from a few years back, one of the observations that I would typically make at a talk would be with regards to the therapeutic benefits of testing / instrumentation aka nobody ever walks out of organic chemistry test learning organic chemistry. That sort of glib observation was used to help motivate the WeHab work, could we instrument while doing therapeutically useful activities? That same observation applies to network instrumentation if you think about it in a broader sense.
By and large when you think about something like a SpeedTest or an iPerf, it is not terribly useful out of measuring the network. The FMNC work also gets at that said tests tend to be fairly wasteful / impactful to other hosts but a question that emerges is whether or not we could use something like PASS to choose what to stage from the centralized server to the client. Rather than just transferring a series of random / garbage data, could we use that data transfer to move something useful that might be helpful for future caching? This creates interesting tension to our FMNC approach (we try to keep it short / sweet and make no guarantees of completion) but also a wicked cool opportunity to get some utility from the transfers.
Right now, we are envisioning a service provided by PASS whereby the FMNC instrument (or CUP, aka the cellular version of FMNC) can request a particular object or chunk that it should use when instrumenting the link. Doing this on-demand is out though to some extent as the latency for a client-derived query could potentially be too high if it becomes client specific. At the same time, we would like to avoid moving the same data so some sort of history is needed as well.
That being said, the upside for this is potentially too interesting to ignore so we will see how well it might work.
Updated Tent Results: We have a pile of data from our University Relations tent from the fall. While the season went perhaps a bit less stellar than we had hoped post-Michigan, we still had pretty good density from the games prior and not bad density for the home games afterwards. In particular, we had one game where we actually managed two tents (the normal University Relations one and the President’s Circle) which should be top notch. Although the redundancy is not great, this is another nice set of data to share / publish which we will be working on to share here in March and then later via a journal submission during the summer.
PASS Software: Finally, we are looking to move PASS out from the proof of concept stage into something a bit more robust. We have the base client that Xueheng developed as part of his dissertation a few years back and can build on that along with newer / better server code (our ScaleBox code is being modernized due to significant technical debt). The observations from scaling Tesserae are super helpful as well borrowing from what we easier to maintain / provide proper separation. I will say that ZMQ and Python are looking pretty good so far to help keep the code simple / maintainable though my background always steers me to C / C++