Subject: [P2Prg] CORE subgroup problem statement

From: "John Buford" <[email-masked]>
Date: Fri, 13 Jan 2006 17:26:33 -0500

A draft CORE subgroup problem statement
is available (attached), also on the
subgroup webpage:

  www.cs.uml.edu/~buford/irtf-p2prg/core.html

Comments welcomed.

John

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

---

From: Luca Caviglione <[email-masked]>
Date: Mon, 16 Jan 2006 15:05:39 +0100

Dear John,
I found the draft interesting. Please, find in this mail same comments.
I am reporting part of the text and inserting my ideas between the  
<LC> </LC> tags.

Best Regards,
Luca

Pag. 1:

However existing designs have limitations in one or more areas of  
scalability, security, interoperability, or generality.

<LC>
I am not quite sure there are generality problems. At least, the  
concept of generality should be defined. What I think is valuable of  
p2p, is its ability of building overlays, and then allowing some kind  
of network independency (BTW, citing JXTA is something, that recalls  
this concept). Then, you should clarify what is generality for you  
and why you think p2p can change something. Is generality something  
related to "re-usability" or a more "smart" concept, such as the  
network independent deisgn?
</LC>.

Pag 2:

The presented literature is quite comprehensive. However, I would  
consider as follows.

<LC>
Since we are talking about IETF, you can cite some good technologies,  
which are something related to service discovery. Mostly, they are  
suitable for local-small scale scenarios, but someone is thinking  
about enabling them for the global Internet. For instance:

o) RFC 2782 "A DNS RR for specifying the location of services (DNS  
SRV)" http://www.ietf.org/rfc/rfc2782.txt

o) The DNSService Discovery (http://www.dns-sd.org/). Besides, the  
DNS service discovery can be jointly used with the Multicast DNS  
(http://www.multicastdns.org/ and http://files.dns-sd.org/draft- 
cheshire-dnsext-nbp.txt). And of course, even if "human readable" and  
"rough", the DNS is related to "overlays". (http://files.dns-sd.org/ 
draft-cheshire-dnsext-dns-sd.txt)

o) You can cite also Zeroconf (http://www.zeroconf.org/).

o) And of course, one can exploit some mapping with underlying  
technologies, such as IPv6.
</LC>

Further there are various peer-to-peer overlay networks and proposed  
designs, both unstructured and structured by which large numbers of  
peers share content and services.

<LC>
 From a strict p2p point of view, there are also hybrid architectural  
flavors, such as BitTorrent. In hybrid frameworks, the centralized  
component plays a role (not being solely devoted to bootstrap). You  
know, people out there have used client-server for decades, hence I  
would be a little pragmatic.
</LC>

Typically large-scale unstructured peer-to-peer systems use limited  
scope flooding or random walk to reach other peers with requests...

<LC>
In hybrid systems, centralized component are used to locate peers and  
then directly route requests.

For instance, in eMule (I am citing file-sharing since is quite  
popular), you can use 3 different architectural flavors:
1) use server to locate via e2DK
2) use Kad (XOR-based Chord DHT ring)
3) Exchange info via hording.

Or in OpenNap
1)Use a OpenNap Server
2)Use a chained facility of OpenNap servers to route requests.

However, the basic under such remarks is that "the more the  
unstructured p2p system is large, the worse the limited scope  
flooding performs". For this reason, supernodes, centralized  
components and so on have been introduced.

Lastly, since it is a problem statement draft, I would mention that  
"limited scope flooding" does not allow to perform _exhaustive_  
searches. Then we have to be honest: p2p is great for what you  
propose, but still need to be fixed. And in a problem statement  
draft, probably will be a nicer phrase.

"Are you going to migrate DNS to an architecture that could be unable  
to resolve  some URL, because peers responsible are too distant?"
</LC>

Search: a discovery mechanism in which content or resources stored  
in  a peer-to-peer network can be searched using various methods  
including text search, keyword search, content-based retrieval or  
meta-data search

<LC>
Are they stored in the p2p network? Or are they stored in peers?

My 2 cents:

-)how the overlay is "built" states intrinsically _how to retrieve_  
(e.g., A DNS based Overlay roughly corresponds to text search).

-)peers belonging to a given overlay _store_ the content or resources.

(??? I am not fond of CDN, but CDN-literature should be inspiring)
</LC>

Service: a computational function packaged for use by other nodes in   
a networked environment .

<LC>
It sounds like "RPCs" or "Stored Procedure" stuff. It is quite clear  
the idea, but for my personal style I would avoid "computational"...  
"a portion of peer resource" is more general (maybe when you'll  
define your architectures, you'll have storage-peers, computing- 
peers... hence, it is more general).
</LC>

Pag 3:

Service description:  Information about a networked service such as  
type of service, name of service, attributes of service, location of   
service, invocation of service.  May be stored in a document or at a  
service repository

<LC>
Confusion here (for me, it is not enough clear). I can't convince  
myself about what a "Service Repository" is:

o) Service Repository: a peer containing related infos.
o) Service Repository: a boot strap server which allows to locate and  
exploit a p2p-based service.
o) A portion of the overlay.
o) A centralized component (see previous comment).

But basically: "Is Service Repository, inside or outside the p2p- 
framework?"
</LC>

The expected volume of transactions expected in a global service  
discovery mechanism is in the range of DNS lookup volume.

<LC>
How can justify such bound? "The expected volume of transactions  
expected in a global service discovery mechanism is in the range of  
DNS lookup volume."
</LC>

Pag. 4

Use of multiple service description formats which might be tailored  
by application or level of semantic description

<LC>
I appreciate this point, really.
</LC>

Access to services, service descriptions, and service  advertisements  
dependent on authorization rights

<LC>
I can see HIP at the horizon...
</LC>

The mechanism can be used in isolation by peers in PANs, ad hoc   
networks, or other limited networking environments

<LC>
Not clear what isolation is...
</LC>

Pag. 5

There are no new security considerations in this document.

<LC>
I agree. In this incarnation the security considerations are not  
pertinent.
</LC>

Il giorno 13/gen/06, alle ore 23:26, John Buford ha scritto:

> <draft-irtf-p2prg-core-problem-statement-00.txt>