Ethane: Taking Control of the Enterprise May 5, 2009

(i) the three most important things the paper says

One of the most important observations of the claims in the paper, although subtle, seems to be the claim that current computer hardware is advanced enough to handle a moderately-sized network’s worth of traffic from a central point.  This is a point that has been shown as false in the past, as the traffic alone is usually enough to congest the single host.  This claim seems quite radical.  Another important observation is that the switches themselves, due to the centralized control in Ethane, can be very simple–other than the massive amount of storage required for flow tables.  This means, as the authors claim, that ASICs can be designed that are much cheaper to develop and manufacture (and thereby would also be cheaper for the consumer).  This means that expanding a network may not be as expensive as it is currently, assuming that the current central hardware is advanced enough to handle the extra traffic to be generated.  Lastly, the observation that all communication can be tracked using flows brings a different view to how one can manage a network.  This takes away a bit of the complexity of having to access rules for each packet that goes through a switch.  Instead, the packet can be analyzed deeply once and then a simple lookup can be done to verify that the transmission can proceed.  This could greatly simplify the computing requirements of each switch.

(ii) the most glaring problem with the paper

The biggest problem with the paper is that it doesn’t function as well with broadcast-based traffic.  Specifically, the paper mentions ARP and other similar discovery protocols.  My biggest problem with this observation is what would happen if an entire network failed and needed to be completely cold-restarted (say, a power outage).  It would seem that this system could be inundated with ARPs, etc. and the delay in getting each workstation/server/etc. back online would take quite some time.  The paper also doesn’t address stressing the network with a flood of ARP requests and whether or not this would hinder the operation of the switching or control hardware.

(iii) the future research directions of the work

The authors did a great job in pinpointed what still needed to be fixed with the system.  Before listing my own ideas for research directions, it seems that the project should fix the kinks that are present now (a network without broadcast protocols using just Ethane constructs, more realistic switch memory sizing, dynamically loaded rulesets, fully-redundant control hardware/software, etc.).  One observation that I came across that would merit further research are the semantics of the policy language itself.  The language seems quite cumbersome and not clear to read (human-readably, at least).  It would seem that this file could get very cluttered quite quickly.  Some work in this area would greatly simplify how this language works and would make it much easier for operators/administrators to edit this file.  Another future research topic would include using this hardware on a larger, more demanding enterprise network to explore the demands on the switching hardware in a more stressful environment.  Lastly, some more security research could be in order.  Maybe some more software could be developed for end-hosts that would try to guarantee a more end-to-end coverage would be a good research direction.

Ethane: Taking Control of the Enterprise May 5, 2009

This paper presents the Ethane system, which is designed to manage an enterprise security policy in an efficient and easy-to-use fashion. It does this by providing a centralized point (or points, in the case of cold/warm backups or full replication) which contain all of the policy information and create flows through which network data travels between hosts.

The three most important things the paper says are:

1. Even though it is counter to the traditional network management mantra, maintaining a centralized policy has many advantages. It simplifies monitoring traffic and authenticating users, and ensures that all of the policies which were traditionally implemented by filters and firewalls distributed throughout the network are actually affecting traffic in the desired fashion. This is primarily because all flows (or at least the first packets from all flows) are rerouted to the controller. Any packet belonging to an unregistered flow is either dropped or routed to the controller, and thus it is impossible for traffic to escape the policies implemented on the router. A centralized authority is made possible by the fact that modern hardware is very powerful (i.e. one controller can manage many thousands of end users) and the fact that the controller is only involved in the establishment of the flow, with all other traffic (assuming the flow is approved and installed) being routed directly (and efficiently, another benefit of an omniscient controller) from end user to end user.
2. The use of a flow-based system allows the Ethane switches throughout the network to be much simpler than a traditional Ethernet switch. While it is possible to optimize them by adding multiple queues for different traffic classes or implementation-specific flow entries to reduce traffic to the controller, the Ethane switch is mostly comprised of just a flow entry table, which consists of much less state than all of the routing tables found in a traditional Ethernet switch. Further, even though the Ethane switch is simpler, not all switches need to be switched from Ethernet to Ethane immediately, since the controller will still manage the spanning tree if it contains traditional Ethernet switches.
3. Network policy is most effective when it is maintained over high-level names. One of the handy features of the Ethane controller is that it binds hosts and users together in a centralized location. This makes auditing connections much more straightforward since there is a permanent record of which user was using which host at a given location in the network (switch port) at any point in time. In addition to making auditing much easier, it makes maintaining the policy information much more straightforward as well, since it provides flexible ways to restrict or allow classes of traffic.

I believe the most glaring problem with this paper is that, even though Ethane is an elegant solution for network policy management, and it can be implemented without immediately switching all Ethernet switches to Ethane switches, there is still a deployment issue. All of the custom hardware deployed by enterprises already has security policies built in, and it is quite possible that the combination of transferring these policies to Ethane and then deactivating them (to avoid conflicts or lost traffic) could cost a considerable amount of resources to ensure that no functionality is lost either by under- or over-restrictive end policies.

While they did implement this system on their 300-host network for a few months and provided data which indicated that Ethane would easily scale to many thousands of users, I think one avenue of future research would be to actually implement it on a sizable network. It is possible that there are issues at the 1000+ host count which were not foreseen on the 300-host network. Another research path would be to determine which “value-added” features to add to the Ethane switches to provide better network performance (in throughput, traffic reduction, latency, etc.) while still maintaining their simplicity, which is valuable if hardware is going to be produced. They mention adding multiple queuing to the switches, but it would be interesting to see what kinds of queues provide the greatest benefit.

Can Software Routers Scale? April 30, 2009

(i) The three most important things the paper says:

1) The current school of research that assumes that software routers adopt a “single server as a router” will never be feasible. Instead the idea of a “clustered software router” solution shows more promise. The rest of the paper then discuss how this can be achieved with specific algorithms and conventional PC architecture.

2) Pin pointing the bottleneck of current conventional PCs that limit the performance at the FSB. Since they are arguing for the use of conventional PCs, this point immediately allows follow up research into how to solve this problem and make an improvement in the performance. Furthermore, they even propose non-radical software and hardware already in this paper.

3) Observation that a conventional PC cannot hope to scale a PC to the speed of a centralized scheduler. Although this may be seemingly trivial, it is actual very thought provoking, since it incites research to look for alternatives instead of doing the same thing as a centralized scheduler. Later in the paper, they even mention specific possibilities, such as interconnecting PCs to form a switching or sorting network.

(ii) The most glaring problem with the paper:

Although a lot of analysis was put into comparing different switching solutions, the paper would have benefited with some actual experimentation. Without experimentation, there may be unforeseen issues that they missed when comparing with pure calculations.

(iii) The future research directions of the work:

A good area for future research is to consider how conventional PCs can be used to beat dedicated hw routers. Since, even if the ideas proposed in this paper are successful and they manage to match speeds of dedicated HW, it may not be enough incentive for users to change. Because changes cost money, and users would only change if there was a compelling reason such as speed improvement or cost reduction.

IP Switching: ATM Under IP April 9, 2009

The main contribution is that ATM switches can be modified to provide level-3 IP routing using hardware. This results in utilizing less expensive hardware to provide higher performance IP routing. The authors identify that while IP is connectionless, many protocols and applications that run on IP do behave as though a virtual connection exists for some period of time. Thus, the existence of a switched connection under IP will benefit many applications. It seems that previous attempts to run IP over ATM did not exploit the connection-based nature of ATM.

Some key details of this approach include flow classification, the use of soft state, and a timeout mechanism. Flow classification allows the IP switch to identify which packets represent a flow between two hosts. An identified flow suggests that packets will be exchanged between the same two hosts because they are engaged in some type of application based conversion/exchange. The authors admit that many flow classification schemes are possible. They chose to identify flows in two ways: between hosts with the same TTL and between hosts with the same port (service-type) and TTL. In the former case, flows were established only after a number of packets were exchanged. In the latter case, flows were setup immediately (as the service types are known). Once a flow is established, the routing no longer involved store-and-forward processing via IP software. The routing was accomplished by switching packets based on setup virtual ATM circuits.

Soft state is employed to provide a cache-like mechanism for each IP switch. When flows are being established, some cached packet history is needed. Similarly, when the flows are established, they need to be tracked so that they can maintain the virtual ATM circuits. However, because each IP switch is autonomous and may fail at any time, this soft state is not absolutely required. It can be rebuilt if lost. Moreover, it is designed to be updated dynamically as the topology and traffic changes.

This leads to the last key detail, the use of timeouts. Each flow is established for a limited amount of time. This prevents virtual ATM circuits from being permanently allocated. If however a flow is continually used, the IP switches will periodically refresh the flow lifetime to keep it alive. This approach allows flows to not consume too many ATM resources and still provide switching for those flows that need it.

Although performance simulations are provided (based on Internet and corporate traces), there is no performance comparison between other IP routing approaches. Several different approaches are described. Based on the descriptions it seems rather glaring that no performance evaluation was done to identify how viable an alternative this IP over ATM approach really is.

Although it appears that crossbar switch based IP routing as won out, I’d expect further research in this area to involve exploring the multicasting benefits that ATM switches may be able to confer. It seems that given the inherent point to many architecture of these devices that they may be able to out perform traditional crossbar switching.