Session 7, Paper 1: RotorNet: A Scalable, Low-complexity, Optical Datacenter Network

William M. Mellette, Rob McGuinness, Arjun Roy, Alex Forencich, George Papen, Alex C. Snoeren, and George Porter (UC San Diego)

[Link to Paper]

William Mellette proposes a new switching model called RotorNet, which is a "future-proof" switching model. Bandwidth has been increasing in production data-centers, and 100+ petabit/second networks are projected to be needed in coming years. The challenge is to deliver low-cost bandwidth at scale. This has spurred work for new protocols, new topologies, and new hardware. However, all this work has fixed the switching model. Bandwidth demands for data-centers are doubling every year, and our current switches are not improving fast enough (doubling every 2 years). Electronic packet switches have I/O limits, whereas optical circuit switches can scale to Tb/s. 

However, optical switches have significant control complexity. The "Rotor" switching model eliminates this complexity. Rotor switching makes two changes to the crossbar-switching model:

1. For an N-port switch, the switch can only select from N-1 matchings.
2. The switch's matchings are run on a fixed schedule.

The implementation of an optical rotor switch is simpler than an optical crossbar, as mirrors only have to select from hard-coded matchings rather than implementing the matchings themselves. For a 2048-port switch, an optical crossbar switch would need 4,096 mirrors that could tilt in 2,048 directions while an optical rotor switch would need 2 mirrors that could tilt in 16 directions. This does come with a concern for network underutilization. Mellette proposes RotorLB as an adaptation between 1- and 2-hop forwarding, that defaults to 1-hop forwarding and sends traffic over 2-hops when there is extra capacity. Mellette goes on to show how Rotor switching performs:

This work is significant as it proposes a model that greatly simplifies the implementation of optical switching networks. To address the issue of scaling, Rotor matchings are distributed among multiple switches, making rotor switches easier to build. Below is an image of a prototype Rotor switch built from commodity hardware:

To wrap up, RotorNet is a promising way to scale datacenter networks to the bandwidth that we will need in the next few years.

Q: How do the switches stay in sync?

A: We just need to ensure synchronization between the switches, and they follow the set schedule for rotating matchings.

Q: What is the ordering of packets that are transmitted?

A: There will be reordering (due to traffic taking 1 or 2 hops), our approach is to have a reorder buffer at the receiver.

Q: What is the format that packets are stored in buffers?

A: We hash the packets to be stored on the end hosts.

Q: How do you do 2000 ports? Do you still only use 2 mirrors?

A: There are a number of different ways to implement the rotor switch at the physical layer. At 2000 ports  you can have a large mirror or a mirror array. Options are being investigated.