Subject: [p2p-sip] dhts

From: RoyR at saic-abingdon.com (Roy, Radhika (AEAD))
Date: Wed Nov 2 10:37:07 2005

Hi, Eunsoo:

I am starting with your statement:

 "... What I thought was something like a common message structure as
the base and different payloads for different overlay algorithms. .."

Yes, if we can agree to create a "common" message structure, and  p2p
entities can use those messages for signaling among themselves this is
what I mean a single p2p protocol. This serves the purpose what I have
been saying.

Definitely, there will be different kinds of "payloads" within the said
p2p protocol to meet different requirements such as algorithms,
discovery, lookup, transport, security, triggering of
contents/applications, etc.

It means that the proposed p2p protocol may invoke/trigger or require or
call upon a host of other protocols to meet the specific requirements.

With respect to your questions related to
domains/inter-domain/node/supper-nodes, I believe, these are
architectural problems, and is NOT so much about protocol problems. I
guess that it could also be taken care of once the base p2p protocol is
developed. 

Of course, if anything needs to be taken care of early on that will
influence the development of the p2p protocol in view of the
/inter-domain/node/supper-nodes, definitely, we have to keep a provision
for those especially for extensibility.

Sure, like David and Philip, you have also made some good points.

Best regards,
Radhika

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, November 02, 2005 5:37 AM
To: Matthews, Philip (Philip)
Cc: David A. Bryan; Roy, Radhika (AEAD); [email-masked]
Subject: Re: [p2p-sip] dhts

Hmm.... probably another terminology issue.
I think 'hierarchical architecture' can have two meanings in P2P SIP.
One is something like supernodes and non-supernodes where supernodes are
not necessarily related to domain boundaries. In that sense, you can
have a hierarchical P2P network even within a (administrative) domain.
Another is something like federation of domains with inter-domain
networking.
That is, 'hierarchical architecture' does not necessarily mean
multi-domain or federation of domains.
I guess Philip is using the term as federation of domains.

I think an architecture supporting federation of domains has significant
merit in that it provides scalability and flexibility in configuring
individual domains and we need to support it eventually. The idea of
algorithm Z for inter-domain operation and algorithm X and Y for
intra-domain operation seems quite natural. It reminds me of
inter-domain routing protocols and intra-domain routing protocols in IP
routing. However, we can see that an algorithm for inter-domain
operation is not necessarily the simplest or default algorithm in IP
routing. This may not be necessarily the case for P2P SIP but I think it
provides enough motivation for us to be cautious. And most likely
dealing with federation of domains will add more complexity to the
architecture and algorithm even though I don't know how much.

I think we agree that we should start with simple algorithms. So I'd say
we look for simple and reasonably good overlay algorithms in general
rather than specifically something for inter-domain operation in the
beginning. That is, I'd suggest we should first look for simple and
reasonably good algorithm X and Y for individual domains.

Regarding one protocol and multiple algorithms, I also agree that
different algorithms are likely to have differences in information in
messages and even in message flows. What I thought was something like a
common message structure as the base and different payloads for
different overlay algorithms. It is debatable whether such a thing is
one protocol or multiple protocols as David pointed. But that approach
looks better to me than creating totally new and different message
structures for each overlay algorithm. It seems feasible at least for
DHTs. What do you think?

Regards,

Eunsoo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20051102/05623dd5/attachment.html

---

From: dhara at research.avayalabs.com (K. Kishore Dhara)
Date: Wed Nov 2 11:50:46 2005

Radhika,

> what I mean a single p2p protocol. This serves the purpose what I have 

I agree that a common message structure is important, but a) contents of 
the structure and b) the semantics of the structure are key issues as 
well.  Does the common P2P protocol  contain information that is 
required for the protocols (and algorithms) used by various P2P systems 
(say X and Y)? If it does, then should it be intrepreted by X and Y in 
the same way?  I see one  way of trying to do that is in addition to the 
common structure, we should try to achieve an abstraction that can 
contain information needed by various algorithms and is flexible enough 
to let me them interpret in their own way (or may be even have some sort 
of lose semantic framework for interpretation, not sure though).  Is 
this achievable?  Well, I think first we should flush out the requirements.

Regards,
-- Kishore