Subject: [p2p-sip] Some comments on Use-cases document <KS> Slightly long e-mail </KS>

From: ksankar at cisco.com (Krishna Sankar (ksankar))
Date: Mon, 27 Mar 2006 18:29:33 -0800

Folks,

Had a chance to read thru some of the P2P SIP material - during a long layoff at the airports ! Some thoughts, the observations are not linear. I will try to make it short & crisp (as much as I can ;o)) I am still internalizing the material and so pl bear with my ignorance.

a) There are two dimensions - scenarios/motivation and feature sets.

b) First we need to bound the trajectory and locus of P2P SIP - the use case document holistically mentions lots of ideas, but we need to crisply classify (and prioritize) them in terms of likely hood, short term pain points and essential feature set.

For example, if we are enabling hastily formed networks for first responders or communication in disaster scenario or many other similar situations, we might have a case for developing a P2P substrate. 

We can, then, opt for DHT, because it enables a much valued pragmatic need. DHT is mature enough to function at this level. The question is not whether a technology is mature in absolute terms, but is it good enough to enable a pain point we are facing today.

c) The next thing is to figure out the whys, whats and finally hows, of whatever we are enabling by the P2P SIP substrate.

d) Then we also need to see what feature set we need - like anonymity (for example leveraging primitives from tor) and traffic shaping (for resource constraint devices - may be need to look at sensor networks) Are we any way connected with domains like Ad-Hoc networks ? Do we need to embed primitives from the various usage patterns ?

The scenarios vs. feature set is very important for the mechanics and mechanisms we embed - using a P2P in normal internet would require strong anonymity primitives while in a hastily formed network might require bandwidth conservation and resource maximization with less chatty protocols.

e) In any case, our goal should be an orthogonally extensible framework not a tightly coupled set of messages, thus trying our best for flexibility in the face of future technological and algorithmic innovations

f) Are we (i.e. P2P SIP) in the control path or in the data path ? The requirement document has both and that puzzles me, because once a P2P substrate is in the data path, we need to figure out strong anonymity as well as traffic shaping ! People might be charged with $ for the bandwidth they are brokering. Then we will have to resort to BitTorrent-like reward mechanisms, fair bandwidth shaping et al. One idea is to have Tor-like super nodes.

g) As we read thru the documents, we also can see that we will need discovery of capabilities (because all nodes will not have all capabilities) and associated semantics. 

h) As it was mentioned in an earlier e-mail, Jabber, in some sense has a P2P SIP substrate. By the time we finish, we might resemble XMPP more than one ways (I am not an expert, am open to be enlightened here)

i) The choke of Chord seems a little arbitrary. Most probably the writers have done lots of background work, but it is not obvious from the documents. I think we need to first make sure we separate any DHT mechanism and then standardize the interfaces, protocols and the mechanics. Pluggable P2P is a good way to go.

j) Having said that Chord might be a good choice to start with, we really cannot be in the abstract-land forever !

k) First I thought the "approach to SIP registration .." only supports Chord, then I saw the dht-param. While I am at it, the document needs more thought in many areas including the concept of overlays (for example would we allow multiple overlays, are they hierarchical, why, or would we say a node can participate only in one overlay except for gateway nodes?), trust model, anonymity primitives and bandwidth shaping.

l) Back to the main feature, IMHO we should develop a P2P framework for a set of well bound, pragmatic, very relevant scenarios, and then have another document that implements the framework using Chord. The framework has to be very robust - our challenge would not be the protocol or message format, but the security, anonymity and related mechanics. 

m) I do think P2P *is* mature enough to be the work of IETF standardization, not all of it, but enough to solve some of the current problems. Especially if we base our work from experience in implementing P2P SIP. For example Section 15 of the "P2P approach ..." says there are several different implementations. Let us abstract what worked and what didn't.

n) We also should choose 2 or 3 P2P mechanisms and implement them to validate the potential framework.

Let me stop before I run out of alphabets for outline ...

Cheers & thanks for the patience to read this thru

<k/>
-----------------------------------------------------------------------------
       |            |        Krishna Sankar, Distinguished Engineer
      :|:          :|:          
     :|||:        :|||:      - Disruptive Technologies & Architectures
 ..:|||||||:.....:|||||||:.. - Security, Mobility & Integration
     Cisco  Systems Inc      - Mobile-Asymmetric-Composable-Embedded Networks
     (Ph) 408-853-8475       ksankar at cisco.com
-----------------------------------------------------------------------------
"Not all those who wander are lost ..." -J.R.R.Tolkien
-----------------------------------------------------------------------------

________________________________

	From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mike Robinson
	Sent: Monday, March 27, 2006 4:14 PM
	To: Roy, Radhika R.; p2p-sip at cs.columbia.edu
	Subject: Re: [p2p-sip] Some comments on Use-cases document

	Radhika:
	
	You agree that there are many problems  that are not resolved yet, and no solution is  available. That means more research needs to be done. Research belongs in the labs, Universities or in IRTF. 
	
	It is not clear how you can change a DHT and still be compatible since SIP messages and headers fields are so much dependent on the type of underlying DHT used. The data maintained by each DHT is different and so are node insertion and removal procedures. I believe the security issues of each DHT types would also be different, so when someone says that they can replace DHT later on, they are just being too simplistic.
	
	Do you really want to create OSPF versus IS-IS kind of two incompatible solutions?
	
	--mike

	"Roy, Radhika R." <RADHIKA.R.ROY at saic.com> wrote: 

		I agree with David.
				It is also NOT harm to link! age a particular design with a particular DHT, if this is the good choice for a given time. However, other proposals are also welcome. It is an open to all of us.
				Standardizations are always done throughout the world if there is a consensus to go for something that is good. With respect P2P-SIP, there are a lot of things to be solved. However, if something provides immediate value, as David and many others of this list have opined, what is the problem for standardization? A better standard in the future can always supersede an inferior standard of the past.
				Best regards,
		Radhika
				________________________________

				From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
		Sent: Monday, March 27, 2006 2:40 PM
		To: 'Mike Robinson'; henry at pulver.com; 'Karst Bjorgson'; 'Kyara Yamamoto'; 'Peter Pan'
		Cc: p2p-sip at cs.columbia.edu
		Subject: Re: [p2p-sip] Some comments on Use-cases document
				I guess one view is the IETF should forever be relegated to the j! anitorial role of cleaning up after the party???s over.  But I believe the IETF can participate in and even promote the party through standardization.  I???d like the IETF to do more than simply formalize de facto standards, but actually create the standards that attract the party.  
				In the case of P2P-SIP, I entirely agree there are multiple, valid, proven ways to solve each of these problems ??? none of which is the clear victor.  And I also agree there are outstanding issues that have no proven solutions.
				If we pick amongst the best practices today, and skip the problems to which we have no clear solution, I personally believe that???ll give us the most immediate value, while paving the road for future improvements. I don???t believe we???ll ever meet any higher standard to get started than has already been met. 
				-david 
				________________________________

				From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mike Robinson
		Sent: Monday, March 27, 2006 10:32 AM
		To: henry at pulver.com; 'Karst Bjorgson'; 'Kyara Yamamoto'; 'Peter Pan'
		Cc: p2p-sip at cs.columbia.edu
		Subject: Re: [p2p-sip] Some comments on Use-cases document
						Henry:
				Do I need to tell that 48! 00 P2P google references have nothing to do with P2P SIP?
				Please let us not obfuscate the issues. You know, as well as, anyone sincere about the value of standards, that the pre-mature standardization leads to bad design as well as failure of the standards. As I mentioned there is no compelling use case presented yet that says we need to "standardize" p2p sip now without even bothering to get output from P2P IRTF group which is looking into core issues of P2P research.  
				Many would say that we first need an IETF standard for P2P file sharing before we want to use "P2P" to design P2P SIP. We need more research on P2P SIP before we standardize any particular "conspiracy" (I use conspiracy in the sense of Karst definition of linking design with a particular DHT)
				-mike
		V! OIP and SIP Trainer and Consultant
				
		Henry Sinnreich <henry at pulver.com> wrote:

			Mike Robinson writes:
						>How many research ! or analytical papers have been published in this area? 
			I have found by Googling a reference listing 4,800 papers on P2P. Hopefully, this enough to get us started. J
			Henry

		rates.

	________________________________

	Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1?/min. <http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://beta.messenger.yahoo.com>

---

From: edpimentl at gmail.com (Edpimentl)
Date: Mon, 27 Mar 2006 22:02:16 -0500

Hello Et Al,

I do agree with Mike R. views, however it comes a time, when perfect is
not good enough.

Think about what would have happen if we waited for a blazing dual core
Intel processor instead of the 4bit zilog to go to the moon.

As Henry S. pointed out, today we have over 4k different papers/docs on P2P

As I understand a number of individuals/groups are beginning to
experiment with http://overlayweaver.sourceforge.net/
since it supports Chord, Kademlia, Pastry, Tapestry and OpenDHT

Net net, the pragmatic approach would be to agree on a framework that
would allow the introduction of  better P2P SIP infrastructure.

Respectfully,
Ed Pimentel

Mail:   edpimentl[at]gmail[dot]com
Web:    http://agileco.net
WebLog: http://edpimentel.com  
IM:     [AOL | Jabber | Yahoo | MSN ] edpimentl
Voip:   [SKype | AgileSIP | GoogleTalk | FWD(14272) ] edpimentl

http://GooGaYa.com (Multimodal Messaging, Presence, LBS, Social Network
and Context Aware Services)
http://ViaSIP.com

Krishna Sankar (ksankar) wrote:

>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>  
>

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 28 Mar 2006 11:13:12 +0200

Some comments about some thoughts:

> b) First we need to bound the trajectory and locus of P2P SIP

I really appreciate the proposed roadmap (8/06->usecases,
1/07->architecture, 7/07->proto); it allows a pretty pipeline and is
likely achievable.  Which issues do you feel have not been properly
addressed?

> d) Then we also need to see what feature set we need - like anonymity
> (for example leveraging primitives from tor) and traffic shaping (for
> resource constraint devices - may be need to look at sensor networks)

The main architectural idea is to allow different feature sets for
different networks.  Actually the requirements in different environments
are unlikely the same and, in many cases, need centralization (e.g. C/S
SIP) for being satisfied.  So far, the main consensus is on defining an
architecture focused on interconnection between possibly different P2P
and C/S islands; and obviously the interconnection must be the one
already defined for traditional SIP (RFC 3263).

> Are we any way connected with domains like Ad-Hoc networks ?

Sure!  It would be great to set up instantaneus gaming sessions without
needing access points and stuff like that.. and eventually I will be
able to join "Quake Parties" during my long airport waits ;-)

> h) As it was mentioned in an earlier e-mail, Jabber, in some sense has a
> P2P SIP substrate. By the time we finish, we might resemble XMPP more
> than one ways

Jabber has servers and clients strictly separated; it is as P2P as email
is.  OTOH SIP has enpoints assembling UACs and UASs and that's why it
could be considered /almost/ P2P.

> I think we need to first make sure we separate any DHT mechanism and
> then standardize the interfaces, protocols and the mechanics. Pluggable
> P2P is a good way to go.

This option as the remaining items on your mail hit the consensus of the
most part of the group.

Enrico

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

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060328/231805a6/attachment-0001.html