Download Overlay Networks

Lecture 6
Overlay Networks
CPE 401/601 Computer Network Systems
slides are modified from Jennifer Rexford
Overlay Networks
2
Overlay Networks
Focus at the application level
3
IP Tunneling to Build Overlay Links
 IP tunnel is a virtual point-to-point link
 Illusion of a direct link between two separated nodes
Logical view:
Physical view:
A
B
A
B
tunnel
E
F
E
F
 Encapsulation of the packet inside an IP datagram
 Node B sends a packet to node E
 … containing another packet as the payload
4
Tunnels Between End Hosts
B
Src: A
Dest: B
Src: C
Dest: B
Src: A
Dest: B
A
C
Src: A
Dest: C
Src: A
Dest: B
5
Overlay Networks
 A logical network built on top of a physical network
 Overlay links are tunnels through the underlying network
 Many logical networks may coexist at once
 Over the same underlying network
 And providing its own particular service
 Nodes are often end hosts
 Acting as intermediate nodes that forward traffic
 Providing a service, such as access to files
 Who controls the nodes providing service?
 The party providing the service
 Distributed collection of end users
6
Overlays for Incremental
Deployment
7
Using Overlays to Evolve the Internet
 Internet needs to evolve
IPv6
 Security
 Mobility
 Multicast

 But, global change is hard
 Coordination with many ASes
 “Flag day” to deploy and enable the technology
 Instead, better to incrementally deploy
 And find ways to bridge deployment gaps
8
6Bone: Deploying IPv6 over IP4
Logical view:
Physical view:
A
B
IPv6
IPv6
A
B
C
IPv6
IPv6
IPv4
Flow: X
Src: A
Dest: F
data
A-to-B:
IPv6
E
F
IPv6
IPv6
D
E
F
IPv4
IPv6
IPv6
tunnel
Src:B
Dest: E
Src:B
Dest: E
Flow: X
Src: A
Dest: F
Flow: X
Src: A
Dest: F
data
data
B-to-C:
IPv6 inside
IPv4
B-to-C:
IPv6 inside
IPv4
Flow: X
Src: A
Dest: F
data
E-to-F:
IPv6
9
Secure Communication Over Insecure Links
 Encrypt packets at entry and decrypt at exit
 Eavesdropper cannot snoop the data
 … or determine the real source and destination
10
Communicating With Mobile Users
 A mobile user changes locations frequently
 So, the IP address of the machine changes often
 The user wants applications to continue running
 So, the change in IP address needs to be hidden
 Solution: fixed gateway forwards packets
 Gateway has a fixed IP address
 … and keeps track of the mobile’s address changes
www.cnn.com
gateway
11
IP Multicast
 Multicast
 Delivering the same data to many receivers
 Avoiding sending the same data many times
unicast
multicast
 IP multicast


Special addressing, forwarding, and routing schemes
Pretty complicated stuff
12
MBone: Multicast Backbone
 A catch-22 for deploying multicast
 Router vendors wouldn’t support IP multicast
 … since they weren’t sure anyone would use it
 And, since it didn’t exist, nobody was using it
 Idea: software implementing multicast protocols
 And unicast tunnels to traverse non-participants
13
Multicast Today
 Mbone applications starting in early 1990s
 Primarily video conferencing, but no longer operational
 Still many challenges to deploying IP multicast
 Security vulnerabilities, business models, …
 Application-layer multicast is more prevalent
 Tree of servers delivering the content
 Collection of end hosts cooperating to delivery video
 Some multicast within individual ASes
 Financial sector: stock tickers
 Within campuses or broadband networks: TV shows
 Backbone networks: IPTV
14
Case Study:
Narada - End System Multicast
15
Narada: End System Multicast
Gatech
Stanford
Stan1
Stan2
CMU
Berk1
Berk2
Berkeley
Overlay Tree
Stan1
Gatech
Stan2
CMU
Berk1
Berk2
Performance Concerns
Delay from CMU to
Berk1 increases
Gatech
Stan1
Stan2
CMU
Berk1
Duplicate Packets:
Bandwidth Wastage
Gatech
Stanford
Berk2
Stan1
Stan2
CMU
Berk1
Berkeley
Berk2
Overlay Tree
 The delay between the source and receivers is small
 Ideally, the number of redundant packets on any physical link is low
 Heuristic:


Every member in the tree has a small degree
Degree chosen to reflect bandwidth of connection to Internet
CMU
Stan2
Stan1
Berk1
Berk2
High latency
Stan2
CMU
Stan2
Stan1
Gatech
Berk1
CMU
Stan1
Gatech
Berk2
High degree (unicast)
Berk1
Gatech
Berk2
“Efficient” overlay
Overlay Trees
 Source routed minimum spanning tree on mesh
 Desired properties
 Members have low degree
 Small delays from source to receivers
Stan2
Berk2
CMU
Stan2
Stan1
Stan1
Berk1
Gatech
Berk2
Berk1
Gatech
Case Study:
Resilient Overlay Networks
20
RON: Resilient Overlay Networks
Premise: by building application overlay network, can
increase performance and reliability of routing
Princeton
application-layer
router
Yale
Two-hop (application-level)
Berkeley-to-Princeton route
UNR
Berkeley
21
RON Circumvents Policy Restrictions
 IP routing depends on AS routing policies

But hosts may pick paths that circumvent policies
USLEC
me
ISP
PU
Patriot
My home
computer
22
RON Adapts to Network Conditions
B
A
C
 Start experiencing bad performance
 Then, start forwarding through intermediate host
23
RON Customizes to Applications
B
A
bulk transfer
C
 VoIP traffic: low-latency path
 Bulk transfer: high-bandwidth path
24
How Does RON Work?
 Keeping it small to avoid scaling problems
 A few friends who want better service
 Just for their communication with each other
 E.g., VoIP, gaming, collaborative work, etc.
 Send probes between each pair of hosts
B
A
C
25
How Does RON Work?
 Exchange the results of the probes
 Each host shares results with every other host
 Essentially running a link-state protocol!
 So, every host knows the performance properties
 Forward through intermediate host when needed
B
B
A
C
26
RON Works in Practice
 Faster reaction to failure
RON reacts in a few seconds
 BGP sometimes takes a few minutes

 Single-hop indirect routing
 No need to go through many intermediate hosts
 Typically, an extra hop circumvents the problems
 Better end-to-end paths
 Circumventing
routing policy restrictions
 Sometimes the RON paths are actually shorter
27
RON Limited to Small Deployments
 Extra latency through intermediate hops
 Software delays for packet forwarding
 Propagation delay across the access link
 Overhead on the intermediate node
 Imposing CPU and I/O load on the host
 Consuming bandwidth on the access link
 Overhead for probing the virtual links
 Bandwidth consumed by frequent probes
 Trade-off between probe overhead and detection speed
 Possibility of causing instability
 Moving traffic in response to poor performance
 May lead to congestion on the new paths
28