One of the authors of RACS here. Indeed, the architecture of RACS is quite similar to Tahoe-LAFS, with a proxy server that sends shares of data to different cloud providers. With RACS, we focused on fault tolerance rather than malicious modification of data: Cloud providers have their own internal redundancy, so they (hopefully) protect their users from low-level hardware failures... but a company itself can fail, or even raise prices suddenly which can lead to an "economic failure", where the user's application becomes prohibitively expensive to run. So RACS is intended to protect against things like this. It can tolerate malicious modification of data shares on individual cloud providers, but that kind of security wasn't our focus, so it's interesting to see that Tahoe-LAFS takes that direction.
Hi -- I'm one of the authors of Tahoe-LAFS. I haven't read your RACS paper before, but it looks pretty good. I appreciate the emphasis on real-world economics and on the costs of vendor lock-in. I haven't yet completely digested your results numbers to see how they inform my business, but I definitely will.
It's too bad that you weren't aware of, or didn't cite, Tahoe-LAFS when you wrote that paper! Even though you used my zfec library, which I created (by copying Luigi Rizzo's feclib) for Tahoe-LAFS's use. Heh heh heh.
I tried to get Tahoe-LAFS's existence registered in the official academic research world by publishing this: http://scholar.google.com/scholar?cites=7212771373747133487&... but it didn't really work. Most of the subsequent research that probably should have cited Tahoe-LAFS still didn't.
Perhaps that 5-page paper was too telegraphic to communicate a lot of the important properties. For example, it does not spell out the fact that Tahoe-LAFS includes a kind of proof-of-storage/proof-of-retrievability protocol. Also, perhaps, I chose too obscure of a venue to publish it in. I'm not sure.
For your reading pleasure here is a big rant by me on my blog, whining that Tahoe-LAFS is deserving of more attention than HAIL (which you do cite):
"It is frustrating to me that the authors of HAIL are apparently unaware of Tahoe-LAFS, which elegantly solves most of the problems that they set out to solve, which is open source, and which was deployed to the public, storing millions of files, and summarized in a peer-reviewed workshop paper before the HAIL paper was published."
You know, I have to admit that the main reason academic researchers don't appreciate the sophisticated proof-of-work/proof-of-retrievability features in Tahoe-LAFS is that I didn't write it up. The 5-page paper that I linked to -- http://scholar.google.com/scholar?cites=7212771373747133487&... -- doesn't explicitly mention that it has proof-of-work/proof-of-retrievability properties at all, much less do the sort of thorough, precise specification and proof that, for example, the HAIL paper has.
Unfortunately our literature review didn't turn up Tahoe-LAFS when we wrote RACS, possibly because of differing terminology. It would have made a great addition to our related work section. I think the two systems are sufficiently different in design and aims, despite some similarities architecture.
