Review of IOFlow (SOSP'13)

1) Is the problem real?
This paper tries to deal with the complexity and overhead of I/O path to storage. The problem is critical and needed to be solved.

2) What is the solution’s main idea (nugget)?
IOFlow uses a four-tuple identifier to achieve a centralized control plane which enable high-level flow control. The key idea of IOFlow is to decouple the control of IO flows from the data plane and introduce programmable data plane queues that allow for flexible service and routing properties.

The system mainly contains 3 parts.
1. a centralized controller. It maintains data plane stages and data center topology.
2. data plane queues. It allows differentiated treatment of IO request.
3. a interface between controller and application.


3) Why is solution different from previous work?
Previously works lack a control plain which enable simple flow of I/O Stake. 

IOFlow borrow some control algorithm from SDN control plain. In addition, SEDA and Click are control systems used for thread/event scheduling or router configuration. IOFlow has different focus point which is enable control for IO stack.

4) Does the paper (or do you) identify any fundamental/hard trade-offs? 


Although the IOFlow can achieve useful end to end IO control policy, it introduce overhead on both data plane and control plane.

5) Do you think the paper will be influential in 10 years? Why or why not?

I think it will be useful, since I/O control is always a big problem during the system processing.