High-Fidelity Switch Models for SDN Emulation

1. High-Fidelity Switch Models for SDN Emulation Danny Y. Huang Kenneth Yocum Alex C. Snoeren University of California, San Diego

2. Buying OpenFlow Switches Clients Which one to buy? HP Procurve Fulcrum Monaco Quanta LB4G

3. Buying OpenFlow Switches 30% queries timed out Clients

4. Buying OpenFlow Switches Clients

5. Buying OpenFlow Switches Clients Same topology. Same workload. Different performance!

6. Buying OpenFlow Switches Performance Variations Clients x 1,000 = How to predict the performance? Which one to buy?

7. Emulating OpenFlow Networks OVS itself would also introduce performance variations. Simulators / Emulators Data Plane Data Traffic Control Plane Mininet Open vSwitch OpenFlow Controller

8. Problem Hard to predict OpenFlow network’s performance: • OpenFlow Switches are different. • Existing emulation framework is not good enough. Goal To predict performance with realism: • To design an emulator that captures vendor variations. • To measure these variations in the control plane.

9. Variations across Vendors Differences in Control Plane Flow table size Flow management policies Switch CPU etc Controller OpenFlow Protocol Focus on CPU’s effect on control-path delays. Data Traffic

10. Control-Path Delays Disproportionately affects short flows. Controller (POX) Packet-in Events Flow-mod Events Hardware OpenFlow Switch Egress Delay Ingress Delay CPU TCAM Ingress Egress Data plane traffic Application Workload

11. Measure Control-Path Delays Installs rules for every new flow Server Control Plane HP Procurve Fulcrum Monaco Quanta LB4G Open vSwitch (OVS) Eth 0 Eth 1 Eth 2 Controller OF Switch Data Plane Clients Queries for a 64-byte value every 50 ms. We measure the query time, ingress & egress delays.

12. Measure Redis Query Times Query completion times for Redis clients (ms)

13. Measure Ingress Delay OVS faster thanthe others.

14. Measure Egress Delay OVS: almost no delays! Slow down the ingress and egress delays on OVS to emulate the hardware

15. Implementing the Emulator Controller (POX) To slow down control traffic Packet-in Events Flow-mod Events Open vSwitch (OVS) Ingress Egress Data plane traffic Application Workload

16. Emulator Proxy Controller (POX) Packet-in Events (Delayed) Flow-mod Events Physical OF Switch ≈ Emulator Proxy Flow-mod Events (Delayed) Packet-in Events Open vSwitch (OVS) Ingress Egress Data plane traffic Application Workload

17. Evaluation HP CDF Query completion time for Redis clients (ms) OVS Hardware Emulated

18. We emulate the ingress and egress delays only. • Reasonble approximation. Evaluation HP CDF Monaco Query completion time for Redis clients (ms) Quanta Query completion time for Redis clients (ms) OVS Hardware Emulated Query completion time for Redis clients (ms)

19. Summary Future Work Increase realism. Capture more artifacts. Expand workload coverage. Automate switch measurements. Capture interactions among multiple switches. • Hard to predict performance due to vendor variations. • We designed an emulator for control-path delays. • Simple, but achieves reasonable approximation. Acknowledgements Marco Canini and Dan Levin (TU Berlin) George Porter (UC San Diego)

20. Thank you!

21. Inverse Transform Sampling • Goal: Emulate switch X, which introduces ingress delay t with probability p. • Algorithm: • Measure the delay distributions of OVS and X. Make them into tables. • Measure how much OVS has delayed. Call this tOVS. • Look up tOVS from the OVS table. This returns probability p. • Look up p from X’s table. This returns delay tX. • Introduce delay (tX - tOVS).

22. Evaluation (QQ Plots) Quanta Monaco HP Time on Emulator (ms) Query completion time on hardware switches (ms)

23. Time Dilation