ISPaided Biased Query Search in P2P Systems

1
ISP-aided Biased Query Search in P2P Systems

• Vinay Aggarwal and Anja Feldmann
• Vinay.Aggarwal_at_telekom.de
• Deutsche Telekom Laboratories / TU Berlin
• Berlin, Germany

2
Introduction

• P2P traffic gt50 of Internet traffic
• Bittorrent, eDonkey, Skype, GoogleTalk
• P2P systems form overlays at application layer
• neighbour selection arbitrary
• routing independent of Internet AS routing
• Routing layer functionality duplicated at
  application layer
• P2P users want performance
• Measure topology themselves (use RTT) ? overhead
• Build topology agnostic of underlay? performance
  loss
• ISPs in a dilemma
• P2P spurs broadband demand, still ISPs lose money
• Traffic Engineering difficult with P2P traffic
• Lack of coordination ? Tension!

3
ISP-P2P tension

• Random/RTT-based peer selection ? peerings cross
  ISP boundaries multiple times, often unnecessarily

4
Solution ISP-P2P Cooperation

• Concept ISP knows its network
• Node last-hop bandwidth, geographical location,
  service class
• Routing policy, OSPF/BGP metrics, AS distance to
  other ISPs
• Each ISP offers Oracle service
• P2P nodes query it during neighbour selection or
  file exchange, send list of potential neighbours
• Oracle ranks these by proximity
• Inside network, last-hop bandwidth, geographical
  location (city/PoP), AS hops
• ISP-aided optimal P2P neighbour selection
• Simple and general solution, open for all
  overlays
• Run as Web server or UDP service at known location

5
How Oracle works
6
Advantage for ISP/P2P

• Measurement overhead eliminated
• Utilize knowledge of ISP
• Avoid high-latency paths and bottlenecks at
  inter-ISP transit/peering links
• ISPs regain control of network traffic
• Traffic across ISP boundaries reduced
• ? immense cost savings
• Better QoS to other applications, improved
  service to customers

7
Impact on network structure

• Node degree and mean overlay path length
  unchanged
• Graph remains connected, overlay underlay
  diameter constant
• Large improvement in AS distance and intra-AS
  peerings
• Impact on flow conductance minimal
• Densely connected subgraphs local to ISPs
• P2P topology correlated with AS topology

8
Overlay-Underlay Topology Correlation

• Random vs biased Gnutella topology

9
Why Testlab?

• Real traffic instead of simulated flows
• Configure network devices (routers, switches,
  machines)
• Generate variegated network scenarios and traffic
  environments
• Wide range of experiments using real
  applications, network stacks, OS
• Better control visibility vs Internet
• No adverse effect on Internet traffic

10
Testlab used for experiments
11
Experimental Topologies

• Internet consists of Autonomous Systems (AS)
• Prefix-based packet forwarding, based on AS
  policies
• P2P systems setup overlay topology
• Implement own routing on query/key basis
• Design multiple-AS topology, each AS hosts
  multiple P2P users
• Router is an abstraction of AS boundary
• 5 routers ? 5-AS topology
• Each router connects 3 machines, each machine
  runs 3 P2P applications concurrently
• 5 ASes, 15 machines, 45 P2P users

12
AS Topologies
Realistic Topology
Ring Topology
Star Topology
Tree Topology
13
Configuration of a topology

• using VLAN, VTP, ifconfig, route

14
Testlab topologies
15
P2P System Gnutella

• Unstructured, open-source, popular file-sharing
  P2P system
• Each servent bootstraps by flooding Pings to
  known nodes, answered by Pongs
• Search content by flooding Query, answered by
  QueryHit (QH)
• Msgs carry TTL (max 7) and msg ID
• Servent selects a node randomly from all QHs to
  download desired content from
• File exchange using HTTP, outside Gnutella
• Ultrapeers (UP) and leafs form 2-level hierarchy

16
Experimental Setup

• Each machine has 1 UP 2 leafs, all run
  GTK-Gnutella
• Central machine runs oracle
• Servents send list of IPs to oracle, which sorts
  them according to parent AS and AS-hop distance,
  returns list to servent
• File-sharing schemes
• Uniform 6 unique files on all servents
• Variable UP-12, a leaf-6, other leaf-0 files
• Compare number of responses to Query
• Each servent introduces a unique Query string
• Realistic query string distribution (mp3,
  album/artist)
• Run unmodified and biased P2P experiments

17
Number of Query Messages
gt 50 reduction with ISP-aided biased P2P
neighbour selection
18
Query responses (Uniform FS)

• gt Query responses with biased P2P
  (dotted) similar
• to unbiased P2P (bold)

19
Query Responses (Variable FS)

• gt Effects similar across file distribution
  patterns and topologies

20
Query responses (rare queries)

• gt Effects hold even for different query types

21
Large scale simulations

• SSFNet discrete-event, packet-level simulator
• 700 node P2P, 16 ASes, churn, free-riding
• behaviour as observed in real world
• Query traffic reduced by 54
• Swarming pattern of Queries benefits
• Reachability at remote locations improves
• Network discovery traffic reduced by 42
• Number of responses per Query similar
• Number of unsuccessful Queries same

22
Responses per Query

• Distribution of queries similar
• Mean 127 vs 102, Median 78 vs 62

23
Conclusion Future Work

• Unique and simple ISP-P2P collaboration concept,
  so that both benefit
• Scalability of P2P networks improves
• Negotiation and query traffic reduced by 50
• No adverse effects on query search process
• Stable across popular, rare, unsuccessful Queries
• Reachability of Queries at remote locations
  improves
• Advantages hold across topologies and scale
• Planetlab experiments coming