Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises May 12, 2009

(i) the three most important things the paper says

One of the most important ideas that the paper discusses are the changes to the link state protocol.  Most notably, the change that allows SEATTLE to only map the switch locations (instead of mapping individual machines).  This reduces the number of broadcast advertisements sent throughout the network, which helps to address one of the biggest problems with Ethernet and IP.  Another important idea that the paper speaks about is the fact that this scheme can do away with the spanning tree protocol, which will actually allow for more efficiency in switch communication (instead of letting a shortest path go to waste for the sake of configurability).  This is important because the authors are attempting to address one of the weak points of Ethernet, because of the bottlenecks that it could possibly create.  A third important idea that the authors put forth is that this scheme can still function properly while still maintaining end-to-end Ethernet and IP semantics.  This means that only the switching hardware needs to change in order to implement this scheme and all end-host hardware can remain the same.

(ii) the most glaring problem with the paper

One of the biggest problems that I can see with this scheme is the fact that it requires 100% proprietary hardware, and in order to function properly cannot use any traditional hardware.  This requires a user to completely revamp their entire networking system with potentially expensive hardware all at once.  This will make this idea much more difficult to transition to.

(iii) the future research directions of the work

A couple future directions would be useful.  First, reducing the complexity of the hardware would be an option, as this would make the “glaring problem” much more tolerable.  Another option would be to somehow adapt the scheme to work partly with commodity hardware, so that users could gradually move their scheme over (which would probably give this scheme more feasibility).

Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises May 12, 2009

This paper presents a noble solution that could become a practical replacement for the Ethernet. The authors note that while Ethernet is flexible and simple, it does not scale well due to its high reliance on broadcast messages and its inefficient spanning-tree approach. Their aim is to achieve the scalability of the IP networks while keeping the simplicity of Ethernet. They do so by using a dynamic hashing approach, while providing shortest-path routing at the same time. In essence, using SEATTLE could remove the need to use a combination of routers and switches and replace both by SEATTLE switches. SEATTLE has the plug-and-play semantics of Ethernet, without breaking backwards compatibility. The main contributions of the paper are:

1. One-hop DHT approach provides mobility, load balancing, and flexible service discovery: SEATTLE uses consistent hashing to map key-value pairs to switches. Key-value pairs could be of type (ip, mac), (mac, switch id), or (’string id’, switch id). This provides host mobility, as no matter where the host is located on the network, looking up which switch is responsible for resolving its address is discovered by the same simple hash function. A publisher switch publishes this key-value binding for a node connected to it, and the resolver switch (determined by the hash function) stores this value. Switches can act like several virtual switches and thus provide better load balancing: the more powerful switches, or switches with less traffic could hold more virtual IDs, thus hashing more of the key-value pairs to themselves. Also this address resolution method removes the need for routers, thus enabling the SEATTLE switches handle the job of a router and a switch.
2. SEATTLE provides scalability in a large network and offers better utilization of the network links. As opposed to Ethernet, SEATTLE only uses the link-state protocol to communicate between the switches and not end hosts. The switches can use active polling to determine which of their hosts are active, which are disconnected, and monitor for changes in the hosts. This ensures that the service scales well with number of hosts in the network. Link-state also allows the switches to find the shortest path between other switches, thus achieving the same shortest-path principles as Ethernet. Further, since SEATTLE does not use the spanning-tree approach, it can use all available links for routing, as opposed to Ethernet where links not in the spanning tree remain underutilized.
3. Removing broadcast messages: SEATTLE does not forward all broadcast messages. For example ARP messages are handles by the switches, since they already know this information. SEATTLE also takes advantage of ARP messages by sending the location of the switch in addition to the MAC address to the host who initiated the ARP request. Therefore, the host packets can traverse shortest-paths by knowing the location of the destination switch. DHCP messages are handled by the switches as well.

Glaring problems: While one of the aims was to keep simplicity of Ethernet, I think the protocol is more complicated than Ethernet and network operators might hesitate before adapting to a more complicated design like SEATTLE. Also, when a switch leaves or joins the network, the hash function could change, and all key-value pairs must be reassigned again using link-state protocol. Although the hierarchical design tries to tackle this problem, it might be difficult to determine such hierarchy. The solution is desired for large scale networks of many switches. In such networks it might be probable for several switches to join or leave the network periodically. This means that in a large enough network of switches, the hash function would change periodically, and thus the switches would need to communicate their new key-pair values with each other. This would generate a lot of undesirable traffic and might hinder network performance. Also the initial lookup of the resolver switch adds several hops. While this only reduces latency for the first lookup, it might still be a problem if the majority of the network traffic is short-lived bursts to various hosts, requiring constant address resolution.

Future Research: it would be interesting to see performance measurements for a large-scale deployment of SEATTLE (rather than simulation of the same scenario).

Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises May 12, 2009

1. Maintain only switch-level topology

The link state protocol implemented by SEATELL maintains only switch-level topology which is used for forwarding packets at each switch. This, not only reduces the control traffic, it also reduces the control and routing information that needs to be maintained by the network devices. Each switch only maintains information about those hosts directly connected to it.

2. Efficient utilization of hash functions to determine host location.

The paper uses hash functions to determine the switch that would maintain IP-MAC-location mappings of a host. This way, flooding resulting from ARP and DHCP is avoided. It also  provides for consistent hashing which reduces overhead in case a switch maintaining MAC-IP-location mapping of a host goes down due to network failure or a new switch is added to the network. SEATTLE also runs multiple virtual switches on each switch allowing the more powerful switches to handle more load by supporting a larger number of virtual switches.

3. Backward compatible with conventional Ethernet and support for ARP & DHCP

The switches in SEATTLE network are capable of discovering hosts supporting only conventional Ethernet. They learn the new hosts MAC address in the same way Ethernet does and learn its IP by snooping on gratuitous ARP requests. The switches support DHCP and ARP while prevent flooding of the network with the ARP and DHCP traffic.

Drawbacks

The SEATTLE network, while elimination broadcast and control traffic overheads introduces its own set of overheads. The switch that the host is connected to (pulisher switch) needs to monitor the liveliness of the switch that maintains the hosts mapping information (resolver switch) through link state advertisements. In case of hierarchiacal implementation of SEATTLE, each publisher switch needs to send periodical probes to backbone resolvers that lie outside its reagion. There is also the triangle problem that might arrise. The looks like a trade-off between latency and state maintaining overhead.

Future work

The idea can be extended to support mutiple protocols. It can be enhanced to provide for greater security that is an important concern in enterprise networks.