CAP for Networks Or: How to Stop Worrying and Embrace Failure= - - PowerPoint PPT Presentation

▶
cap for networks
SMART_READER_LITE
LIVE PREVIEW

CAP for Networks Or: How to Stop Worrying and Embrace Failure= - - PowerPoint PPT Presentation

Mar 27, 2023 367 likes •706 views

CAP for Networks Or: How to Stop Worrying and Embrace Failure= Aurojit Panda, Colin Scott, Ali Ghodsi, Teemu Koponen, Scott Shenker UC Berkeley, KTH, VMware, ICSI Keshav raps about SDN CAP Theorem In the presence of network P artitions pick

slide-1
SLIDE 1

Aurojit Panda, Colin Scott, Ali Ghodsi, Teemu Koponen, Scott Shenker

CAP for Networks

UC Berkeley, KTH, VMware, ICSI

Or: How to Stop Worrying and Embrace Failure=

slide-2
SLIDE 2

Keshav raps about SDN

slide-3
SLIDE 3

CAP Theorem

In the presence of network Partitions pick one of

  • Service Correctness
  • Service Availability
slide-4
SLIDE 4

CAP Theorem: Impact

Divides the database community (even today)

NoSQL Availability above all SQL Correctness above all

slide-5
SLIDE 5

How does the CAP theorem apply to networks?

slide-6
SLIDE 6

What about Networks?

slide-7
SLIDE 7

What about Networks?

Traditionally connectivity was the only concern

  • Correctness: Deliver packets to destination
  • Availability: Deliver packets to destination
  • Correctness is the same as Availability
slide-8
SLIDE 8

The move to SDN

slide-9
SLIDE 9

The move to SDN

SDN provides more sophisticated functionality:

  • Tenant isolation (ACL enforcement)
  • Fine grained load balancing
  • Virtualization
slide-10
SLIDE 10

The move to SDN

SDN provides more sophisticated functionality:

  • Tenant isolation (ACL enforcement)
  • Fine grained load balancing
  • Virtualization

Control plane partitions no longer imply data plane partitions

  • Control traffic often does not use data plane network
slide-11
SLIDE 11

Availability ≠ Correctness

During control plane partitions

  • Data plane connected => Deliver packets (Availability)
  • Inconsistent control plane data (Correctness)
  • Availability does not imply Correctness
slide-12
SLIDE 12

How does the CAP theorem apply to networks SDN?

slide-13
SLIDE 13

How does the CAP theorem apply to networks SDN?

Can one provide correct isolation and availability in the presence of link failures?

slide-14
SLIDE 14

Network Model

  • Out-of-band control network.

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

slide-15
SLIDE 15

Network Model

  • Out-of-band control network.
  • Routing and forwarding based on addresses.

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

slide-16
SLIDE 16

Network Model

  • Out-of-band control network.
  • Routing and forwarding based on addresses.
  • Policy specification using end-host names.

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

slide-17
SLIDE 17

Network Model

  • Out-of-band control network.
  • Routing and forwarding based on addresses.
  • Policy specification using end-host names.
  • Controller only aware of 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

slide-18
SLIDE 18

Isolation Result

  • Consider policy isolating A from B.

A 10.1.1.1 B 10.1.1.2 D 10.1.2.2 Controller 1 Controller 2

Switch Switch

A 10.1.1.1 B 10.1.1.2 D 10.1.2.2

slide-19
SLIDE 19

Isolation Result

  • Consider policy isolating A from B.
  • A control network partition occurs.

A 10.1.1.1 B 10.1.1.2 D 10.1.2.2 Controller 1 Controller 2

Switch Switch

A 10.1.1.1 B 10.1.1.2 D 10.1.2.2

slide-20
SLIDE 20

Isolation Result

  • Consider policy isolating A from B.
  • A control network partition occurs.

A 10.1.1.1 B 10.1.1.2 D 10.1.2.2 B 10.1.2.1 Controller 1 Controller 2

Switch Switch

A 10.1.1.1 D 10.1.2.2 B 10.1.2.1

slide-21
SLIDE 21

Isolation Result

  • Consider policy isolating A from B.
  • A control network partition occurs.
  • Only possible choices

A 10.1.1.1 B 10.1.1.2 D 10.1.2.2 B 10.1.2.1 Controller 1 Controller 2

Switch Switch

A 10.1.1.1 D 10.1.2.2 B 10.1.2.1

slide-22
SLIDE 22

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)

A 10.1.1.1 B 10.1.1.2 D 10.1.2.2 B 10.1.2.1 Controller 1 Controller 2

Switch Switch

A 10.1.1.1 D 10.1.2.2 B 10.1.2.1

slide-23
SLIDE 23

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 D 10.1.2.2 B 10.1.2.1

slide-24
SLIDE 24

Workarounds for Isolation

  • Identity-Address disconnect underlies isolation result
slide-25
SLIDE 25

Workarounds for Isolation

  • Identity-Address disconnect underlies isolation result
  • Network can label packets with sender’s identity
slide-26
SLIDE 26

Workarounds for Isolation

  • Identity-Address disconnect underlies isolation result
  • Network can label packets with sender’s identity
  • Route based on identity instead of address
slide-27
SLIDE 27

Workarounds not General

Edge Disjoint Traffic Engineering

  • Two flows must traverse disjoint links
  • Requires consistent topology across controllers
slide-28
SLIDE 28

Can one provide correct isolation and availability in the presence of link failures?

slide-29
SLIDE 29

Can one provide correct isolation and availability in the presence of link failures?

Not in general

slide-30
SLIDE 30

In the Paper

  • More policies and proofs
  • More details on workarounds
  • Other ways to model the network
slide-31
SLIDE 31

CAP for Networks?

Choices for network architects

Availability above all Correctness above all

ICING? Security Policies? BGP Traditional Routing? NOX Routing

slide-32
SLIDE 32

Backup Slides

slide-33
SLIDE 33

Host Migration

  • Our model assumes host migrations without controller involvement.
  • In part this is because host migrations are surprisingly 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
  • NVP and Floodlight work in a similar manner
  • In enterprises controller involvement complicated by mobility.