A Swarming Architecture for Internet Data Transfer

1. A Swarming Architecture for Internet Data Transfer Arun Venkataramani Donald Towsley Presented by: Shiqi Chen, Ionut Trestian

2. Introduction • Late 90s client-server architectures dominated data transfers on Internet • Alternatives emerged: • Unstructured p2p file sharing • Content Distribution Networks • Structured Distributed Hash Tables • Publish subscribe • End-System Multicast • Main point: make data location Independent

3. Introduction • Problems with existing p2p systems • Free riding • Central point of failure (BitTorrent) • Simple and robust incentive strategy (tit-for-tat) is a deterrent for free riding. • Can swarms form the basis of a universal architecture for the Internet and if so what is an appropriate architecture?

4. Uswarm Architecture • Fundamental difference • Uswarm (one huge swarm for all data transfers) • BitTorrent (one swarm per file) • Typical transfer multipoint-to-point • Data is location independent and self-verifying • Designed to send bulk data but can send dynamic data too.

5. Uswarm Architecture

6. Naming and resolution • Intent Resolution Service – translating intent (what a peer is looking for, URL, RSS feed) to metadata • IRS, Modern search engine, web server that serves metadata • Metadata Resolution Service returns set of peer addresses (tracker in BitTorrent), distributed here.

7. Central vs Distributed Tracking • Peers translate metadata to addresses(3 ways) • Logically centralized tracking service similar to DNS • In-network support for tracking (gateway router intercepts and processes resolution requests) • Peer-to-Peer tracking • Centralized trackers suited for pull data transfer but not fur push data transfer. • Enables location based caching

8. Roles and application usage • Peers have roles depending on their economic relationship with their peers and network service provider. • Some peers always ready to send data, social network based trust possible. • Live streaming – p2p live streaming • Semi-autonomous peer system – push contents to set-top boxes • Human-centric applications – facilitates push based applications

9. Data Transfer and Control Plane • Fundamental benefits of uswarm over isolated swarms • Post-popularity – BitTorrent robust to flash crowds but treats bad unpopular content. • Block-availability - Allow peers to change blocks across different content. • Robust tracking – BitTorrent is inherently unscalable. Fractured content

10. Data plane: uswarm vs isolated swarms • Download capacity O(log n) greater • Also more robust to failures

11. Control plane - distributed tracking • BitTorrent – central server (single point of failure) • Low tracker availability is a significant problem for users. • Solutions • Replicated trackers • Integration of DHTs with BitTorrent clients.

12. Control plane - distributed tracking

13. Control plane - distributed tracking • Our approach, a combination of: • Massively replicated tracking. • Similar to DNS (hierarchical) • Peer-to-peer gossip. • Controlled flooding • Active gossip • In-network tracking. • Couples a uswarm tracker with in-network caches.

14. Other implications • Traffic engineering • Today’s Internet constraints the routing choice of both end users and ISPs • Bring ISPs into the picture (tracker router): return a set of peers that result in the most load-balanced traffic assignment.

15. Research questions • More complex scenarios required. • Which replicated tracking mechanism is best suited. • Implicitly assumed that download rate is the performance metric. For some applications this is not the case. • In-network caching raises the question of placement and replacement strategies.

16. Incentive Strategies • Incentives in isolated swarms • BitTorrent is not robust to selfish peer behavior • Bittyrant: selfish algorithm benefits every peer irrespective of how many peers are using it. • Open questions: • Estimating peer upload and download capacities • Analyzing if the proposed mechanism is strategy proof • Robustness to byzantine faulty peers

17. Incentive in uswarm • Data plane: extend Bittyrant algorithm – select peers so as to maximize download on available upload rate • Users may upload blocks from different files to download a particular file or simultaneously download several files with different utility. • Sort peers according to dp/up weighted by utility

18. Incentives in uswarm • Control plane • tit-for-tat: keep track of the number of metadata requests a neighbor helps resolve. Peers choose to help neighbors that have been most useful in the past. • Dynamic topology adaptation: peers prefer other peers with similar content interest for neighbors, resembling a semantic social network.

19. Incentives in uswarm • How to measure the performance of control plane? • Peer selection in the data plane at fine time scales. • Peer selection in the control plane that operates over slower time scales • Movement of peers across interest clusters based on their content access pattern.

20. Connection games in uswarm • Opening a connection has cost. • So S will not benefit even he increase the number of connections if we charge a fixed cost per connection.

21. Connection games in uswarm • tit-for-tat: Pairwise Nash equilibrium exists but the loss of efficiency is unbounded. • If considering routing topology and congestion control, then Nash equilibrium only exists for simple topologies and the loss of efficiency can be arbitrarily large. • Goal: Interactive strategic peer selection while taking topology and allocation cost into account.

22. Other research questions • Pricing: upload bandwidth may not be free or even linearly priced. • Indirect trading: agents with low upload capacity may appoint other agents to participate in uswarm on its behalf. P2P detour routing may be implemented as a service on top of uswarm. • Workload and network conditions: Block availability, TCP’s inefficiency, block-based tit-for-tat strategy, noisy information on the efficiency or vulnerability.

23. Deployment and Case studies • DoI-resistant information dissemination service – if a user seeks a file at least one copy of which exists in the network then she could be able to retrieve it unless the underlying network is physically partitioned by faulty or malicious nodes. • Basic idea: to use massive replication to ensure that a peer can reach at least one replica. • Knowledge of routing topology: select neighbors • Replicating content: DoS attacks do not make information unavailable.

24. Opportunistic Measurement • Instrument a small number of Bittyrant clients to passively monitor transfer performance and contribute measurement. • It is incentive-compatible for peers to contribute measurements because peers with more information about the capacity of other peers can make better strategic choices.

25. Delay-tolerant uswarm and new services • uswarm is tolerant to delays or interrupted point-to-point connections by design. • RAPID (Resource Allocation Protocol for Intentional DTN routing): enables sophisticated knobs to intentionally optimize performance metrics of interest. • Push-based application: advertising and trading of content according to individual interest.

26. Plan of work • Model single-swarm and multi-swarm behavior accounting for strategic peer behavior. • Topology adaptation model and implementation of DoI-resistant dissemination service. • Implement a modified socket API to enable application use. Investigate interaction with traffic engineering and virtualized architectures. Test for security.

27. Future Impact of this project • Enable a robust dissemination service resistant to denial of information attacks. • Foster the growth of novel human-centric applications. • Enable delay-tolerant data transfer for poorly connected environments.

28. Thank you ! Questions ?