1. FireFly: A Reconfigurable Wireless Datacenter Fabric using Free-Space Optics
Navid Hamedazimi, Zafar Qazi, Himanshu Gupta, Vyas Sekar, Samir Das, Jon Longtin, Himanshu Shah, Ashish Tanwer
Hello My name is navid hamed azimi and today I want to talk about FireFly, a wireless data center network using steerable free space optical links
ACM SIGCOMM 2014

2. Datacenter network design is hard!
Performance
Cost
Energy
Cabling
Expandability
Design of data center network is hard since it must satisfy several goals:
High throughput,   
low equipment and management cost,
Incremental expandability, low cabling complexity, power and cooling costs.
Cooling
Adaptability

3. Existing Data Center Network Architectures…
Over subscribed
(e.g. simple tree)
Over provisioned
(e.g. FatTree, Jellyfish) …
Augmented (e.g. cThrough) … u
Add examples to slides.
The current datacenters are either
Overprovisioned with dense core and high cost to account for worst-case traffic patterns, e.g., fat-trees or Jellyfish, or
Oversubscribed e.g., simple trees which are low cost but offer poor performance due to congested links.
Recent work proposed augmenting oversubscribed network with a few reconfigurable links such as 60Ghz RF or optical switches.

4. Our Vision : FireFly Coreless Wireless Steerable ToR switch FireFly
Links
FireFly
Controller
Inspired by augmented wireless architectures, we explore an extreme design called Firefly that pushes this concept to the limits
We completely get rid of the core
We only use wireless links and
All links are Steerable.
The controller steers the wireless links and updates the forwarding tables

5. Potential Benefits of This Vision
Performance
Cost
Coreless
Cabling
Wireless
Cooling
Steerable
Energy
If we CAN do this, there are lots of POTENTIAL benefits
We re getting rid of the core, hence, we reduce cost, and we get a network which is easily expandable if needed
It is all wireless, hence, no cabling complexity
Steerable links facilitate good performance and adaptability to dynamic traffic
Expandability
Adaptability

6. Challenges in Realizing the Vision
Steerable wireless links
Network Design
Network Management
ToR
switch
Steerable
FSOs
FireFly
Controller
THERE ARE SEVERAL KEY challenges in realizing this vision
What technology can we use for steerable wireless link which provides high throughput and
How should we design our network? How many links do we need what is the degree of steerability for each link
What should our controller do, how does routing work, how can we steer the links. What topology do we use and how does it adapt to the traffic?
In this work we show that our vision is in fact WITHIN the realm of possibility!
FireFly shows this vision is feasible

7. Outline Motivation Steerable Wireless Links Network Design
Network Management
Evaluation
Here is the outline of the talk,
First  I am going to talk about Our enabler which is Free space optical links,
after that, we talk about the network design
then network management
and finally evaluation of our Firefly architecture.

8. FSO (Free Space optical)
Why FSO instead of RF?
RF (e.g. 60GHZ)
FSO (Free Space optical)
Wide beam 
High interference
Limited active links
Limited Throughput
Narrow beam 
Zero interference
No limit on active links
High Throughput
Why can’t we use traditional RF in our work? The main reason is that traditional RF uses a wide beam which is very difficult to narrow. This results in high interference on top of the racks which limits bandwidth, range, and number of active links.  
Free space optical links on the other hand give us excellent throughput over long ranges. Plus,  they are easy to narrow which eliminates interference and thus allows many active links.

9. Today’s FSO Cost: $15K per FSO Size: 3 ft³ Power: 30w Non steerable
If you look at the market, the current FSO’s are
expensive, 15k for a single FSO
they take LOTS of space,
they need massive amount of power
and they are not STEERABLE
Current: bulky, power-hungry, and expensive
Required: small, low power and low expense

10. Why Size, Cost, Power Can be Reduced?
Traditional use : outdoor, long haul
High power
Weatherproof
Data centers: indoor, short haul
Feasible roadmap via commodity fiber optics
E.g. Small form transceivers (Optical SFP)

11. FSO Design Overview fiber optic cables Diverging beam
Lens focal distance
Parallel beam
lens
Collimating lens
Focusing lens
Large core fiber optic cables
SFP
ere is the design of a FSO using COMMODITY SFP in FireFly. SFP’s normally are connected using fiber optic cables.
Directly launching the beam from SFP into air results in unacceptable divergence and loss of signal at receiver.
We can stop the divergence of the beam using an optical lens. We put the SFP at the lens focal distance, and we get a collimated parallel beam
At the receiver, we focus this collimated beam into the SFP using another lens
However SFPs are supposed to directly be connected to switch motherboard so putting them at top of the rack is inconvienent
To better manage the system, we launch and receive the optical signal into fiber optic cables
Based on our experiments, we find “big core” 125nm and up fibers would work, SO THAT WE CAN GATHER SUFFICIENT LIGHT
large cores (> 125 microns) are more robust

12. Steerability Shortcomings of current FSOs Cost Size Power FSO design
Not Steerable
FSO design
using SFP
This LINK DESIGN takes care of cost energy and size problem
but we still need to make this links Steerable. We explore two technologies. Switchable mirrors and galvo mirrors.
Say different two different design give us two different options innetwork design
Via Switchable mirrors
or Galvo mirrors

13. Steerability via Switchable Mirror
Switchable Mirror: glass mirror
Electronic control, low latency
Ceiling mirror
SM in “mirror”
mode
Before we talk about switchable mirrors, lets talk about another issue:  if we put all this FSO’s on top of the racks, we will have line of sight problems.
We borrow an idea from prior work and solve the line of sight problem by turning the ceiling into a mirror.
We then can add flexibility by using switchable mirrors. These are mirrors which can be turned into glass and back to mirror by passing a small electric current, we can add several of them for each FSOs each aligned in a different direction.
This pros of these mirrors is that they have electronic control and fairly short switching time in order of several ms. By using a few of them per FSO, we can then steer the link, by switching off all the mirrors
except one. E.g. in this picture, we can steer the link to receiver 2 by switching off all the mirrors except this one B C A

14. Steerability via Galvo Mirror
Galvo Mirror: small rotating mirror
Very low latency
Ceiling mirror
Galvo Mirror
Another technology that we are exploring are galvo mirrors  they are in essential small rotating mirror where mirror can be rotated in a cone of 45 degrees
We only need one per FSO
They are very reliable and have very fast response time (few hundred microseconds to switch a link) Now again in our example, if we want to steer the link to receiver 2
We just have to rotate this mirror to get the link B C A

15. FSO Prototype in Data center
Mirror
Fiber holder and lens

16. FSO link is as robust as a wired link
FSO Link Performance
Effect of vibrations, etc.
6mm movement tolerance
Range up to 24m tested
6 mm
We build our prototype and we measured its performacen, we first measured how sensitive our link is to movement to see how much vibration, bumps into racks, etc. would affect the link. We find out that the link is fairly robust and it can tolerate movement of up to 0.7mm in each direction.
We tested the link range in an actual data center and it worked up to 24 meters. However, this is because in our data center this was the farthest distance. It should in theory work for distances of up to few hundred meters.
We then measure the throughput. Here is the chart of throughput of the link vs throughput of the link on wire, where x is the throughput and y is the cumulative distribution of the throughput. As you can see there is no difference between the wired link and FSO link in throughput.
So in conclusion, FSO link is robust and it almost behave almost exactly as a wired connection.
FSO link is as robust as a wired link

17. Outline Motivation Steerable Wireless Links Network Design
Network Management
Evaluation
Now that we have our candidate steerable wireless link let’s talk about the design of our network.

18. How to design FireFly network?
Goals: Robustness to current and future traffic
Budget & Physical Constraints
Design parameters
Number of FSOs?
Number of steering mirrors?
Initial mirrors’ configuration
Performance metric
Dynamic bisection bandwidth
DYNAMIC GRAPH
New NETWORK DESIGN
NEW ASSEssMENT measure
What is our goal? To build a network which is robust to the current and future traffic patters
What is our constraints, we have budget constraints, the price of this network should be reasonable and we have physical space constraints, how many FSO’s we can feet at top of our racks.
Since we don’t have a network graph our design problem doesn’t fit into any of the traditional network design paradigms. How can we define our problem then? what are design parameters?
The first and most obvious one is how many FSO do we need?
Second is how many steering mirrors, be it Galvo or switchable mirrors do we need?
And the third is that how can we should initially configure our mirrors
Now we have our design parameters but since again we don’t have a network graph, we can’t use traditional assessment metrics s.a. bisection bandwidth in network design?
We define a new metric, dynamic bisection bandwidth which can be used for other augmented architectures as well. You can find the details in the paper. 18

19. FireFly Network Design
# of FSOs = # of Servers
# of Switchable Mirrors = [10-15] for up to 512 racks or
# of Galvo Mirrors = per FSO
Mirror Configuration = Random graph
less than ½ the ports of FatTree
Projected Cost: 40% to 60% lower than FatTree
For FireFly project we use the following values in our design
Number of FSOs are equal to the number of servers
We have 10 to 15 switchable mirrors per FSO, alternatively we can have only one galvo per FSO
Our initial mirror configuration is random graph, for galvos it is still a random graph but there are some additional steps. Please see the paper for the details.
We find out that random graph works surprisingly well 19

20. Outline Motivation Steerable Wireless Links Network Design
Network Management
Evaluation
Now that we have a network, lets talk about how to manage it when its running

21. Network Management Challenges
Reconfiguration
Traffic engineering
Topology control
Correctness during flux
Ceiling Mirror
ToR
switch
Steerable
FSOs
We have a Controller in our network which has two important task
topology control, it will change the network graph if needed and
traffic engineering
Which requires the input of a traffic patter predicator. This two functions are closely related to each other since topology only changes in response to traffic
In addition, our controller should make sure of packet delivery correctness when network is influx t.i. the topology is chaning.
FireFly
Controller 21

22. FireFly Reconfiguration Algorithm
Joint optimization problem
Decouple
Traffic engineering
Topology control
Above is done periodically
In addition: Trigger-based reconfiguration
E.g. Create direct link for large flows
Massive ILP
Max-flow, greedy
Weighted Matching
Topology control and network engineering problems together is a joint optimization problem which is NP
but can be modeled as a massive ILP which is not practical in use
To make it practical, we can decouple the two
For topology control, we can use a maximal matching based algorithm
For traffic engineering, we can use a max flow or greedy algorithm
We can do both of them periodically in fixed intervals
In addition, we can also do trigger based reconfiguration,
For example, we create a direct link or shorter path if we detect a large flow or a congested link in the network

23. Correctness Problems During Flux
Connectivity
Black Holes
Latency
The other problem that we have is packet delivery correctness, since we have a dynamic topology, we have few routing issues,
We have a connectivity issue, we can make a change which entirely disconnects part of the network.
We have an issue with black holes, we have a packet in highlighted node and we disconnect the link without updating the routing table. The node try to send the packet using a link that does
we have a latency issue, as an example here we try to send a packet from A to C but once the packet gets to B the network changes and the packets keeps going forward and backward between A and B and the packets will never gets delivered or it would take a long time A B C

24. Simple Rules To Ensure Correctness
Disallow deactivations that disconnect the network.
Stop using a link before deactivating it
Start using a link only after activating it
“Small” gap between reconfigurations
We can solve all these correctness problems by using the following simple rules.
First, our topology controller never changes a link which results in disconnecting the network,
Second we always change the routing table and stop using a link before deactivating it
Third, we always activate a link before start using it in our routing table
And fourth, we force a small gap between reconfigurations so that the packets in flight get delivered, This fourth rule however was not necessary since all the packets get delivered in our simulations anyway without enforcing it.

25. Outline Motivation Steerable Wireless Links Network Design
Network Management
Evaluation
Now, that we have finished the talk about FireFly, I would talk about the evaluation of Firefly performance

26. FireFly Evaluation Packet-level Flow-level (for large scale networks)
Evaluation of network in-flux
Evaluation of Our Heuristics
Evaluation of the firefly network Steps

27. FireFly Throughput
The first thing we tested is what is the troughput of our system, this chart is packet level simulation of our system compare to fattree and c-Through for 64 racks. The y axis is the throughput per server and x access are the traffic patterns. We use two traffic patterns, hotspot and uniform and 4 hotspots, we used different hotspots percentages 8% and 16%.
As you can see FireFly is comparable to Fattree and better than c-Through over wide range of traffics.
FireFly is comparable to FatTree with less than ½ the ports
Flow completion time better than FatTree

28. Conclusions Vision: Extreme DC network architecture
Fully Steerable, No core switches, All-wireless inter-rack
Unprecedented benefits:
No Cabling, Adapt to traffic patterns, Less clutter
Firefly shows a viable proof point
Practical steerable FSO for datacenters
Practical network design and management heuristics
Close to fat tree performance over several workloads
Less than half of FatTree ports
Just a start .. Many directions for improvement
So to conclusion, We have a challenging problem, designing data center networks,
we have come up with a new architecture, Firefly which is fully flexible, coreless and wireless
The key enabler of our new architecture are the Flexible FSO links
The key challenges of the work was to actually design the flexible FSO links and coming up with new method of managing the network.
And finally, our simulations shows that good over a wide range of traffic patterns