Hierarchical Policies for Software Defined Networks Andrew Ferguson, Arjun Guha, Chen Liang, Rodrigo Fonseca, and Shriram Krishnamurthi 1
Particpatory Networking 2
3
4
5
TCP Nice: A Mechanism for Background Transfers Arun Venkataramani Ravi Kokku Mike Dahlin Laboratory of Advanced Systems Research Department of Computer Sciences University of Texas at Austin, Austin, TX 78712 arun, rkoku, dahlin @cs.utexas.edu Abstract bandwidth consumption and possibly disk space for im- proved service latency [15, 18, 26, 32, 38, 50], improved Many distributed applications can make use of large availability [11, 53], increased scalability [2], stronger background transfers transfers of data that humans consistency [53], or support for mobility [28, 41, 47]. are not waiting for to improve availability, reliability, Many of these services have potentially unlimited band- latency or consistency. However, given the rapid fl uc- width demands where incrementally more bandwidth tuations of available network bandwidth and changing consumption provides incrementally better service. For resource costs due to technology trends, hand tuning the example, a web prefetching system can improve its hit aggressiveness of background transfers risks (1) compli- rate by fetching objects from a virtually unlimited col- cating applications, (2) being too aggressive and inter- lection of objects that have non-zero probability of ac- fering with other applications, and (3) being too timid cess [8, 10] or by updating cached copies more fre- and not gaining the bene fi ts of background transfers. quently as data change [13, 50, 48]; Technology trends Our goal is for the operating system to manage network suggest that “wasting” bandwidth and storage to im- resources in order to provide a simple abstraction of near prove latency and availability will become increasingly zero-cost background transfers. Our system, TCP Nice, attractive in the future: per-byte network transport costs can provably bound the interference in fl icted by back- and disk storage costs are low and have been improv- ground fl ows on foreground fl ows in a restricted network ing at 80-100% per year [9, 17, 37]; conversely net- model. And our microbenchmarks and case study appli- work availability [11, 40, 54] and network latencies im- cations suggest that in practice it interferes little with prove slowly, and long latencies and failures waste hu- foreground fl ows, reaps a large fraction of spare net- man time. work bandwidth, and simpli fi es application construction Current operating systems and networks do not provide and deployment. For example, in our prefetching case good support for aggressive background transfers. In study application, aggressive prefetching improves de- particular, because background transfers compete with mand performance by a factor of three when Nice man- foreground requests, they can hurt overall performance ages resources; but the same prefetching hurts demand and availability by increasing network congestion. Ap- performance by a factor of six under standard network plications must therefore carefully balance the bene fi ts congestion control. of background transfers against the risk of both self- interference , where applications hurt their own perfor- 1 Introduction mance, and cross-interference , where applications hurt other applications’ performance. Often, applications at- Many distributed applications can make use of large tempt to achieve this balance by setting “magic num- background transfers transfers of data that humans are bers” (e.g., the prefetch threshold in prefetching algo- not waiting for to improve service quality. For exam- rithms [18, 26]) that have little obvious relationship to ple, a broad range of applications and services such as system goals (e.g., availability or latency) or constraints data backup [29], prefetching [50], enterprise data dis- (e.g., current spare network bandwidth). tribution [20], Internet content distribution [2], and peer- Our goal is for the operating system to manage net- to-peer storage [16, 43] can trade increased network work resources in order to provide a simple abstrac- This work was supported in part by an NSF CISE grant (CDA- tion of zero-cost background transfers. A self-tuning 9624082), the Texas Advanced Technology Program, the Texas Ad- background transport layer will enable new classes of vanced Research Program, and Tivoli. Dahlin was also supported by applications by (1) simplifying applications, (2) reduc- an NSF CAREER award (CCR-9733842) and an Alfred P. Sloan Re- search Fellowship. ing the risk of being too aggressive, and (3) making 6
7
7
8
9
9
10
11
11
12
12
12
13
13
13
Participatory Networking 14
15
17
Participatory Networking Secure? Fair? Safe? Black holes? Loop freedom? 18
Participatory Networking 1. semantics + protocol (Hot-ICE ’12) 19
Participatory Networking 1. semantics + protocol (Hot-ICE ’12) 2. implementation (this talk) 20
Participatory Networking 1. semantics + protocol (Hot-ICE ’12) 2. implementation (this talk) PANE 20
Hierarchical Flow Tables 21
22
22
bandwidth root 100Mbps bandwidth root adf 50Mbps Hierarchy of Privileges 23
Hierarchy of Policies 24
(dstPort = 22, Deny) (dstIP=10.0.0.2, GMB=30) (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchy of Policies 24
: t e k c a P 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d (dstIP=10.0.0.2, GMB=30) (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchy of Policies 25
: t e k c a P 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d (dstIP=10.0.0.2, GMB=30) (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 26
: t e k c a P 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d (dstIP=10.0.0.2, GMB=30) (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 27
: t e k c a P 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d ? (dstIP=10.0.0.2, GMB=30) GMB=10 Allow (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 27
: t e k c a P 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d ? +S (dstIP=10.0.0.2, GMB=30) GMB=10 Allow (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 27
: t e k c a P 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d ? 0 +P +S (dstIP=10.0.0.2, GMB=30) GMB=10 Allow (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 27
: t e k c a P 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d GMB=10 ? 0 +P +S (dstIP=10.0.0.2, GMB=30) GMB=10 Allow (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 27
: t e k c a P 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d GMB=30 GMB=10 ? 0 +P +S (dstIP=10.0.0.2, GMB=30) GMB=10 Allow (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 27
: t e k c a P GMB=30 1 0 . 0 . . 0 1 c r s (dstPort = 22, Deny) 0 8 : 2 . 0 . 0 0 . 1 t s d GMB=30 GMB=10 ? 0 +P +S (dstIP=10.0.0.2, GMB=30) GMB=10 Allow (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 27
GMB=30 +P (dstPort = 22, Deny) GMB=30 GMB=10 +S (dstIP=10.0.0.2, GMB=30) +D GMB=10 Allow (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 28
Only Requirements: GMB=30 Associative, 0 -identity +P (dstPort = 22, Deny) GMB=30 GMB=10 +S (dstIP=10.0.0.2, GMB=30) +D GMB=10 Allow (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) Hierarchical Flow Table 28
+D D and S identical. In node Deny overrides Allow. +S Sibling GMB combines as max Child overrides Parent Parent-Sibling +P for Access Control GMB combines as max PANE’s HFT Operators 29
Implementation 30
(d (d (d (d (s (d (d (s (d (d (d (d (s (d (d (s (d (d (d (s PANE 31
(dstPort = 22, Deny) (dstIP=10.0.0.2, GMB=30) (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) 32
(dstPort = 22, Deny) (dstIP=10.0.0.2, GMB=30) (dstPort=80, GMB=10) (srcIP=10.0.0.1, Allow) 32
PANE 33
PANE 33
PANE 34
Recommend
More recommend
