Subject: [p2p-sip] NAT and Overlay Maintenance

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 28 Feb 2006 16:16:10 -0500

Hi,

It seems that there is a robust discussion going on about
P2P SIP and the participation of devices behind firewalls
and NATs.

As we know a large number of devices may exist behind
NATs and firewalls, potentially dwarfing those available
outside.

There may be significant load issues if every device
behind a NAT or Firewall makes use of a Super Node
as the referrer for location lookups in a P2P network.

I'd like to describe some of the reasoning used in describing
a two layer hierarchy as described in the arch draft, and
elicit further comment regarding the assumptions we made,
and also the conclusions drawn.

So to summarize the draft (perhaps inappropriately: please
read it).  we:

* Classify the network into Ordinary nodes and Super Nodes.

* Supernodes are involved in Overlay Maintenance

* Ordinary Nodes are not.

* Either node can place data records into the P2P Overlay

* Super Nodes assist Ordinary Nodes to join the overlay.

* after bootstrap, SNs only perform get(), update() and add()
  operations on behalf of ONs

* Media/SIP (TURN) relaying operations may be done by non overlay
  nodes, or by a service co-located with an SN.

At issue here:

* Super Nodes are only drawn from the pool of publicly addressed/
  reachable nodes.

As described by Sathya, this is the inter-network view of things,
based on the fact that devices behind NAT are difficult to
reach reliably.

For P2P overlay networks which remain within an administrative
domain, the addressing requirement may not be strictly necessary
(the reachability may be though).

So let's explore the assumptions underpinning the idea that SNs can
only be publicly addressed (with Sathya's caveat):

* Inbound messages need to be supported.
  - an SN needs to be able to receive overlay update and lookup
    messages from other peer SNs

* The stability of the Overlay network is at the mercy of weak nodes
  - where a portion of the name/location lookup information is stored
    behind a NAT, failure of the NAT, the NAT mapping or a TURN relay
    effectively isolate a portion of the overlay network.
  - this could cause significant damage to the data held on the overlay

As such, the role of overlay maintenance nodes has been delegated to
the fully reachable SNs.

* Ordinary Nodes may fail without affecting the overlay maintenance.

* Nodes which have a reachability impediment are not eligible for
  Overlay Maintenance (SN) roles.

Please be aware that alternative mechanisms to handle peer-to-peer
operation within an isolated domain, and then connect it to the
global network (even if that global network is partly P2P).

In the current draft, this scenario could use P2P internally, and
may use a SIP Proxy with some P2P function (a P2PProxy) to cross an
administrative domain to the global network. Some additional media
relaying function may yet be required (for establishing inbound
media paths for example).

Please note that the P2P proxy may not need to be an SN on the
global network, in order to perform the lookup operations, and
advertise the domain.

Greg