Anirudh Sivaraman, Keith Winstein, Suvinay Subramanian, Hari Balakrishnan (MIT CSAIL)
Speaker: Anirudh Sivaraman
In the past, several queue-management and scheduling algorithms for different scenarios have been proposed. Among these are RED, and more recently XCP, RCP, and PDQ. All of these optimize for different objectives and are effective and suitable for their specifc field. The idea of this work is to apply principles of SDN to the data plane in order to find a more flexible and general solution instead of implementing even more different scheduling and queueing schemes. This would allow one to optimize for different networks and different objectives like low latency, high bandwidth or low loss independently of the actual application and the operating system in a more dynamic manner.
The paper works on quantifying the non-universality of existing in-network methods. In particular, the authors look at three different queuing and scheduling schemes, namingly CoDel+FCFS, CoDel+FQ, Bufferbloat+FQ which again all are well applicable for different distinct objectives. Additonally, three different traffic types are taken into consideration: bulk transfers, web traffic (optimize for completion time), and interactive communication. In essence, since the selection of the right schemes, highly depends on various factors, mainly the underlying network and the application, there is no silverbullet solution in terms of a single good network queueing and scheduling configuration.
To overcome this problem, it is proposed to architect the data plane itself for flexibility and extendability in order use different schemes dynamically. This means that network operators should be able to dynamically, based on rules, specify the scheduling and queuing logic by getting an interface to the data plane of the switch exposing the head and tail of the queue. This approach relies on hardware adaption, customized I/O interfaces, state maintenance and a domain-specific instruction set. The hardware side is implemented using a FPGA attached to the switch. The instruction set is put in place to express control flow and implement functionality that is not available in the hardware directly. In conclusion the work proposes an open interface for queuing and scheduling that is portable across vendors, which is a significant step moving towards a programmable data plane.
Q: The methodology of proving seems odd. They don’t seem to prove the non existence of a silver bullet.
A: We tried 3 schemes that are typical. Yes, there could be other ones that we did not work on. We believe these schemes are representative.
Q: Thinking about Click (being one way of doing sdn) … can’t all this be done in Click?
A: Click is purely a software router. Nobody uses it in production. We wanted to work with actual hardware for performance and deployability in real networks.
Q: Instead of specifying all the logic, why don’t you use existing schemes in hardware and parameterize them?
A: Believe, the better approach is to expose API and programmability instead of parameterizing existing.
Q: Could you compare this to FCP (flexible control plane - specifies set of operations on the forwarding plane)?
A: Not aware of this work.
Q: What is the usage scenario for this approach? Just programmable dataplane? Adapt scheduling and queuing based on time (based on workload)? Every single packet possibly treated differently?
A: Our system can support either of these due to its minimal interface.
Q: There have been approaches doing this at the network edge (e.g. Fabric). What is the motivation to have two different architectures? Isn’t processing at the edge more the silver bullet?
A: No, if there are bottlenecks in the network core; if at the edge then possibly.
Q: If a bottleneck is in the core, can the edge identify and transfer control to the core?
A: Possibly.
No comments:
Post a Comment