Re: [P2Prg] CORE subgroup problem statement

[buford at research.panasonic.com]

Dear Luca,
Thanks very much for the detailed and useful comments.  Responses below.
Best regards,
John

> 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>.

<JB>
Yes, I agree that p2p overlay and index mechanisms are quite general. 
But some p2p systems are application-specific (e.g., file sharing, voip)
so not being general-purpose is meant from service-offering standpoint.  
So generality has to do, in my opinion, with supporting any type of service.
</JB>

> 
> 
> 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>

<JB>
Yes, thanks for these suggestions.  Definitely RFC2782 and multicastdns and zeroconf.
However isn't IPv6 an enabling technology?  
</JB>

> 
> 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>

<JB>
Yes agree.  In fact the P2P overlay survey we posted had hybrid in the taxonomy.
Good point.
</JB>


> 
> 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>

<JB>
Good points, this can be cited, do you suggest citations for eMule and OpenNap
technical details?
Also, we kept the overlay discussion short in the problem statement since 
we have proposed in the charter to prepare a separate survey document.
So some of this discussion might go there.

Regarding the chance of not finding something that is stored somewhere in the overlay,
yes it doesn't seem like a desirable scenario. 

What would be nice from a research standpoint is to have a probabilistic formula
as a function of size, architecture, churn, average node lifetime, replication rate,
and index pollution, etc. of finding an item stored in the overlay.
</JB>


> 
> 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>

<JB>
Why is the distinction between storage in the peer vs p2p network important?
Consider a system like OpenDHT where some node which is not part of the
p2p system can insert and lookup into a p2p index formed by another set of 
nodes.  from the client node standpoint, the p2p index could just as well
be a single server, and the storage is somewhere in the collection of nodes,
hence "p2p network".  Also there is the case of replicated entries, and
cases where we might split up an object into parts before indexing
each part.

Regarding "how the overlay is built ... how to retrieve".  I am not sure.
A number of proposals develop complex mappings and lookups on to a simple
hash-base index.

Agree that CDN is relevant.  Seems like a lot of CDN is push-oriented
model anticipating future requests.
</JB>


> 
> 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>

<JB>
How about:
Service: an interface to a resource packaged for use by other nodes in a networked environments.
</JB>

> 
> 
> 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>

<JB>
Service repository is intended to cover architectures which store descriptions at a server
(e.g., SLP, UDDI, LDAP) or proxy node.
</JB>

> 
> 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>


<JB>
I think it is an upper bound.  It seems that service invocation frequency should be much
higher than service discovery frequency.  But service discovery < DNS lookups, in that
hostname resolves due to say web browsing should occur at a higher frequency then
service discovery requests.  

</JB>

> 
> 
> 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>
> 

<JB>
That is, if say 5 peers are connected to each other but not to the Internet, they
should still be able to do service discovery among each other.
An example is if I have 5 devices in my PAN and I roaming disconnected from
other networks.
</JB>


> 
> Pag. 5
> 
> 
> There are no new security considerations in this document.
> 
> <LC>
> I agree. In this incarnation the security considerations are not pertinent.
> </LC>
> 




_______________________________________________
P2prg mailing list
P2prg at irtf.org
https://www1.ietf.org/mailman/listinfo/p2prg