1 Optimizing Malloc and Free Professor Jennifer Rexford jrex.
Projects Related to Coronet Jennifer Rexford Princeton University jrex.
-
date post
19-Dec-2015 -
Category
Documents
-
view
216 -
download
0
Transcript of Projects Related to Coronet Jennifer Rexford Princeton University jrex.
Outline
• SEATTLE– Scalable Ethernet architecture
• Router grafting (joint work with Kobus)– Seamless re-homing of links to BGP neighbors– Applications of grafting for traffic engineering
• Static multipath routing (Martin’s AT&T project)– Joint traffic engineering and fault tolerance
2
SEATTLE
3
Scalable Ethernet Architecture for Large Enterprises(joint work with Changhoon Kim and Matt Caesar)
http://www.cs.princeton.edu/~jrex/papers/seattle08.pdf
Goal: Network as One Big LAN
• Shortest-path routing on flat addresses–Shortest paths: scalability and performance–MAC addresses: self-configuration and mobility
• Scalability without hierarchical addressing–Limit dissemination and storage of host info–Sending packets on slightly longer paths
4
SH
S
S
S
S
S S
S S
S S S
S
H
H
H
H
HH
H
H
SEATTLE Design Decisions
5
Objective Approach Solution
1. Avoiding flooding
Never broadcast unicast traffic Network-layer
one-hop DHT2. Restraining
broadcastingBootstrap hosts
via unicast
3. Reducing routing state
Populate host infoonly when and where
it is needed
Traffic-driven resolution with caching
4. Shortest-path forwarding
Allow switches to learn topology
L2 link-state routingmaintaining only
switch-level topology
* Meanwhile, avoid modifying end hosts
Network-Layer One-hop DHT
• Maintains <key, value> pairs with function F – Consistent hash mapping a key to a switch–F is defined over the set of live switches
• One-hop DHT– Link-state routing ensures
switches know each other
• Benefits– Fast and efficient
reaction to changes– Reliability and capacity
naturally grow with size of the network
6
0 12128-1
Location Resolution
7
SwitchesEnd hosts
Control messageData traffic
<key, val> = <MAC addr, location>
Host discovery
B
x
HashF(MACx) = B
Store<MACx, A>
Traffic to x
HashF(MACx ) = BTunnel
to A
Notify<MACx, A>
E
Forward directly from D to A
ATunnel to B
C
D
yOwner
User
Resolver
Publish<MACx, A>
Address Resolution
8
<key, val> = <IP addr, MAC addr>
Traffic following ARP takes a shortest pathwithout separate location resolution
B
DHash
F(IPx) = B
Store<IPx, MACx, A>
BroadcastARP requestfor IPx
HashF(IPx ) = B
Unicast reply<IPx, MACx, A>
E
AUnicastlook-up to B
C
<IPx ,MACx>
x y
Handling Network and Host Dynamics
•Network events–Switch failure/recovery
Change in <key, value> for DHT neighbor Fortunately, switch failures are not common
–Link failure/recovery Link-state routing finds new shortest paths
•Host events–Host location, MAC address, or IP address –Must update stale host-information entries
9
Handling Host Information Changes
10
Resolver
y
Host talkingwith x
< x, A >
< x, A >
< x, A >
D< x, D >
Oldlocation
New location
< x, D >
< x, D >
< x, D >
Dealing with host mobility
MAC- or IP-address change can be handled similarly
B
xA
C
E
F
Packet-Level Simulations
• Large-scale packet-level simulation–Event-driven simulation of control plane–Synthetic traffic based on LBNL traces –Campus, data center, and ISP topologies
• Main results–Much less routing state than Ethernet–Only slightly more stretch than IP routing–Low overhead for handling host mobility
11
Prototype Implementation
12
Host-info registrationand notification msgs
User/Kernel Click
XORP
OSPFDaemon
RingManager
Host InfoManager
SeattleSwitch
Link-stateadvertisements
Data Frames
Data Frames
RoutingTable
NetworkMap
ClickInterface
Throughput: 800 Mbps for 512B packets, or 1400 Mbps for 896B packets
Conclusions on SEATTLE
• SEATTLE –Self-configuring, scalable, efficient
• Enabling design decisions–One-hop DHT with link-state routing–Reactive location resolution and caching–Shortest-path forwarding
• Relevance to Coronet–Backbone as one big virtual LAN–Using Ethernet addressing
13
Router Grafting
14
Joint work with Eric Keller, Kobus van der Merwe, and Michael Schapira
http://www.cs.princeton.edu/~jrex/papers/nsdi10.pdf
http://www.cs.princeton.edu/~jrex/papers/temigration.pdf
Today: Change is Disruptive
• Planned change–Maintenance on a link, card, or router–Re-homing customer to enable new features–Traffic engineering by changing the traffic matrix
• Several minutes of disruption–Remove link and reconfigure old router–Connect link to the new router–Establish BGP session and exchange routes 15
customerprovider
16
Router Grafting: Seamless Migration
• IP: signal new path in underlying transport network
• TCP: transfer TCP state, and keep IP address
• BGP: copy BGP state, repeat decision process
Send state
Move link
17
Prototype Implementation
• Added grafting into Quagga– Import/export routes, new ‘inactive’ state– Routing data and decision process well separated
• Graft daemon to control process
• SockMi for TCP migration
ModifiedQuagga
graftdaemon
Linux kernel 2.6.19.7
SockMi.ko
Graftable Router
HandlerComm
Linux kernel 2.6.19.7-click
click.ko
Emulatedlink migration
Quagga
Unmod.Router
Linux kernel 2.6.19.7
18
Grafting for Traffic Engineering
Rather than tweaking the routing protocols…* Rehome customer to change traffic matrix
19
• Internet2 topology, and traffic data
• Developed algorithms to determine links to graft
Traffic Engineering Evaluation
1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.60
100000
200000
300000
400000
500000
600000
700000
800000
900000
1000000
Original Topology (optimal paths)
With Grafting
Demand Multiple
Tot
al L
ink
Usa
ge Network can handle more traffic(at same level of congestion)
Conclusions
• Grafting for seamless change–Make maintenance and upgrades seamless–Enable new management applications (e.g., TE)
• Implementing grafting–Modest modifications to the router –Leveraging programmable transport networks
• Relevance to Coronet–Flexible edge-router connectivity–Without disrupting neighboring ISPs
20
Joint Failure Recoveryand Traffic Engineering
21
Joint work with Martin Suchara, Dahai Xu, Bob Doverspike, and David Johnson
http://www.cs.princeton.edu/~jrex/papers/stamult10.pdf
Simple Network Architecture
• Precomputed multipath routing– Offline computation based on underlying topology– Multiple paths between each pair of routers
• Path-level failure detection– Edge router only learns which path(s) have failed– E.g., using end-to-end probes, like BFD– No need for network-wide flooding
• Local adaptation to path failures– Ingress router rebalances load over remaining paths– Based on pre-installed weights
22
Architecture
23
• topology design• list of shared risks• traffic demands
t
s
• fixed paths• splitting ratios
0.25
0.25
0.5
State-Dependent Splitting
• Custom splitting ratios–Weights for each combination of path failures
25
0.40.4
0.2
Failure Splitting Ratios
- 0.4, 0.4, 0.2
p2 0.6, 0, 0.4
… …
configuration:
0.6
0.4
p1
p2
p3
at most 2#paths entries
Optimizing Paths and Weights
• Optimization algorithms– Computing multiple paths per pair of routers– Computing splitting ratios for each failure scenario
• Performance evaluation– On AT&T topology, traffic, and shared-risk data– Performance competitive with optimal solution– Using around 4-8 paths per pair of routers
• Benefits– Joint failure recovery and traffic engineering– Very simple network elements (nearly zero code)– Part of gradual move away from dynamic layer 3
26