Presented by: Alvin AuYoung
Authors: Jeff Mogul, Alvin AuYoung, Sujata Banerjee, Jeongkeun "JK" Lee, Jayaram Mudigond, Lucian Popa, Puneet Sharma, Yoshio Turner
In many other area of computing, programs are expressed using modular programming abstractions. It would be nice to be able to write network control programs this way too, but different programs often impose conflicting requirements on the network. For example, in a datacenter network, a program trying to minimize bandwidth usage across a core switch may wish to group tenant VMs on the same rack, while a program trying to minimize the effects of link failures may wish to distribute VMs across different racks.
Corybantic is a system for enabling modular composition of network control programs. This work is important because it represents the first attempt to address the general problem of modular composition of network control programs with conflicting requirements. Corybantic defines an API that allows controllers to make proposals for how network resources should be used and define a function for assigning value to other proposals (in a universal "currency"). The Corybantic system collects the proposals and their evaluation by each controller and selects the overall configuration that maximizes value. A prototype system has been implemented in Python and evaluated on the bandwidth/fault-tolerance example in a tree topology, comparing the value computed by Corybantic against the optimal value as computed offline.
Q: Each module is responsible for formulating a complete proposal, rather than a partial proposal. Is that correct?
A: That's correct in what we've actually implemented so far.
Q: You only evaluate proposals that someone makes. What about proposals that nobody makes but that would serve everyone better?
A: We're currently thinking about this. For example, we could add another module that watches what proposals are being made, and inserts its own proposals that would be better than any of the individual modules have been making.
Q: Are the programmers all from the same organization and agree with each other or have you considered adversarial models?
A: The assumption for now is that the programmers are not adversarial.
Q: The theory community has lots of ways for dealing with more complicated constraint problems. What are the right abstractions for expressing and resolving constraints in networking?
A: We think many compositions problems can be naturally expressed in terms of a simple currency instead of more complicated weights, because prices can be grounded in some economic reality, whereas weights are an abstraction of reality.
Q: How do you model things like SLAs as constraints? How do you even know they're satisfiable?
A: There seem to be very few real constraints. Most things can be assigned a value -- for example, one can violate an SLA and pay a penalty. For the true hard constraints (for example, don't burn down the data center, or don't allow traffic from certain users to flow across certain paths) the system allows each module to check proposals against its local set of constraints, and effectively veto constraint-violating proposals. The tricky part is to find ways to generate proposals that don't violate constraints. I don't think we have a general solution to that, yet.
Q: What about the dynamic behavior of the system? Suppose a link goes down in a fault-tolerant program? Who decides whether to batch recompute or just incrementally adjust? To put it another way, does Corybantic introduce more dynamism?
A: Corybantic makes it easier to develop a controller that supports more dynamism. (More dynamism is the goal!)
Acknowledgments: Jeff Mogul and Alvin AuYoung added some clarification on the Q&A.
No comments:
Post a Comment