D istributed Systems, N etwork Protocols & A pplications Srinivasan Seshan Computer Science Department Carnegie Mellon University.

Slides:



Advertisements
Similar presentations
Dynamic Replica Placement for Scalable Content Delivery Yan Chen, Randy H. Katz, John D. Kubiatowicz {yanchen, randy, EECS Department.
Advertisements

Distributed Data Processing
Colyseus: A Distributed Architecture for Online Multiplayer Games
W3C Workshop on Web Services Mark Nottingham
Efficient Event-based Resource Discovery Wei Yan*, Songlin Hu*, Vinod Muthusamy +, Hans-Arno Jacobsen +, Li Zha* * Chinese Academy of Sciences, Beijing.
Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan MIT and Berkeley presented by Daniel Figueiredo Chord: A Scalable Peer-to-peer.
Clayton Sullivan PEER-TO-PEER NETWORKS. INTRODUCTION What is a Peer-To-Peer Network A Peer Application Overlay Network Network Architecture and System.
Cognitive Publish/Subscribe for Heterogeneous Clouds Šarūnas Girdzijauskas, Swedish Institute of Computer Science (SICS) Joint work with:
Self-Organizing Hierarchical Routing for Scalable Ad Hoc Networking David B. Johnson Department of Computer Science Rice University Monarch.
Small-Scale Peer-to-Peer Publish/Subscribe
Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 ECSE-6600: Internet Protocols Informal Quiz #13: P2P and Sensor Networks Shivkumar Kalyanaraman:
Multicasting in Mobile Ad-Hoc Networks (MANET)
Technical Architectures
Scribe: A Large-Scale and Decentralized Application-Level Multicast Infrastructure Miguel Castro, Peter Druschel, Anne-Marie Kermarrec, and Antony L. T.
1 Defragmenting DHT-based Distributed File Systems Jeffrey Pang, Srinivasan Seshan Carnegie Mellon University Phillip B. Gibbons, Michael Kaminsky Intel.
Web Caching Schemes1 A Survey of Web Caching Schemes for the Internet Jia Wang.
Applications over P2P Structured Overlays Antonino Virgillito.
15-441: Computer Networking Lecture 26: Networking Future.
Traffic Engineering With Traditional IP Routing Protocols
M ERCURY : A Scalable Publish-Subscribe System for Internet Games Ashwin R. Bharambe, Sanjay Rao & Srinivasan Seshan Carnegie Mellon University.
Carnegie Mellon University Complex queries in distributed publish- subscribe systems Ashwin R. Bharambe, Justin Weisz and Srinivasan Seshan.
Mercury: Scalable Routing for Range Queries Ashwin R. Bharambe Carnegie Mellon University With Mukesh Agrawal, Srinivasan Seshan.
A Scalable Content-Addressable Network Authors: S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Shenker University of California, Berkeley Presenter:
CS 672 Paper Presentation Presented By Saif Iqbal “CarNet: A Scalable Ad Hoc Wireless Network System” Robert Morris, John Jannotti, Frans Kaashoek, Jinyang.
Security in Wireless Sensor Networks Perrig, Stankovic, Wagner Jason Buckingham CSCI 7143: Secure Sensor Networks August 31, 2004.
Object Naming & Content based Object Search 2/3/2003.
Mercury: Supporting Scalable Multi-Attribute Range Queries A. Bharambe, M. Agrawal, S. Seshan In Proceedings of the SIGCOMM’04, USA Παρουσίαση: Τζιοβάρα.
Wide Web Load Balancing Algorithm Design Yingfang Zhang.
A Cross Layer Approach for Power Heterogeneous Ad hoc Networks Vasudev Shah and Srikanth Krishnamurthy ICDCS 2005.
Protecting Privacy in Sensor- Enriched Internet Services Presenter: Yan Ke, CMU In collaboration with: Phillip B. Gibbons, Brad Karp, Rahul Sukthankar,
Peer-to-peer file-sharing over mobile ad hoc networks Gang Ding and Bharat Bhargava Department of Computer Sciences Purdue University Pervasive Computing.
1CS 6401 Peer-to-Peer Networks Outline Overview Gnutella Structured Overlays BitTorrent.
SIMULATING A MOBILE PEER-TO-PEER NETWORK Simo Sibakov Department of Communications and Networking (Comnet) Helsinki University of Technology Supervisor:
Self-Organizing Adaptive Networks Hari Balakrishnan MIT Laboratory for Computer Science
Roger ZimmermannCOMPSAC 2004, September 30 Spatial Data Query Support in Peer-to-Peer Systems Roger Zimmermann, Wei-Shinn Ku, and Haojun Wang Computer.
Chapter 2 Architectural Models. Keywords Middleware Interface vs. implementation Client-server models OOP.
A Brief Overview by Aditya Dutt March 18 th ’ Aditya Inc.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public ITE PC v4.0 Chapter 1 1 Connecting to the Network Networking for Home and Small Businesses.
Peer to Peer Research survey TingYang Chang. Intro. Of P2P Computers of the system was known as peers which sharing data files with each other. Build.
Jonathan Walpole CSE515 - Distributed Computing Systems 1 Teaching Assistant for CSE515 Rahul Dubey.
Wireless Networks of Devices (WIND) Hari Balakrishnan and John Guttag MIT Lab for Computer Science NTT-MIT Meeting, January 2000.
Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications Xiaozhou Li COS 461: Computer Networks (precept 04/06/12) Princeton University.
Mar 1, 2004 Multi-path Routing CSE 525 Course Presentation Dhanashri Kelkar Department of Computer Science and Engineering OGI School of Science and Engineering.
Aditya Akella The Performance Benefits of Multihoming Aditya Akella CMU With Bruce Maggs, Srini Seshan, Anees Shaikh and Ramesh Sitaraman.
Tony McGregor RIPE NCC Visiting Researcher The University of Waikato DAR Active measurement in the large.
TOMA: A Viable Solution for Large- Scale Multicast Service Support Li Lao, Jun-Hong Cui, and Mario Gerla UCLA and University of Connecticut Networking.
A comparison of overlay routing and multihoming route control Hayoung OH
Communication Paradigm for Sensor Networks Sensor Networks Sensor Networks Directed Diffusion Directed Diffusion SPIN SPIN Ishan Banerjee
The Replica Location Service The Globus Project™ And The DataGrid Project Copyright (c) 2002 University of Chicago and The University of Southern California.
Rendezvous Regions: A Scalable Architecture for Service Location and Data-Centric Storage in Large-Scale Wireless Sensor Networks Karim Seada, Ahmed Helmy.
15-744: Computer Networking L-22: P2P. Lecture 22: Peer-to-Peer Networks Typically each member stores/provides access to content Has quickly.
M ERCURY : A Scalable Publish-Subscribe System for Internet Games Ashwin R. Bharambe To appear in NetGames’02.
Scaling Properties of the Internet Graph Aditya Akella, CMU With Shuchi Chawla, Arvind Kannan and Srinivasan Seshan PODC 2003.
INTERNET TECHNOLOGIES Week 10 Peer to Peer Paradigm 1.
P2P Search COP P2P Search Techniques Centralized P2P systems  e.g. Napster, Decentralized & unstructured P2P systems  e.g. Gnutella.
1 Traffic Engineering By Kavitha Ganapa. 2 Introduction Traffic engineering is concerned with the issue of performance evaluation and optimization of.
Internet Traffic Engineering Motivation: –The Fish problem, congested links. –Two properties of IP routing Destination based Local optimization TE: optimizing.
15-829A/18-849B/95-811A/19-729A Internet-Scale Sensor Systems: Design and Policy Review.
Scaling Properties of the Internet Graph Aditya Akella With Shuchi Chawla, Arvind Kannan and Srinivasan Seshan PODC 2003.
Network Topologies for Scalable Multi-User Virtual Environments Lingrui Liang.
Peer-to-peer networking
A Comparison of Overlay Routing and Multihoming Route Control
CHAPTER 3 Architectures for Distributed Systems
#01 Client/Server Computing
Specialized Cloud Architectures
Data-Centric Networking
Small-Scale Peer-to-Peer Publish/Subscribe
A Comparison of Overlay Routing and Multihoming Route Control
Host and Small Network Relaying Howard C. Berkowitz
#01 Client/Server Computing
Presentation transcript:

D istributed Systems, N etwork Protocols & A pplications Srinivasan Seshan Computer Science Department Carnegie Mellon University

2 Three Major Projects Measurement analysis of networks Sensor networks Distributed virtual reality

3 Measurement/Analysis of Networks Selfish TCP behavior Bottleneck discovery Scaling properties of the Internet Multihoming People:  Aditya Akella, Jeff Pang, Bruce Maggs and Srinivasan Seshan  Anees Shaikh (IBM)

4 Measuring the Internet from Everywhere What could you learn if you could…  Have a machine in almost every ISP  Collect routing information (E-BGP/I-BGP) from these ISPs  Be part of a significant fraction of all Web transfers  Be queried by almost every DNS server in the world We have access to such a testbed  Akamai

5 Bottleneck Discovery Where are bottlenecks in the Internet?  Ignoring access links What is the capacity of these bottlenecks? Initial results  There is a lot of available bandwidth in the Internet today > 45Mbps on 50% of paths!  Quantified relative benefit of using larger Tier-1 ISPs over smaller ISPs  Internal ISP links are bottlenecks more often than expected  Peering between ISPs not as significant a bottleneck as expected Stub More ISPs ISP1 Stub ISP2 Stub Bottlenecks?

6 Scaling Properties of the Internet How will these bottlenecks change over time? Analyzing the combination of Internet topology and routing Identifying changes that are needed to make the Internet scale with hardware improvements from Moore’s law Initial results  Congestion scales poorly in Internet-like graphs  Policy-routing does not worsen the congestion  Alleviation possible via simple, straight-forward mechanisms Congested hot-spots Uniformly scale all capacities? Scale some links faster? Moore’s-law like scaling sufficient?

7 Multihoming How can stub networks like CMU route traffic around bottlenecks? Using multiple ISPs can…  Improve performance and reliability of Internet connectivity  Make Internet routing robust to failures and attacks But need…  Techniques for stub domains to choose providers  Monitoring tools to track changes in Internet performance  Dynamic control over chosen routes ISP 2ISP 1 Internet CMU Destination The effective use of multiple ISPs (multihoming) by stub networks

8 Multihoming In a given metro area…  What maximum performance benefits can multihoming offer?  How can multihomed networks realize these benefits in practice? Initial results  Multihoming helps, but not much beyond 4 providers  Careful choice necessary  Cannot just pick top individual performers  Performance can be 50% worse for a poor choice of providers Future work  Reasons for observed performance benefit  can we relate route/ISP selection to bottleneck observations?  Impact of ISP cost structure  what is the best choices for a given cost?  How will Internet operation be affected by such “smart” routing?

9 Sensor Networks IrisNet People:  Suman Nath, Yan Ke, and Srinivasan Seshan  Phil Gibbons, Babu Pillai, Rahul Sukthankar (Intel Research)

10 What if Sensors Were Everywhere? Persistent queries/triggered actions Characterization of human activity Is the cafeteria busy? Where’s Fred? Person Locator System Show an image when you hear a honk Network monitoring Packet sniffers as sensors

11 Sensor Services Need: infrastructure to simplify creation of sensor- enriched services Remove deployment overhead  Provide a common shared infrastructure of sensors Automate common tasks  Sensor reading collection and storage  Efficient query processing over readings  Address privacy concerns of users

12 Sensor Networks mote hardware TinyOS, TinyDB, etc. campus-scale minimal sensor processing energy is a key concern scalar sensors narrowly focused services ad hoc wireless connectivity IrisNet PCs/PDAs Linux, Java, XML, C++ Internet-scale intensive sensor processing powered nodes multimedia sensors wide variety of services direct Internet connectivity IrisNet: Internet-scale Resource- Intensive Sensor Network Services

13 Example: Parking Space Finder A distributed database maintains  Spot availability data  Address of parking spot  Meter description  Historical availability data Query: Where is the cheapest empty parking spot near school?  Returns driving directions to the best spot

14 IrisNet Architecture University Downtown Hill District Internet Parking Space Finder Organizing Agents Sensing Agents Person Finder Organizing Agents Amy-JohnKim-SteveTom-Zoe Sensing Agents

15 Design Decisions Sensor feeds processed in application specific way near source  Reduces demand on network  Requires relatively intensive processing on sensor device Distributed, hierarchical XML database stores readings  Accommodates frequent updates to different readings  XML supports hierarchical and heterogeneous/evolving description of data  Hierarchical organization enables scalability and rich query styles Challenges in database processing, image processing & distributed systems

16 Distributed Virtual Reality Distributed multiplayer games People:  Ashwin Bharambe, Jeff Pang and Srinivasan Seshan

17 What do Multiplayer Games Look Like? Large shared world  Composed of map information, textures, etc  Populated by active entities: user avatars, computer AI’s, etc Only parts of world relevant to particular user/player Player 1 Player 2 Game World

18 Individual Player’s View Interactive environment (e.g. door, rooms) Live ammo Monsters Players Game state

19 Current Game Architectures Distributed broadcast-based (e.g., DOOM )  Every update sent to all participants Advantages/disadvantages +No central server -Waste of bandwidth -Synchronized game state – difficult for players to join at arbitrary times Do not scale well Centralized client-server (e.g., Quake) Every update sent to server who maintains “true” state Advantages/disadvantages +Reduces overall bandwidth requirements +State management, cheat proofing much easier -Bottleneck for computation and bandwidth  current games limited to about 6000 players - Single point of failure - Response time limited by client-server latency

20 Large-Scale Distributed Games Need to distribute responsibility for maintaining world state and running computer AIs Avoid any single point of failure Efficient use of available bandwidth  Every player only receives “relevant” updates  subscribes to updates Player x ≥ 50 x ≤ 150 y ≥ 150 y ≤ 250 Interests x 100 y 200 Events (100,200) (150,150) (50,250) Arena Virtual World Solution: model game with Publish- Subscribe

21 Publish-Subscribe Overview Key feature  subscription language  Rich database-like subscription languages (e.g. all publications with stock price > 100)  Subject/channel-based subscriptions (e.g. all publications on the IBM stock channel) State-of-the-art  Centralized designs with rich subscriptions  Scalable distributed designs with channel-based subscriptions  Unscalable designs with rich subscriptions Subscription Publications Publishers produce publications Subscribers register their interests via subscriptions

22 Our Approach Goal: build a scalable distributed publish-subscribe system with a “relatively” rich subscription language  Mercury Mercury subscription language  SQL-like but more limited  tradeoff to achieve scalability Example: int x ≤ 200  Enough to support range predicates  Sufficient for games How to support this subscription language scalably?  Use techniques derived from distributed hash tables (DHT)  Existing DHT-based designs only support exact-match lookup Need range-based lookups Eliminate the use of cryptographic hashes  must explicitly handle load-balancing

23 Publish-Subscribe Critical Components Subscription language  Subjects vs. attribute/values  Exact matches vs. regular expressions? Routing mechanism  Where are subscriptions stored in the system?  How are publications routed so that they “meet” subscriptions?  How are publications delivered from this rendezvous point to subscribers?

24 Related Systems Scribe, Herald  Scalable, but –  Restricted subscription language Siena, Gryphon  Flexible subscription language, but –  Poor scalability due to message flooding Delicate balance between expressiveness of language and scalability of routing

25 M ERCURY : Subscription Language SQL-like but more limited  tradeoff to achieve scalability  Example: int x ≤ 200  Enough to support range predicates SQL- like  Need sortable attribute-values  Sufficient for modeling games Game arenas Player statistics, etc. How to support this subscription language scalably?  Use techniques derived from distributed hash tables (DHT)  Existing DHT-based designs only support exact-match lookup  Need range-based lookups  Eliminate the use of cryptographic hashes  must explicitly handle load-balancing

26 M ERCURY : Routing Protocol Each node responsible for range of attribute values For each attribute, nodes arranged into circle Each node compares value in message to his range; and routes along the circle HxHx [240, 320) [80, 160) [160, 240) [0, 80) Attribute Hub

27 Routing Illustrated Send subscription to any one attribute hub Send publications to all attribute hubs [0, 80) [210, 320) 50 ≤ x ≤ ≤ y ≤ 250 x 100 y 200 HxHx [240, 320) [80, 160) [160, 240) HyHy [0, 105) [105, 210) Subscription Publication Rendezvous point

28 Why Not Use DHTs (and Cryptographic Hashing) ? Hashing is good for exact matches  e.g., DHTs Want to support range queries Possible approach  Hash each value in the range  Problems Can only be used for discrete- valued attributes Too many subscriptions int x  1 int x  10 int x = 1 int x = 9 int x = 10

29 Future Work Performance  Cached pointers  reduce number of overlay hops  Network aware placement of nodes  delay competitive with centralized systems Robustness  need to survive node failures Workload  need system to self-tune to workload Cheating  detecting various forms of cheating  Routing, subscriptions, state ownership

30 Future Work Distributed VR has similar challenges as many other distributed applications Other applications we plan to explore:  Collaborative applications (whiteboard, shared applications, chat servers, etc)  Distributed databases  Distributed simulation (ns-2)  …