SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Incremental Consistent Updates

guri avatar
guri
37 diapositives · 546 Views · Jul 27, 2014

Incremental Consistent Updates. Naga Praveen Katta Jennifer Rexford, David Walker Princeton University. Network Policy. Policy : C ollection of Openflow rules in the entire network. === === ===. === === ===. === === ===. 2. 1. 1. 1. 2. 2. 1. 2. === === ===.

Incremental Consistent Updates - slide 1
01 / 37Incremental Consistent Updates
1 / 17

Télécharger la présentation

Incremental Consistent Updates
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. Incremental Consistent Updates Naga Praveen Katta Jennifer Rexford, David Walker Princeton University

  2. Network Policy Policy : Collection of Openflow rules in the entire network === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  3. Policy Update From old policy === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  4. Policy Update From old policyto new policy === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  5. Inconsistent policy during transition === === === === === === === ====== === === === === === 2 1 1 1 2 2 1 2 === === === === === ===

  6. Inconsistent policy during transition === === === === === === === ====== • Per Packet Consistency (Reitblatt et. al. SIGCOMM’12) • A packet sees either exclusively the old policy or exclusively the new policy. === === === === === 2 1 1 1 2 2 1 2 === === === === === ===

  7. Both old and new policy on the network 2 1 1 1 2 2 1 2

  8. 100% space overhead in intermediate steps 2 1 1 1 2 2 1 2

  9. 100% space overhead in intermediate steps • Problem Statement • Can we do a consistent update with less space? 2 1 1 1 2 2 1 2

  10. Trade Space for time Less space overhead but more update time Goals General : Works for any policy (with ternary matches) Efficient : No packet-processing overhead on the controller

  11. Trade Space for time Less space overhead but more update time Goals General : Works for any policy (with ternary matches) Efficient : No packet-processing overhead on the controller • Divide entire update into multiple rounds • Each round is assigned a set of predicates (predicate : a symbolic ingress packet) • Eachround updates policy slice for assigned predicates • Slice : rules effecting the packets of a predicate

  12. Update the policy slice by slice === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  13. Update the policy slice by slice === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  14. Update the policy slice by slice === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  15. Update the policy slice by slice === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  16. Update the policy slice by slice === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  17. Update the policy slice by slice === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  18. Update the policy slice by slice === === === • Given a predicate, how do you compute the slice? • How do you update the network with policy slices? • How do you assign predicates to slices? === === === === === === 2 1 1 1 2 2 1 2 === === ===

  19. 1. Computing a slice for a given predicate • Collect matching rules from all switches?

  20. Challenges in computing a slice Header Modifications Multiple predicates match a single rule Packets of predicate never reach a switch. 01->11 01 11 01 0* 11 01 01 01 01

  21. Compute policy slice using symbolic execution Similar to Header Space Analysis (NSDI 2012) 2 1 1 1 2 2 1 2

  22. Compute policy slice using symbolic execution 2 1 1 1 2 2 1 2

  23. Compute policy slice using symbolic execution === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  24. Similarly computethe old slice === === === === === === === === === 2 1 1 1 2 2 1 2 === === ===

  25. 2. Update policy slice– Add the new slice === === === === === === === === === === === === 2 1 1 1 2 2 1 2 === === === ===

  26. Thenremove the old slice? === === === === === === === === === === === === 2 1 1 1 2 2 1 2 === === === ===

  27. Difficult with multiple dependent predicates Cannot remove 1* rule till both 10and 11migrate 10 -> 2 10 -> 1 11 -> 2 1* -> 1 2 1 1 1 2 2 1 2 11 -> 2

  28. Difficult with multiple dependent predicates Cannot remove 1*rule till both 10and 11migrate • Keep track of all dependent predicates • Add a new rule as soon as anynew slice needs it • Delete an old rule as soon as noold slice needs it 00 -> 2 00 -> 1 01 -> 2 0* -> 1 2 1 1 1 2 2 1 2 11 -> 2

  29. 3. Choosing the predicates? Optimal order of updates How many slices in total? Which predicates in which slice?

  30. Choosing the predicates Divide Ningress predicates into K ordered slices optimally Avoid exponential preprocessing Cannot consider slices in isolation

  31. Choosing the predicates Divide Ningress predicates into K ordered slices optimally Avoid exponential preprocessing Cannot consider slices in isolation Pose it as a Mixed Integer Program Combine individual predicate symbolic analyses Encode dependency counting • Trade-off dimensions • Rule space overhead • Update time (# rounds/slices) • Trafficvolume of migrated rules

  32. Evaluation Fattree topology - 24 Switches, 576 hosts Load Balancer Policy Each client chooses server randomly Packet modification at the ingress Shortest path forwarding to servers Optimization solver Always within 1% in few (~5) seconds

  33. Overhead decreases significantly with increased rounds Consistent Updates Space Overhead (%) Total number of slices

  34. Minimizing update times finishes in just 9 slices Number of slices updated Number of slices updated Switch space overhead capped at 5%

  35. 80% traffic migrates in slice 1 and 99% in 3 slices Number of slices updated Switch space overhead capped at 5%

  36. Conclusion • Policy abstractions come with a cost • How to implement efficiently? • Keeping the essence of abstraction • Optimizing consistent updates • Slice by slice policy update • Symbolic execution and MIP reduction • Uses less rule space • Moves high volume flows early

  37. Questions? Naga Praveen Katta nkatta@cs.princeton.edu