Subject: [P2PSIP] Two-Stage Name Resolution

From: Ingmar Baumgart <[email-masked]>
Date: Thu, 06 Dec 2007 10:06:47 -0800

The P2PNS draft proposes to use a two stage approach to resolve AoRs to
IP addresses.

1. Resolve AoR -> NodeID (DHT layer)
2. Resolve NodeID -> IP (KBR layer)

This is motivated by some locator/ID split architectures.
The nodeID is used as location independent identifier which is
efficiently resolved to the current location (IP address) by the KBR
layer. The benefit of this design is a mostly static (AoR, NodeID)
binding in the DHT. This could be important if IP address often change
and modification of DHT records is expensive due to security mechanisms
(replication and majority votes).

Probably it depends on the application scenario which of the two
alternatives (direct storage in a DHT or two-stage stage with KBR/DHT)
performs better.

In my opinion we should at least try to keep the peer protocol flexible
enough to support both alternatives.

Any comments?

Regards,
  Ingmar

-- 
Dipl.-Inform. Ingmar Baumgart
Institut für Telematik, Universität Karlsruhe (TH)
Zirkel 2, 76128 Karlsruhe, Germany
Phone: +49 721 608 8281, Fax: +49 721 608 6789

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 6 Dec 2007 10:17:18 -0800

Please forgive my naïve question:

Could a similar technique be deployed to have a forking-like behavior?

Forking in SIP is has proven to have all kinds of problems and some replacement functionality in P2PSIP is fascinating me.

Henry

-----Original Message-----
From: Ingmar Baumgart [mailto:[email-masked]] 
Sent: Thursday, December 06, 2007 10:07 AM
To: P2PSIP Mailing List
Subject: [P2PSIP] Two-Stage Name Resolution

Any comments?

Regards,
  Ingmar

---

From: Ingmar Baumgart <[email-masked]>
Date: Thu, 06 Dec 2007 10:29:34 -0800

An AoR in the DHT could be bound to several nodeIDs or IP addresses. But
probably there will be exactly the same problems as with native SIP forking.

Please note that this is independent of the two stage approach (you
could simply store a "AoR to multiple IPs" mapping in the DHT).

Regards,
  Ingmar

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 6 Dec 2007 11:16:30 -0800

I'm concerned about any proposal that restricts resolution to
ultimately be a mapping of AoR to IP address.  (technically the Common
API paper says transport address, of which it says IP is only an
example.)   There are examples of URI->URI mapping, URI->PeerID (where
peerid is the final result because there is not direct IP
connectivity), and other combinations with small or large resources
being returned.  reload-02 uses the term "seed" to indicate that the
initial item is not necessarily an AoR or even a URI.

I haven't fully digested all the implications in p2pns, but I'm
concerned that it appears to restrict the range of mappings that are
available.

Bruce

---

From: Ingmar Baumgart <[email-masked]>
Date: Fri, 07 Dec 2007 09:43:02 -0800

This is a good point. I think the two-stage approach is only a
optimization for some use cases. The peer protocol should support all
the different type of mappings you mentioned on DHT layer. In case this
is an (AoR, NodeID) mapping you simply go for the second stage on KBR layer.

Regards,
  Ingmar

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 10 Dec 2007 13:43:47 -0500

How does P2PNS implement the KBR in the presence of NATs?  Using HITs
as NodeID has the obvious attraction that there is no mapping to an
IP,  but in other cases, there isn't a mapping to a single IP, thus
the proposals for tunneling over the overlay or establishing a direct
connection to a remote peer (identified by peerid) by using ICE.
reload-01 and p2pp both propose using a set of (ice candidate)
addresses but in all cases, fallback to full ice is required when
those don't work.

Bruce

---

From: Ingmar Baumgart <[email-masked]>
Date: Mon, 10 Dec 2007 20:59:40 -0800

Our implementation currently uses only STUN for NAT traversal. If we add
ICE support, we probably would also use a set of candidate addresses
instead of a single transport address on KBR layer.

For the two-stage name resolution this makes no difference - the second
stage simply returns the transport address(es) used in the KBR routing
table.

Regards,
  Ingmar