Thursday, September 17, 2009

Floodless in SEATTLE

C. Kim, M. Caesar, J. Rexford, "Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises," ACM SIGCOMM Conference, (August 2008).

This paper describes a network architecture called SEATTLE (Scalable Ethernet Architecture of Larger Enterprises) which aims to achieve the scalabilty of IP combined with the simplicity of the Ethernet. The most important aspect of SEATTLE was its plug and play functionality as well its ability to simultanously operate with existing infrastructure and protocols.

The paper started off by discussing the problems of Ethernet bridging (namely inflexible route selection and its dependence on broadcasting for basic operations), Hybrid IP (configuration overhead due to hierarchical addressing, complexity encoutered in implementing network policies and its limited support for mobility if end hosts) and Virtual LAN (Trunk configuration overhead, limited control-plane scalability and insufficient support for richer topologies).

The authors then proposed a system for a network layer one-hop DHT. The concept was to use link state protocol on the switch level to ensure that each switch knows others' position in the network. Now, each end node was hashed based on its MAC and IP addresses on other switches. The idea was that whenever a request came to a switch, it computed the hash of the IP address of destination and queried the switch which resulted. This switch had the location of the switch in whose domain the destination host belonged and the packet was routed to it. Moreover, the value was cached for further tranmissions on source node's switch. The logic behind this was the observation that most of the communications in the modern Internet involved communicating with a small fixed number of destinations. Further, it also enabled flexible service discovery as services like "PRINTER", "DHCP_SERVER" could also be cached in a similar manner on the switches. The system was also much more lenient to topology changes by communicating between switches and upldating key value pairs. Further, the authors discussed about the scalability of the system by proposing a multi-level one hop DHT by defining a separate regional and backbone hash ring. Finally a simulations study was provided based on real-world traffic traces using Emulab to evaluate using Click and XORP routing platforms.

Overall, this paper is very straightforward in its approach and clearly discusses about the current scenario in enterprise networks.  It does an impressive job in tackling out many of the issues that affect the scalability of current networks which rely a lot on broadcasts and flooding as a means of path detection. However, I felt that the authors gave a very fledgling insight in the hierarchical multi-level one-hop DHT. Since the boundary level switch ring has to maintain hash values of each and every host, this puts a question on the size of the enterprise networks that the authors were targeting. Somehow, it was not really clearly defined by the authors. Further, it would have been great if the authors had discussed about the cost/feasibility of the smart switches in the protocol too.

3 comments:

  1. I also thought there needed to be more discussion of the multi-level DHT. While partitioned DHTs have been looked at before, I think managing one would present a number of the same challenges that the small LAN connected by IP approach has. For example, every subnet would need to know about every other subnet, or would have to go up to some 'root' subnet, which would either mean big routing tables, or a lot of load on the root.

    ReplyDelete
  2. I agree that there are ultimately some real scalability issues in their approach. I have to say that nobody seriously believes that the proposal will be implemented in any operational datacenter any time soon.

    ReplyDelete
  3. I completely agree. In the paper they mentioned about taking the former approach, that is having big routing tables. Now as mentioned in VL2 paper, a cheap switch can have upto 16,000 routing table entries. This imposes a further question on the cost-to-benefit ratio of larger switches.

    ReplyDelete