Transcript Document

Infrastructure Primitives for Overlay Networks
Karthik Lakshminarayanan, Ion Stoica and Scott Shenker
Sahara/i3 Retreat, Summer 2003, University of California at Berkeley
Goal: Share Overlay Functionality
What do overlays share?
• Underlying IP infrastructure
• Underlying hardware (e.g. PlanetLab)
Why not share…
• Higher level overlay functionality
– Each application designs overlay routing from scratch
– Lower deployment barrier: design effort & deployment
expense
Our Approach
What are the requirements for supporting most of the
overlays applications?
•
Routing control
(i) Adaptive routing (ii) Measuring virtual link properties
•
Data manipulation
How overlay functionality is split
•
Embed in the infrastructure:
–
•
– Each application performs probes to find good overlay
paths
– Reduce overlay maintenance overhead
Third-party services:
–
• Network weather information
–
•
m1
m1
m
m1
m2
n2
• RTT(n1,n2) = t(m1) – t(m)
• Loss Rate:
Services are implemented at end-hosts, shared using an open
interface
Information for making routing decisions, e.g. measurements of
path delay, loss-rate, bandwidth
At the end-hosts:
–
Delay/Loss-rate Measurement
n1
Low-level routing mechanisms, e.g. forwarding, replication
Not shared at all, e.g. policies for choosing paths
Available BW Measurement
1
n1
(m Λ ~m1 Λ ~m2)  loss on virtual
link (n1,n2)
– False positives:
• m1 was not dropped on (n1,n2)
• m1 was dropped either on (n1,n2) or
(n2,R)
• m2 was dropped on (n2,R)
– False negative:
• m1 was dropped on (n1,n2)
• m was dropped on (n1,,R)
n2
1
1
– Might not work well
Bottleneck?
1
• Delay-based
bandwidth
measurement (TCP
Vegas like)
1
cwd
R
• Increase sending
rate till increase in
delay is seen
• Use packet
replication to identify
if the bottleneck is
on (n1,n2) or not
Infrastructure Primitives
• Path Selection
• Path Replication
•Hello
Experiments
(Delay)
n2
m
Why this approach?
•No difference between data
m1
m
and measurement traffic –
better security, nodes have no
m
incentive to lie
•Control path must be outside R
R’
– collective knowledge to
decide what to monitor
Claim: This is enough to do (i) Adaptive routing
(ii) Measurements (iii) Data manipulation
Weather Service Design
Challenge: Scalability in monitoring
Client A
Network measurements
Query/reply routing info.
Setup routes
Weather
Service 1
Weather
Service 2
Prob. of false
positives/negatives is O(p2)
R
n1
Client D
Client B
• hello
Experiments
(Loss rate,
Avail-BW)
• Accuracy of 90% in over
89% of the cases
Client C
Open Questions/Future Work
• What if path characteristics are correlated?
– Shared bottleneck
– Losses at the egress/ingress link
• Sub-problems
– By having incomplete information about network
weather, how much do we lose (if at all)?
• 37 PlanetLab nodes, 90% RDP < 1.38
• Within a factor of
two for 90% of pairs
• Temporal variation
in Avail-BW may be
large
• How much does accuracy of measurements affect
the final outcome?
– If the underlying routing is bad, what is the diversity of
such an overlay needed to do a good job?
• Design API and develop applications based on it