Subject: RE: [P2Prg] SIP

From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" <[email-masked]>
Date: Mon, 8 Dec 2003 12:49:06 -0600

> What are the requirements of a P2P system
 
 "those who can, do, those who can't, write
  requirements documents" 
         - Noel Chiappa 
 
 "in some cases we have gone from "rough 
  consensus and working code" to "fine 
  requirements and forbidden code". 
         -  Henning Schulzrinne 
 
It often doesn't limit the scope. The requirement document 
will have multiple goals which contradicts each other. It 
is hard to define a solution based on that... On the other 
hand, it is necessary for areas where problem space and 
solutions are not currently defined.

We have seen two generations of P2P systems. The initial 
wave of napster focusing on file sharing. If you ask me, 
the first generation is actually design of mail and inter
domain routing systems (which is P2P in nature.) then, 
the 2nd generation with lot of building blocks (DHT based 
systems,skip nets, gnutella etc.) Now, we are in 3rd 
generation i.e. P2P systems put in main stream use i.e. 
data management, group communication and storage etc. 

Also, Peer to Peer has also seen wide deployment. It is 
difficult to write requirements (which everyone will 
agree) at this stage.

Instead, sent us text in the form of solutions. Lets get
down to task .i.e. what features of SIP will be useful
to enable your favourite p2p system? How SIP name space
can be exploited? Is SIP a dead cat and so, P2P can't
use them?

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

---

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 08 Dec 2003 14:57:58 -0500

> "those who can, do, those who can't, write

And here's another one:

"What we learn to do, we learn by doing."

Arundatti Roy

Nice sayings! None the less, it would be a good idea to know what the 
desired features are. Why are we trying to generalize anything?  If one 
cannot adequately decide on a working description of a P2P system the 
point of this whole research group is moot one might just  whole 
discussion group with [email-masked] or the equivalent gnutella 
group or what have you. Why bother with a general set of protocols for 
P2P systems? What do we want such a system to do? If it is just about 
finding peers and establishing peer to peer connections then sip does 
the job and we need go no further. So I have to ask again:

-  what , in the opinion of the group is a P2P system? I ask this 
because I only have some hazy picture in mind. (kindly forget the usage 
of the term "requirements document" as it seems to be offensive) I 
simply seek to know what we want such a system to do in the first place.
-  What is the mission of this group? Is it to come up with an 
architecture for P2P and an open scalable set of protocols for the (as 
yet undefined) P2P systems? If so, it would be a great idea to have a 
working definition first.

I dont see a rough consensus on what a P2P system is just yet. Maybe it 
is because I have not read some key document. It is important to get a 
clear definition to limit the scope of activity.

>
>Instead, sent us text in the form of solutions.
>

If only I knew what problem I were trying to solve I might attempt to 
solve it.... Philosophical eh?

> Lets get
>to enable your favourite p2p system?
>
>How SIP name space

-- 
M. Ranganathan 

Advanced Networking Technologies Divsion,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 

tel:301 975 3664 , fax:301 590 0932 , http://www.antd.nist.gov/~mranga

Advanced Networking Technologies For the People!

---

From: Mauricio Arango <[email-masked]>
Date: Tue, 09 Dec 2003 10:33:58 -0500

Hi Ranga,

I'm not going to attempt defining P2P, but to address the area
of discovery, where P2P and SIP could combine nicely.

SIP provides session control functions, as pointed out by Paul Francis.
However, SIP doesn't have a discovery mechanism, it doesn't address
how SIP-based applications obtain SIP URL's. Providing a rich, content
addressable discovery mechanism is an area where P2P could enrich
SIP-based applications.

Regards,

Mauricio

------------------

"M. Ranganathan" wrote:

> desired features are. Why are we trying to generalize anything?  If
> one cannot adequately decide on a working description of a P2P system
> the point of this whole research group is moot one might just  whole
> because I only have some hazy picture in mind. (kindly forget the
> usage of the term "requirements document" as it seems to be offensive)
> I simply seek to know what we want such a system to do in the first
> place.
> I dont see a rough consensus on what a P2P system is just yet. Maybe
> it is because I have not read some key document. It is important to
> get a clear definition to limit the scope of activity.
>
>
>
>

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 09 Dec 2003 11:58:47 -0500

Hi Mauricio,

Rather than trying to define the undefinable and in the interest of 
making progress, I am going to resign myself to the fact that  an 
operational definition for P2P as defined by the subgroups in this 
working group is fine for now. ( Senthil may agree with this. :-)  )

Getting back to the topic, I note the following :

SIP Provides session control and routing functions. Further, SIP 
transactions are asynchronous ( and have notions of timeouts etc. ). 
Long running transactions even have provisional responses that can be 
issued by upstream components. Note that SIP Does not necessarily define 
how messages get routed before a dialog is established. Thus I would go 
further and say that routing of messages that are essentially queries 
for resources that a User Agent may want to discover (ie. content based 
routing) are also in the scope of SIP and can be supported by SIP. For 
example, lets say you were interested in finding a file called 
"myfile.txt", you  can route through a set of proxy servers that have 
partial knowledge of where the file may be found. The partial knowledge 
may be stored in a routing cache (this is the way JXTA does it I 
understand).

In picking something concrete to do to experiment with this idea and 
work out the details, I have been contemplating building an open P2P 
protocol (such as JXTA) on top of SIP. Would this be a reasonable proof 
of concept that you might be interested in participating in?

Best Regards,

Ranga.

-- 
M. Ranganathan

---

From: Mauricio Arango <[email-masked]>
Date: Wed, 10 Dec 2003 09:55:14 -0500

Hi Ranga,

I agree that SIP's overlay network of proxies supports
routing at a higher level than IP routing. And it could be used to
experiment
on various kinds of routing methods for P2P.

However, SIP routing is done only based on the destination's URL, which
in my view is very limited. So it is content based routing but only
based on the content of the destination URL, which is a limited size
and format string.

In order to support richer content-based routing with SIP it would
be necessary to route messages not only based on the destination URL
but also based on additional information stored in the SIP message.
This of course may be possible, but then I'm not sure if it would
require changes to SIP and if there are other protocol infratrucuters
such as JXTA that could provide more flexibility.

Regards,

Mauricio

----------------------------

"M. Ranganathan" wrote:

> issued by upstream components. Note that SIP Does not necessarily
> define how messages get routed before a dialog is established. Thus I
> would go further and say that routing of messages that are essentially
> queries for resources that a User Agent may want to discover (ie.
> content based routing) are also in the scope of SIP and can be
> supported by SIP. For example, lets say you were interested in finding
> a file called "myfile.txt", you  can route through a set of proxy
> servers that have partial knowledge of where the file may be found.
> The partial knowledge may be stored in a routing cache (this is the
> way JXTA does it I understand).
>
> protocol (such as JXTA) on top of SIP. Would this be a reasonable
> proof of concept that you might be interested in participating in?
>
> Best Regards,
>
> Ranga.
>
> Mauricio Arango wrote:
>
>> Hi Ranga,
>>

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 10 Dec 2003 10:52:59 -0500

Hi Mauricio,

I dont think it would break the protocol to do routing based on more 
than just the destination URL. If my understanding is right, a routing 
element (proxy) can do whatever it wants to determine the next hop 
address, including looking up DNS and a location service for support of 
mobility. Of course, both these just use the Sip URI for lookups. Once 
the route is established, in the dialog, it remains that way until a 
re-invite for the dialog changes the route. I dont thing anything 
seriously breaks if  you consider the entire message in determining the 
next hop for the message instead of just the Request URI. I'll ask in 
the sipping news group and maybe I'll get a response to the contrary. 
Someone chime in with an explanation if I am way off mark here.

Lets consider JXTA as a concrete example (indeed the only P2P system 
that I am familiar with): Just a thought - say the above hypothesis were 
true, and there were a nice interface to the JXTA routing cache (which 
caches all kinds of things including the association between JXTA urns 
and IP addresses, peer advertisements and other resource 
advertisements), then rather than forward messages using JXTA, one could 
use SIP as the signaling protocol to frorward the jxta messages. So JXTA 
just provides a distributed caching service and the signaling is done 
through SIP. An end to end pipe would still have the same semantics and 
do the same thing as it currently does but all the messages that are 
used to set it up would be sip messages and setting up the end to end 
pipe could be done using SIP.   Its been a while since I looked at JXTA 
so I may be jumbled in my terminology. However, what I am saying is that 
one can tunnel JXTA control messages in SIP.

On the other hand, if I understand what Bill was saying earlier, one 
should consider P2P protocols as being lower level than SIP - which 
would argue for tunneling SIP messages in JXTA and this whole discussion 
is moot.

I dont know what the right design choice would be but just in terms of 
deployed base (3gpp, msn messenger and whatnot) I am leaning towards the 
former modulo any design problems with routing etc. that need to be 
worked out.

Ranga.

-- 
M. Ranganathan

---

From: Mauricio Arango <[email-masked]>
Date: Wed, 10 Dec 2003 14:56:20 -0500

Ranga,

It's not that SIP would break by using other information in the message,

but that the only information in a SIP message that describes the
required
resource is the Request URI. The SDP-based information in a SIP Invite
message describes only the source of the request, doesn't describe the
required
resource or destination.

It could be possible to describe the destination via SDP (or XML, tec),
but carrying
this info, I assume, would require changes to SIP.

Regards,

Mauricio

------------------------------

"M. Ranganathan" wrote:

> address, including looking up DNS and a location service for support
> of mobility. Of course, both these just use the Sip URI for lookups.
> Once the route is established, in the dialog, it remains that way
> until a re-invite for the dialog changes the route. I dont thing
> anything seriously breaks if  you consider the entire message in
> determining the next hop for the message instead of just the Request
> URI. I'll ask in the sipping news group and maybe I'll get a response
> to the contrary. Someone chime in with an explanation if I am way off
> mark here.
>
> that I am familiar with): Just a thought - say the above hypothesis
> were true, and there were a nice interface to the JXTA routing cache
> (which caches all kinds of things including the association between
> JXTA urns and IP addresses, peer advertisements and other resource
> advertisements), then rather than forward messages using JXTA, one
> could use SIP as the signaling protocol to frorward the jxta messages.
> So JXTA just provides a distributed caching service and the signaling
> is done through SIP. An end to end pipe would still have the same
> semantics and do the same thing as it currently does but all the
> messages that are used to set it up would be sip messages and setting
> up the end to end pipe could be done using SIP.   Its been a while
> since I looked at JXTA so I may be jumbled in my terminology. However,
> what I am saying is that one can tunnel JXTA control messages in SIP.
>
> would argue for tunneling SIP messages in JXTA and this whole
> discussion is moot.
>
> deployed base (3gpp, msn messenger and whatnot) I am leaning towards
> the former modulo any design problems with routing etc. that need to
> be worked out.
>
> Ranga.
>
>
>
> Mauricio Arango wrote:
>
>> Hi Ranga,
>>
>> >> > Nice sayings! None the less, it would be a good idea to know
>> >> > what
>> >> > the
>> >> > group or what have you. Why bother with a general set of
>> >> > protocols
>> >> > for
>> >> > finding peers and establishing peer to peer connections then
>> >> > sip
>> >> > does
>> >> > architecture for P2P and an open scalable set of protocols for
>> >> > the
>> >> > (as
>> >> > yet undefined) P2P systems? If so, it would be a great idea to
>> >> > have
>> >> > a
>> >> > If only I knew what problem I were trying to solve I might
>> >> > attempt
>> >> > to

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 11 Dec 2003 08:39:26 -0500

Hi Mauricio,

I agree with you although I am not sure that routing based on message 
content changes the protocol in any fundamental way. The protocol is 
basically centered around Dialogs, Transactions and messages. I would 
contend (possibly incorrectly) that the way in which messages out of 
Dialog are routed is left fairly open in the protocol ( for example 
Location Servers, DNS lookup etc.) That being said, it IS true that all 
these schemes rely just on the request URI. Indeed, they just rely on a 
portion of the request URI.

One might note that all headers of an entire SIP message may be 
parameterized in the request URI as header parameters. This is ugly to 
be sure but it is possible (ie. 
sip:foo.bar.com;method=INVITE;contact=127.0.0.1  is a valid SIP url -  
one can invent a new header called MyPeerToPeerHeaderMatchCriterion and  
parameterize an entire XML document resulting in a URI that is amazingly 
long, undecipherable and ugly (ugh!).   Now that would be stretching it 
to be sure but one could route on request URI alone in that case. )

OK moving on, would it not be possible to content based routing based on 
just the URI by using UUIDs for resources. I agree that using this would 
make it impossible to do partial matching. In short I think one can work 
around routing without departing from the protocol in any fundamental 
way. I invite SIP (no pun intended) experts to contradict and correct 
this point of view. I'll open up a discussion on SIP Implementors to vet 
this.

Regards

Ranga

-- 
M. Ranganathan

---

From: Bill Yeager <[email-masked]>
Date: Thu, 11 Dec 2003 12:14:11 -0800

On Dec 9, 2003, at 8:58 AM, M. Ranganathan wrote:

> Thus I would go further and say that routing of messages that are 
> essentially queries for resources that a User Agent may want to 
> discover (ie. content based routing) are also in the scope of SIP and 
> can be supported by SIP. For example, lets say you were interested in 
> finding a file called "myfile.txt", you  can route through a set of 
> proxy servers that have partial knowledge of where the file may be 
> found. The partial knowledge may be stored in a routing cache (this is 
> the way JXTA does it I understand).

No, Jxta does not work like this. It is much, much richer. How do I 
know? I helped write the original specifications, and was the CTO of 
Jxta for two years. This isn't the appropriate place to go into the 
details of the Jxta protocols. Routing itself is extremely complicated. 
It may be too complicated as implemented there.

We looked at SIP again as a way to set up chat rooms, or other group 
conversations and there are those doing just that at the application 
layer now from what I hear.

The problems that we must solve in the beginning are much simpler 
though, and I don't see at all where SIP plays. Assume a purely ad-hoc 
P2P network. No formal registration except the configuration knowledge 
of what Jxta calls a rendezvous/relay. Rendezvous are for discovery and 
relays are for routing.

Now, to stay simple, suppose we have two peers, p1 and p2, and each is 
either NAT bound or firewall bound.  What mechanisms shall we use so 
that p1 and p2 can

	1: Find one another
	2: Communicate with one another securely (say a full TLS connection 
end-to-end)

How does Jxta approach this? Lets assume further that p1 and p2 both 
have 10.0.1.2 as IP addresses, both use NAT,  and that their NAT boxes 
us DHCP to get the NAT external IP address.

Jxta creates an overlay network. Remember, some of us will be working 
on that subgroup. Every peer node has a unique UUID and a peerName. 
This information along with "real transport information" and other 
details are placed in an XML peer advertisement. Therefore:

(*) Every peer node has a peer advertisement

(**) There is thus an overlay network which is the {peer UUID(i) :  i = 
1, 2, ..., n}, where n has no fixed upperbound.

This leads to problems of scale, so Jxta then defines peer groups, 
which are subcollections of these peer UUID's that have a unique UUID 
and a name. Membership itself is determined by peer group policy which 
is one of the parameters describing the peer group. Membership can 
require strong authentication, and thus peer groups can form "walled 
gardens."

When a peer boots it is in the NetPeerGroup for sake of consistency. 
This context is not particularly useful for applications and thus peers 
pretty quickly join (join is another protocol) a private peer group, 
eg, for a chat session. There are also peer group XML advertisements.

Well, how in the world do peers communicate? To accomplish this Jxta 
has pipes which are like virtual ports on the overlay network. Pipes 
are in the context of a peer group, they have UUIDs, and the peer group 
ID is part of this UUID. Yes, there are pipe advertisements: unicast, 
unicast secure, propagate (multicast).

That is a rough description of the UUID's, advertisements and overlay 
network they define. Now, it gets very interesting. We throw the 
rendezvous in the mix, and they also have advertisements. Every edge 
peer has a hosting rendezvous which is necessary unless all of the 
edge-peers of note are in fact on the same IP subnet and IP multicast 
is enabled.

Finally, how does jxta solve our discovery problem? Roughly, when local 
advertisements are created, each peer uses the Shared Resource 
Distributed Index (SRDI) to index them on its rendezvous. The 
rendezvous using a DHT replicates these indices. Discovery, thus does a 
DHT lookup. It usually begins with a pipe advertisement. This yields 
the peer ID of a peer that has this advertisement. Roughly, the peer ID 
is also hashed, and a lookup yields its peer advertisement, rendezvous, 
etc... The querying peer node's query is then send to the that peer 
either directly or by using its relay. The relay maintains an "inbox" 
like cache that the destination peer node accesses to get the jxta 
message. Thus, we have NAT and firewall traversal. The response to the 
query follows, etc ...

I'm not going to go any further here. But, I do not understand how SIP 
can begin to emulate all of this. And, I still argue that SIP belongs 
at the application layer. One can stretch protocols beyond their 
original scope, and engineers tend to do this.

Our first priority is to really understand what we must do to implement 
a collection of P2P protocols that not only deal with today's 
applications but with those applications we have not even dreamed of. 
The latter applications will be limited by what we do. I think that 
using SIP will lock the future into a single box that even if it is 
elastic has limits beyond which it will tear.

> proof of concept that you might be interested in participating in?

Sure, enjoy doing that. But do note that the Jxta platform 
implementation is about 510 source java files. The protocolS are quite 
rich.

Let's move on to our research subgroup efforts ... I'll be getting the 
work done to have the separate mailing lists in place by next week.

A+

Bill