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.
No comments:
Post a Comment