P6P: A PeertoPeer Approach to Internet Infrastructure

1
P6P A Peer-to-Peer Approach to Internet
Infrastructure

• Lidong Zhou Robbert van Renesse
• Microsoft Research Silicon Valley Dept. of
  Computer Science, Cornell University
• lidongz_at_microsoft.com rvr_at_cs.corenll.edu
• Presented By
• William Barnett
• Dept. of Elec. And Comp. Eng. And Comp. Sci.,
  University of Cincinnati
• barnetwc_at_ececs.uc.edu
• May 16, 2005

2
Outline

• I. Introduction
• II. P6P Architecture
• III. P6P Routing
• A. Basic Protocol
• B. Updating Address Records
• C. Security
• IV. Evaluation
• V. Discussion
• A. Alternative Routing Protocols
• B. Nested Deployment
• C. Multihoming, Multicast and Robustness
• VI. Related Work
• VII. Conclusion

3
Introduction

• Current Internet Inertia of core Internet vs.
  Increasing demand of end sites
• IPv6 promises
• End-to-end connectivity.
• Large address space.
• Multicast, anycast, and mobility.
• Core Internet has been defying the switch to IPv6.

4
Introduction

• P6P
• Alleviate tension between core Internet and end
  sites.
• Decouple addresses as identifiers from addresses
  as locators for routing.
• Creates a clean separation of the end sites from
  core Internet routing infrastructure.
• Isolates transport layer from network layer.

5
Introduction

• P6P
• Persistent unique identifiers for end hosts
  restores the end-to-end connectivity.
• Simplifies deployment of IPSec and P2P
  applications.
• Can be incrementally deployed.
• Incorporates support of IPv6 deployed in existing
  OS platforms.

6
Introduction

• Edge routers
• Map identifiers to locators via a DHT-based P2P
  overlay network.
• Connect end sites with the core Internet.
• Are comprised of two logical components an
  Internal Gateway (IG) and an External Gateway
  (EG).

7
Introduction

• Identifiers are isolated from changes to how the
  site connects to the core Internet via overlay
  mapping updates.
• Shields site from ISP switching and multihoming.
• Reduces churn due to the stability of the edge
  routers.

8
P6P Architecture

• End sites receive IPv6 addresses.
• Addresses are permanent and serve as identifiers
  of hosts or interfaces of P6P sites.
• Each site has a unique site identifier, the 48
  bit IPv6 address prefix.
• Prefixes would need to be assigned by an
  authority such as IANA.

9
P6P Architecture

• Internal Gateways (IG)
• Forward P6P packets between P6P sites and their
  associated External Gateway (EG).
• Have unique P6P addresses.
• Are used by hosts within the P6P site as their
  gateway.
• Each P6P site must be connected to at least one
  IG.
• IGs may share a common EG.

10
P6P Architecture

• External Gateways (EG)
• Exchange encapsulated P6P packets via tunnels
  created within the core Internet.
• Maintain routing tables mapping P6P site
  identifiers to a set of address records.
• Records containing the tunneling protocol and the
  peer EGs protocol address IPv4, UDP/IPv4, IPv6,
  etc.

11
Figure 1
An example of two P6P sites connected to a core
IPv4 network.
12
P6P Routing

• P6P sites are location independent.
• Thus they require a non-hierarchical mapping to
  EGs.
• In P6P distributed hash tables (DHT) have been
  selected to fulfill this requirement.
• Other are discussed later.

13
Basic Protocol

• Each EG runs a DHT agent to maintain the DHT
  routing protocol.
• Each EG maintains a cache containing a subset of
  the entire mapping.
• Initially, the cache contains a listing for the
  particular EGs own site identifier and the
  protocols it supports.
• EGs also maintain records of any Internet Service
  Providers (ISP) to which they are connected.

14
Basic Protocol

• INSTALL message consists of the P6P site
  identifier and address records.
• Upon receipt of an INSTALL message the EG copies
  the routing information into the local routing
  table.
• Upon receipt of a P6P packet from an IG, the EG
  checks for cached routing information and routes
  accordingly if the record exists.

15
Basic Protocol

• If the EG does not find the required information
  to route a P6P packet it sends a LOOKUP request
  to DHT(id) against the DHT.
• Responses contain the requested routing
  information provided by the EG serving the
  requested P6P site and are routed via the core
  network rather than via the DHT to the return
  address in the LOOKUP request.

16
Basic Protocol

• Piggybacking EGs send a limited number of
  un-requested routing data with each routing
  message sent as an optimization.
• Currently, K most recently requested entries are
  returned.

17
Updating Address Records

• Address records are not static.
• However, isolating sites from how they access the
  core Internet reduces the need to update
  addresses to switching of ISPs.
• Routing tables are still treated as cached data
  although updates are needed less frequently.
• To be successful, P6P must balance freshness
  with overhead.

18
Updating Address Records

• P6P takes advantage of the grace period given
  when addresses or ISPs are changed.
• Ttransition The transition time within which
  updates must occur.
• Version numbers control the replacement of
  routing data.
• Routing tables contain timestamps for each record
  change.

19
Updating Address Records

• Trefresh Each EG increments the version number
  of its own mapping at a static refresh interval
  and whenever its address record changes.
• Texpire When routing P6P packets, EGs check
  whether a mapping exists or whether an existing
  mapping is older than a static expiration
  interval.
• If either is the case, a fresh LOOKUP is
  performed.

20
Updating Address Records

• The following should hold
• Trefresh
• Ttransition is expected to be in the order of
  days.
• In the prototype Trefresh is 15 min. and Texpire
  is 30 min.

21
Security

• Public key cryptography prevents attackers from
  installing unauthorized DHT entries.
• Paired X.509 certificates, owner and map, are
  stored in the routing table.
• Owner certificates validate P6P sites.
• Map certificates validate mappings within the
  network and contain the version number to prevent
  replay attacks.

22
Security

• Map certificates are signed with the private key
  of the P6P site owner.
• LOOKUP replies contain both owner and map
  certificates of the responding EG.
• Upon receiving an INSTALL message each EG checks
  the certificates of previously unknown mappings.
• EG maintain an owner certificate, a private key
  to sign mappings, and the Certificate Authoritys
  (CA) public key.

23
Evaluation

• Focused on routing table misses necessitating a
  LOOKUP.
• Interested in missed ratio and routing load
  across the EGs as functions of N (number of P6P
  sites) and K (the number of piggyback entries
  used).
• Churn was ignored as it is expected to have
  little impact as previously stated.
• However, future studies are planned to examine
  this assumption in greater detail.

24
Evaluation

• Simulations consisted of
• 1000 rounds with N micro-rounds.
• During each micro-round a packet was sent from
  randomly chosen source sites to randomly chosen
  destination sites according to a Zipf
  distribution.

25
Evaluation

• The first series of simulations fixed K 8.
• The miss ratio was computed as (misses / N) as a
  function of the round number.
• Misses appear to decrease logarithmically with
  time until about 90 of look-ups can be performed
  locally.
• Note that the x-axis is logarithmic.

26
Figure 2
Average miss ratio as a function of round number
for various N. K 8.
27
Evaluation

• The second series of simulations fixed N 4096
  and varied K.
• Piggybacking improves performance considerably
  over not piggybacking.
• Increasing K only gradually improves performance.
• Again the x-axis is logarithmic.

28
Figure 3
Average miss ratio as a function of round number
for various values of K. N 4096.
29
Evaluation

• Finally, a series of simulations focused on load
  as a function of N.
• Examining the average number of look-up requests
  divided by N in the 100th round of the
  simulation.
• For K 0 the load appear to grow logarithmically
  indicating that P6P scales well.
• Again, choosing a larger K does not appear cost
  effective.

30
Figure 4
Average load on EGs in round 100 as a function of
N.
31
Evaluation

• Initial concerns about the effects of site
  popularity on the network load balance were not
  born out in the simulations.
• Piggybacking appears to have ensured a reasonably
  distributed load.
• The next step is large scale deployment to obtain
  realistic latency data.

32
Discussion - Alternative Routing Protocols

• Reverse DNS
• Look-ups against the P6P site identifier would
  require the introduction of a new DNS record
  type.
• Would require a separate protocol to support
  piggybacking to ensure that DNS does not become
  overloaded.

33
Discussion - Nested Deployment

• A P6P sub-site can be deployed within an existing
  P6P site or within a sites internal IPv4
  network.
• A private DHT or a simpler mapping mechanism
  could tie sub-sites together.
• Site identifiers would require subnetting.
• Internal EGs will need to be able to distinguish
  between local and externally addressed packets
  according to the mapping mechanism.

34
Multihoming, Multicast and Robustness

• P6P supports the attachment of policies to
  address records to specify primary links or for
  traffic engineering.
• Thus multihoming is trivial.
• P6P supports application level multicasting
  (e.g., Narada and Overcast ).
• P6P can also be extended to support routing
  robustness by exploiting ideas from RON 1 and
  Detour 2.

35
Related Work

• Authors originally proposed a P2P implementation
  of IPv6 in 2002.
• P6P trades off generality for scalability by
  aggregating IPv6 addresses for each P6P site.
• Global, Site, and End-system (GSE) addressing
  expands on the notion of separating identifiers
  and locators.
• GSE is a header re-writing technology similar to
  Network Address Translation (NAT).

36
Related Work

• GSE varies from P6P which is a layering
  technology in which locators are not visible to
  hosts.
• This results in a clear separation of network and
  transport layers.
• Unmanaged Internet Protocol (UIP) advocates
  naming and routing separation but aims at
  ubiquitous network computing.

37
Related Work

• Host Identity Payload (HIP) also proposes
  decoupling of network and transport layers but
  would require a new IANA protocol number and
  changes to DNS.
• IP Next Layer (IPNL) is an alternative IPv6
  proposal.
• IPNL would be layered on top of IPv4 using
  NAT-boxes using DNS domain names as addresses
  with their structure controls routing.

38
Related Work

• IPNL exhibits properties similar to P6P but would
  require large software deployments.
• PeerNet proposes replacement of the IP layer with
  a P2P protocol targeted at routing within
  wireless networks.

39
Related Work

• Internet Indirection Infrastructure (I3) is
  similar to P6P in many respects but requires a
  new API whereas P6P utilizes the existing IPv6
  API.
• P6P relies on transitioning mechanisms inspired
  by 6to4, ISATAP, and Teredo.

40
Conclusion

• P6P
• Is an overlay routing architecture.
• Implements IPv6 routing transparently to
  end-hosts.
• Simplifies transition to IPv6.
• Adds value to IPv6 by permitting end-host
  addresses to be administered separately from
  those used in the core infrastructure.

41
Conclusion

• P6P
• Permits renumbering of the core Internet, ISP
  switching, and multihoming without reconfiguring
  entire sites, breaking connections, updating DNS,
  mutual cooperation of ISPs, or increased load on
  core routers.
• Can be extended to support multicasting and
  robust routing.

42
Conclusion

• P6P
• Is easy to deploy.
• Can be deployed incrementally.

43
References

• R. van Renesse, and L. Zhou. P6P A
  Peer-to-Peer Approach to Internet
  Infrastructure. The 3rd International Workshop
  on Peer-to-Peer Systems, San Diego, CA, USA,
  26-27 Feb. 2004.
• 1 D.G. Andersen, H Balakrishnan, M.F. Kaashoek,
  and R. Morris. "Resilient Overlay Networks." in
  Proc. of the 18th ACM Symp. on Operating Systems
  Principles, Banff, Canada, Oct. 2001, pp.
  131-145.
• 2 A. Collins. "The Detour framework for packet
  rerouting." M.S. thesis, University of
  Washington, Seattle, October 1998.