Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Backpressure routing wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Deep packet inspection wikipedia , lookup
Network tap wikipedia , lookup
Computer network wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Airborne Networking wikipedia , lookup
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: (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) 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 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