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.

Paper: http://conferences.sigcomm.org/hotnets/2013/papers/hotnets-final48.pdf

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.