CAP for Networks

Talk I gave for ONF's CTO Summit at Stanford.

Paper: http://www.eecs.berkeley.edu/~rcs/research/cap-paper.pdf

Transcript

1. Aurojit Panda, Colin Scott, Ali Ghodsi, Teemu Koponen, Scott Shenker CAP for Networks UC Berkeley, KTH, VMware, ICSI
2. CAP Theorem When distributed systems face network Partitions pick one of •Service Correctness (Consistency) •Service Availability
3. CAP Theorem: Impact Divides the database community (even today) NoSQL Availability above all SQL Correctness above all
4. How does the CAP theorem apply to networks?
5. Our goal: articulate fundamental tradeoffs networking will face
6. Traditional Networks When intradomain routing was the main concern •Correctness: Deliver packets to destination •Availability: Deliver packets to destination •Correctness is the same as Availability
7. The move to SDN SDN provides more sophisticated functionality: •Tenant isolation (ACL enforcement) •Traffic Engineering •Virtualization Control plane partitions no longer imply data plane partitions •Control traffic often does not use data plane network
8. Availability ≠ Correctness During control plane partitions •Data plane connected => Deliver packets (Availability) •Inconsistent control plane data (Correctness) •Availability does not imply Correctness
9. How does the CAP theorem apply to networks SDN?
10. How does the CAP theorem apply to networks SDN? Can one provide isolation and availability in the presence of control plane partitions?
11. Network Model • Out-of-band control network. • Routing and forwarding based on addresses. • Policy specification using end-host names. • Controller responsible for local name-address bindings. Controller 1 Switch A 10.1.1.1 Controller 2 B 10.1.1.2 Switch C 10.1.2.1 D 10.1.2.2 A 10.1.1.1 B 10.1.1.2 C 10.1.2.1 D 10.1.2.2
12. 10.1.1.1 ! 10.1.2.1 Isolation Result • Consider policy isolating A from B. • A control network partition occurs. • Only possible choices •Let all packets through (including from A to B) (Correctness) •Drop all packets (including from A to D) (Availability) A 10.1.1.1 B 10.1.1.2 D 10.1.2.2 B 10.1.2.1 10.1.1.1 ! 10.1.2.2 Controller 1 Controller 2 Switch Switch A 10.1.1.1 B 10.1.1.2 A 10.1.1.1 D 10.1.2.2 D 10.1.2.2 B 10.1.2.1
13. Value of Model Practical workarounds follow directly
14. Workarounds for Isolation •Identity-Address disconnect underlies isolation result ! !
15. Workarounds for Isolation •Identity-Address disconnect underlies isolation result ! •Network can constrain address allocation
16. Workarounds for Isolation •Identity-Address disconnect underlies isolation result ! •Network can route on identity rather than addresses
17. Workarounds for Isolation •Identity-Address disconnect underlies isolation result ! •Use in-band control networks rather than out-of-band
18. Workarounds not General Edge Disjoint Traffic Engineering • Two flows must traverse disjoint links S1 C1 S2 S3 S4 C3 C2 L0 L1 L2 L3 L4 L5 A B D E
19. Workarounds not General Previous workarounds not applicable! S1 C1 S2 S3 S4 C3 C2 L0 L1 L2 L3 L4 L5 A B D E
20. Can one provide correctness and availability in the presence of partitions? Not in general
21. In the Paper “CAP for Networks”, HotSDN ‘13 • More policies and proofs • More details on workarounds • Other ways to model the network
22. CAP for Networks Choices for network architects Availability above all Correctness above all ICING VMware NSX BGP Traditional Routing Policy-Specific Workarounds Packet Labeling In-Band Control
23. Backup Slides
24. Host Migration •Our model assumes host migrations without controller involvement. •In part this is because host migrations are common •Soundararajan and Govil 2010: 6 migrations/day/VM •In a datacenter ~480,000 migrations/day •5.5 migrations per second •Controller involvement is too expensive in datacenters •NSX and BSC work in a similar manner •In enterprises controller involvement complicated by mobility.