Monday, May 11, 2009

Thoughts on Practical Declarative Network Management

Authors: Timothy Hinrichs, Natasha Gude, Martin Casado, John Mitchell, Scott Shenker

Published in: Workshop on Research in Enterprise Networks (WREN) 2009

Summary:
The authors designed, implemented, and tested a language for declarative network policies --- Flow Management Language (FML). The language has no ordering and is declarative. Conflicts in rules can arise and are handled by prioritizing keywords (e.g. deny has higher priority over allow). Because the language has no ordering the authors claim it is easier to write and reason about and is can accommodate multiple authors more easily. Application developers can have control over flows and can write rules themselves.

They implemented the FML engine over Nox and deployed it on two campuses. The implementation can process rules in linear time and can handle heavy loads. The implementation was done by using trees in order to evaluate rules. The deployment seems to be working, and they had the ability to introduce new keywords (HttpRedirect) into the language to handle complex cases.

The Good:
The paper makes it clear that FML is a flexible language that can be used to declare network policies nicely. But not only is it flexible, concise, and based on principals, it can be evaluated in linear time. The implementation and deployment provides good evaluation. The tree implementation for implementation is a very cute idea. I think I will be using it for my stuff :) I liked the fact that new keywords can be added, but is it easy to do?

The Bad:
The authors argue that ordering is a bad idea. Yet, they end up enforcing some form of ordering by making policies cascade. OK, so it's not ordered within a single cascade, but I'm not sure you would write rules without cascades. They did not make the case for lack of ordering well. I think it is really really difficult to reason about flows in the case of conflicts. I do not see how the combination of conflicts + keyword prioritization + cascades is simpler than a total ordering on all statements. The argument about making it easier for multiple authors does not really hold water because it seems that authors would have priority, and you don't want conflicts anywhere. In fact, I don't see how multiple authors can operate easily in FML, even with cascades!

Unfortunately, I don't see how application developers (or do they mean Nox applications?) can control their own flows. Is their an API? I thought FML was pre-compiled, how do users add their own stuff there?

The Ugly:
I really did not like the non-ordering, cascading, and keyword prioritization stuff. It seemed to make things much more complex. The fact that conflicts are allowed negates a whole bunch of things they had said about making it clearer to reason about things. I don't see its necessity, or maybe there is some necessity (such as to make it easier for implementation) but I don't recall it was mentioned in the paper.

2 comments:

  1. Hi Jad. I also have studied this article but there is one blurry zone to which i cannot find answer, maybe you could help me.

    In the paper, it is said that FML can target users. But i don't understand how it is possible to differentiate several users on the same host. It seems that since it is built on a Nox controller, the information it has access to are the one defined in the Openflow specifications, and these are information about mac or ip address.

    I sincerely hope you could help me understand this article more. Thank you in advance for your time

    ReplyDelete
  2. Right, the assumption is that there is one user per MAC address or IP address at a time.

    ReplyDelete