Friday, November 22, 2013

HotNets'13: Trevi: Watering Down Storage Hotspots with Cool Fountain Codes.

George Parisis, Toby Moncaster, Anil Madhavapeddy, Jon Crowcroft (Computer Laboratory, University of Cambridge).

Presented by George Parisis.


Commodity storage applications still use TCP, which has its own problems: Incast, lack of multicast support, no multipath support.  The paper introduces a system called Trevis, a transport protocol specially designed for storage applications that uses fountain codes to get around TCP's limitations. In Trevis, (fountain coded) symbols are first-class citizens of transmission.  The key features of Trevis are: (a) receiver-based flow control, (b) fountain-coded symbols, (c) support for multicasting, and (d) multi-sourcing to fetch data from multiple replicas.

What is interesting about this paper is that it got me thinking along the lines of designing a transport with application intent (fetching content) in mind, instead of metrics we usually associate with application performance (flow completion times).

Q: Fountain codes have some limitations (e.g. it can encode only limited message length) before it has serious overheads.  What do you do about this?
A: The messages are typically small in size -- limited by the storage system's blob size, which is typically bounded (~4MB) and configurable.

Q: You are combining error recovery with congestion control.  Is this the right thing to do?
A: I don't know, and I don't have numbers to show (yet).

Q: Our benchmarks show Reed-Solomon codes takes 5--10s.
A: This isn't Reed-Solomon.  Fountain codes are "online" so you can do it on the fly.