Subject: [P2PSIP] separate message for service lookup?

From: "John Buford" <[email-masked]>
Date: Fri, 14 Mar 2008 11:28:05 -0400

Regarding Henning's comment that DHT lookup seems sufficient
for handling service lookups, there have been a number of
papers which directly use the DHT for
- serving DNS records
- locating relay peers in an overlay, including discovery
   by network position
- location telephony feature serving peers in an overlay
- locating servers for other service discovery mechanisms like SLP

no modification to the DHT or overlay protocol was needed to
support these cases.  as long as you can describe a service
with a key that all participating peers understand, the DHT should
work for service lookup.

there are some cases where the service-related resource's
availability is dynamic (e.g., relay load for admission control),
which could be part of the advertisement.  then there is a
tradeoff between updating the DHT-stored advertisement when
the load changes or leaving it for service invocation time for
the invoking peer to find out.

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 Mar 2008 11:33:48 -0400

> the invoking peer to find out.

It is, however, more difficult to provide weighting and/or adaptive  
load balancing to services using a DHT lookup than it might be with  
other techniques.

It is also difficult to rank services on their network-path  
optimaility unless such a ranking is implicit in the underlying DHT.  
Finding a network path efficient relay is very important for reducing  
latency in real-time media flows.

--
Dean

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Fri, 14 Mar 2008 16:39:29 +0100

>  with a key that all participating peers understand, the DHT should

If I understand it correctly, do all peers need to know a Service-ID
(exact matching search) to discover its associated service provider?
What happens if a peer wants to publish a new (non-well-known) service
into the overlay?

Thank you,
-- 
Victor Pascual Ávila

---

From: "John Buford" <[email-masked]>
Date: Fri, 14 Mar 2008 11:41:44 -0400

> load balancing to services using a DHT lookup than it might be with

I agree but I don't see that load balancing in the DHT is strictly
a problem for service lookup

> latency in real-time media flows.

One dimension of the network path (relative position to the endpoints)
can be accomdated using the DHT, for example using an
internet coordinate system.  e2e capacity of the path is another
dimension which could involve post-discovery steps.

John

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Mar 2008 15:46:02 -0400

There are many different ways to identify services and to identify  
candidates. However, since the DHT structure generally has no  
relationship to network or geographic topology, I don't see how this  
relates to finding a (topologically) nearby server.

---

From: "John Buford" <[email-masked]>
Date: Fri, 14 Mar 2008 16:03:34 -0400

> relates to finding a (topologically) nearby server.

We did some experiments using network position determined by
a peer's ICS (internet coordinate system) coordinates, specifically
using the Vivaldi algorithm.  The relay determines its coordinates
and indexes its service advertisement in the DHT using a key
which includes its coordinates aligned to a grid.  We tested this
on three internet topology data sets with 1500+ nodes and also
tested for coordinate stability given some churn.

The benefit of the DHT is that it scales nicely for large overlays
with large numbers of relay candidates to chose from.  Also the
key distribution is fairly uniform.

Since existing ICSes are known to be innaccurate we ended
up with a hybrid scheme that combines coordinate-based discovery
followed by some probing.

Details are in:

J. Buford, A. Wang, X. Hei, Y. Liu, K. Ross.  Discovery of In-Band
Streaming Services in Peer-to-Peer Overlays. IEEE Globecom 2007, Nov.
2007.

Here's the pdf of the paper:
http://www.samrg.org/p2psip/RelayDiscovery-Globecom07-PID474604.pdf

We also tested using the DHT to do location-based discovery using keys based
on geographic position, which is potentially useful in location-based service
discovery, but not relevant to relay selection.  Again, scalable and good
key distribution properties in the DHT. See:

J. Buford, A. Brown, M. Kolberg.  Meta Service Discovery.  IEEE 3rd
International Workshop on Mobile Peer-to-Peer Computing (MP2P) 2006,
March 2006.

John

---

From: Dan York <[email-masked]>
Date: Fri, 14 Mar 2008 19:14:00 -0400

John,

Thanks for passing along these references.  I'm looking forward to  
giving them a read.

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 15 Mar 2008 05:33:38 -0700

> latency in real-time media flows.

Yes, this is very true and interestingly enough seems to have been
solved by running auxiliary applications, mostly PING apps to measure
the following metrics for neighbors:

1. Latency,
2. Number of IP routing hops,
3. Bandwidth.

The DHT also plays a role. See <draft-baset-sipping-p2pcommon-00>

The impact of neighbor selection was a big topic in the DHT research
community, so I won't flood the list with more references  :-)

Henry

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean Willis
Sent: Friday, March 14, 2008 11:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [P2PSIP] separate message for service lookup?

--
Dean