Subject: [p2p-sip] Some comments on Use-cases document

From: kyara543 at yahoo.com (Kyara Yamamoto)
Date: Tue, 21 Mar 2006 18:08:20 -0800 (PST)

Peter:

>From http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-02.html Chord is official overlay of P2P SIP. 

Forget about KAD and your solution here, as long as Bush insists staying in Iraq.

--Yamamoto
> On Mar 21, 2006, at 3:20 PM, Peter Pan wrote:
> 
> >> The exact DHT algorithm we implement, the exact way the we use SIP,
> >> the methods, etc I think are all going to need some careful thought.
> >> But for P2P SIP, I think SIP is the obvious choice for DHT  
> >> operations,
> >> and I would consider it the default unless a convincing argument is
> >> made against it.
> >
> > Not an argument but a question: how to efficiently implement Kademlia
> > STORE_VALUE primitive in SIP INVITE/REGISTER when the stored values  
> > can be
> > of any length and type?
> 
> 
> By bounding the P2PSIP store-value primitive as a vector of  
> distinguished name and contact URI.
> 
> It's not a question of what Kademlia can express, it's a question of  
> what P2PSIP requires.
> 
> --
> Dean

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060321/ca483d44/attachment.html

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Tue, 21 Mar 2006 22:43:29 -0800 (PST)

--- Kyara Yamamoto <kyara543 at yahoo.com> wrote:

> >From
http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-02.html
> Chord is official overlay of P2P SIP. 
> 

A DHT is essentially a set of nodes that conspire to
resolve names. There are multiple ways to build such
conspiracies -- Kamdelia, Chord, Microsoft's PNRP,
even dynamic DNS. We can be pretty usre that some of
the existing ways will be proven broken in the future,
and that new algorithms will be found. Linking P2P SIP
to is specific conspiracy does not appear very wise.
Can't we build a level of indirection? For example, is
it possible to somehow identify the specific DHT
inside the P2P SIP URL?

-- Karst

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 22 Mar 2006 07:37:06 -0500

No decision has been made as far as I know.
I think we need to select a DHT algorithm (the first one we will use)
sooner or later.
What have been discussed (and roughly agreed, I believe) was that we
should not spend too much effort to compare all kinds of DHTs to pick
the very best one. A number of people believe that DHT algorithms have
pros and cons and thus it would be hard to say which is the best.
Probably we could have a brief comparison among well-known DHT
algorithms and pick one as our starting point. We may find a better one
later and thus the architecture and protocol should be modular enough to
allow easy change of the DHT algorithm.

Certainly Chord is one of the primary candidates. But I understand there
are some other proposals, too.
Thanks.

Eunsoo

Kyara Yamamoto wrote:

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

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Wed, 22 Mar 2006 08:16:04 -0800 (PST)

Karst,

Could you please elaborate on why do you say " Linking P2P SIP
to a particular DHT is specific conspiracy does not appear very wise.".
What is wrong with Chord that is being suggested?

--mike
-------------------
Mike Robinson
VoIP Trainer and Consultant

Karst Bjorgson <karstbj at yahoo.com> wrote: 

-- Karst

		
---------------------------------
 Yahoo! Mail
 Use Photomail to share photos without annoying attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060322/3498e0a9/attachment.html

---

From: kyara543 at yahoo.com (Kyara Yamamoto)
Date: Wed, 22 Mar 2006 17:09:12 -0800 (PST)

>     > It's not a question of what Kademlia can express, it's a
Using an *indirect* vector of contact URIs and another protocol (MSRP) to store/retrieve a resource sounds like taking pants off to fart. It takes extra NAT penetration efforts (risk) for the second protocol to *reach* the URIs.

If David's *5x overhead* theory on multiple P2P-SIP ports is valid, a protocol suite with *2x less efficiency* and "2xx more complexity" is far from encouraging. 

"Ask all the SIP community what a pain this can be."

--Yamamoto

---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060322/2c23468e/attachment.html

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Fri, 24 Mar 2006 23:04:31 -0800 (PST)

> to a particular DHT is specific conspiracy does not

Most of the DHT technologies are still at the research
level. We can expect significant progress in security,
handling of locality, amount of management overhead,
etc. Ths, we may well expect that a DHT implementation
that looks attractive now will look terrible in say,
five years. This calls for a level of indirection.

I used the word "conspiracy" to denote the tight
coupling between notes expected in many DHT
technologies. The INSERT primitive, in most systems,
finds the node "closest" to the inserted index, and
asks that node to publish the value. In practice, this
requires a lot of trust: trust that a third party will
publish your data, just because the hash code of their
node-id is closest to the hash code of your name. That
kind of trust is easier to obtain in small groups than
in very large systems. Thus, even if we picked a
single DHT technology, we would still want a level of
indirection to indicate which particular DHT group
should be used.

> What is wrong with Chord that is being suggested?

I would rather be modest here -- Chord is a nice piece
of work, and I enjoyed reading their papers. I am
concerned mostly with two aspects: the possibility for
bad nodes to insert themselves at strategic point in
the "routing tables"; and the amount of overhead
required for table maintenance. That does not mean we
cannot use Chord, but I believe it would be a mistake
to not plan for technical evolution.

-- Karst

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Sun, 26 Mar 2006 12:35:37 -0800 (PST)

Hello Karst:

Thanks explaining your "consipracy" rationale.. 

After following the  discussion  in BOF and  in ad-hoc meetingin IETF, it appears that certain people are more interested in pushing their personal agendas of p2p sip than caring for technical merits of this group. Now that I understand your point of view, and details a bit better, and it appears to me that p2p sip idea as being proposed  seems to have a real "conspiracy" behind it.

Why are are we trying to standadize some thing in hurry that is so ill-defined and is not yet ready for standardization?  How many research or analytical papers have been published in this area? Perhaps none! Several people, I talked to seem to favour sip over p2p rather than what is being proposed by the current crop of people that are pushing their solution with limited implementation experience. May it is some IPR thingy or something I don't understand well the politics of it. When a company and University work together, I usually become suspicious of their motivation.

Karst Bjorgson <karstbj at yahoo.com> wrote: > Could you please elaborate on why do you say "
> Linking P2P SIP

Hmm....
Looks like we haven't yet reached a stage where we can really
talk of  a particular DHT being standardized in a IETF protocol.

I see your point - it appears that technology needs more research
before it can be standardized. I believe there is an IRTF sub-group
researching into DHT implementations and other P2P area.  Formation
of this group should perhaps wait till some more input from IRTF is
available in this direction. Moreover, I didn't see a very compelling use
case that says the p2psip is needed right away. It does not do any thing that cannot be done with sip at least in the enterprise network
that I am familiar with.

I hope area director is reading this list.

Thanks for putting this information in a clear perspective.
I do agree with your assessment.

--mike
VOIP and SIP Trainer and Consultant

---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060326/d334ccc8/attachment.html

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Sun, 26 Mar 2006 19:45:29 -0800 (PST)

> Why are are we trying to standadize some thing in
> hurry that is so ill-defined and is not yet ready
> for standardization?  How many research or
> analytical papers have been published in this area?
> Perhaps none! 

Well, it is easy to see the potential benefits of a
standardized P2P version of SIP. Power to the people,
end to end architecture, freedom to connect, and all
that sort of things. Definitely interesting, and a
worthy endeavour for the IETF. 

On the other hand, the current approach smells a lot
like "rushing to the solution before we actually
understand the problem". David Bryan's draft
(draft-bryan-sipping-p2p-02) is typical of that
approach: it describes in great detail how to
implement a DHT using SIP formats and algorithms
derived from CHORD, but this degree of detail can only
be useful if actually know what to optimize for. What
about security, privacy, resistance to DOS attacks,
management overhead, selection of supernodes? On there
are certainly a bunch of other problems...

-- Karst

---

From: bryan at ethernot.org (David A. Bryan)
Date: Sun, 26 Mar 2006 23:18:59 -0500

As has been pointed out before on this list (dozens of times), is
clearly stated in the draft, and I even asked EKR to say in his
presentation at the plenary -- the draft is a strawman. It is there to
prove such a solution is possible. In the earliest days of this
effort, it was not clear such a solution was possible, so we went and
built one, and created the draft to detail what we did. As we work on
our idea, we update the draft.

If you have alternate suggestions or would like to present solutions
to the list of problems you mention (or the even longer list of
problems we list in the draft itself, including the ones you mention),
please do! That is the purpose of the draft.

No one on this list -- most certainly not the authors -- have ever
claimed it is a complete solution, is ready to be deployed, or even
reflects what an IETF group is likely to adopt. Several people in this
thread have implied that is the case. It most certainly is not. It is
there as an example, and I think it is useful to update it as we go to
reflect one possible approach in enough detail to allow people to
possibly implement and play with the ideas.

I intend to continue to update it, but I expect many other
suggestions, alternate drafts, etc. from others in this list as well.
There have been suggestions from Eunsoo, Philip Matthews, Henning and
others from Columbia, and many others. Please feel free to suggest
something different. You can write an alternate draft, or if as you
say, you think that having drafts of protocols is too much detail,
please outline a suggestion in email what you think might be a better
approach, suggest comments for the requirements draft, suggest a new
architecture draft. There are many avenues for you to suggest
something.

Neither I nor any of my coauthors have said our draft is the only way
-- quite to opposite, we have changed to a design that separates
search from invite in response to suggestions in Vancouver.

If you have better ideas -- present them. Repeatedly complaining the
draft has flaws or claiming that there is a conspiracy against
proposed designs using other mechanisms that haven't even been
submitted yet is not helping advance the efforts of this group. Do you
have a suggestion for resistance to DOS attacks? Write it up! An idea
about selecting supernodes? Please suggest! We are very interested in
contributions. Please make them.

David Bryan

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Sun, 26 Mar 2006 21:46:20 -0800 (PST)

> Repeatedly complaining ... that there is a
> conspiracy against proposed designs...

To be clear: I used the word "conspiracy" to describe
the tight relation between nodes in a DHT, as in:
"nodes conspire to store and resolve hashes." I am
sorry that it somehow implied an alternate meaning. I
do not believe that there is inappropriate behavior
going on in the proposed working group.

-- Karst

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 27 Mar 2006 01:14:31 -0500

Indeed you did not use that term, sorry to imply you did.

The reply was in general to several messages in this thread, and that
particular comment was in response to the concern Mike expressed (and
Kyara seemed to imply earlier) that there was a specific effort  to
exclude ideas besides Chord over SIP. There is not. Do I believe that
approach has merits? Certainly, otherwise I would not have spent time
writing the draft. I currently think it is a very good approach, and
will continue to advocate it as long as I believe it is. I can
certainly be convinced something else is better. Many others on the
list have proposed other mechanisms, and I expect even more.

Nothing at all has been decided, and none of the drafts currently
proposed are polished or enjoy consensus from the (non-existent as
yet) WG. It is very early. All ideas are on the table, and I think I
speak for everyone in saying we have many open problems.

The only things that are off the table are things that simply won't
fly for a group called P2PSIP at the IETF -- things like tunneling
messages over port 80 or fundamentally redesigning SIP simply won't be
allowed in IETF and are out of scope. That is the only constraint
right now.

--David Bryan

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Mon, 27 Mar 2006 07:23:01 -0800 (PST)

Hello David:
 
 Let me be very clear that I have nothing against your draft and I am aware that you have been putting great efforts in developing a version based on p2p sip. As a matter of fact, I applaud *your* efforts in maintaining p2p sip site, but do not necessarily agree, as others have pointed out too, that the technology is at a stage where standardization is not possible or a wise choice yet.  Karst has given many specific issues that range security, node insertion, dynamics of DHT maintenance etc. As a research project - please go ahead and publish your papers, your results, your code, let some of us try it and see if it is really worth standardization, or where we need improvements. SIP took over 10 years to be where it is today and still sip and sipping group is dealing with many many new drafts addressing a lot of new issues or problems. So, is p2p sip in a shape where a standards body should bless it?  Where are the data points to support one choice over others? My opinion is!
  that if
 p2p file transfer applications can survive without standardization for some time and flourish, p2p sip can too. 
 
 My comments were more directed at some presentations that I saw which neither had any specific ideas, but still trying to push p2p sip standardization, and seems to be in more hurry than you. I am just intrigued why would some people familiar with sipping and sip WG work load would be so interested without having any new specific ideas to address these issues to create a new WG? What is that they are looking for in return? I am not saying that there is any thing inappropriate going on, but I am still curious why so much of hurry.
 
 The question that area director and others need to answer - Is a hurriedly crafted standard that may cause a lot of issues later on is better than no standard at all? That is all, folks. 
 
 I need to finish some installation today so may not see my response immediately.
 
 --mike

"David A. Bryan" <bryan at ethernot.org> wrote: Indeed you did not use that term, sorry to imply you did.

--David Bryan

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

---

From: henry at pulver.com (Henry Sinnreich)
Date: Mon, 27 Mar 2006 10:17:48 -0600

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

Henry

  _____  

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mike Robinson
Sent: Sunday, March 26, 2006 2:36 PM
To: Karst Bjorgson; Kyara Yamamoto; Peter Pan
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Some comments on Use-cases document

Hello Karst:

After following the  discussion  in BOF and  in ad-hoc meetingin IETF, it
appears that certain people are more interested in pushing their personal
agendas of p2p sip than caring for technical merits of this group. Now that
I understand your point of view, and details a bit better, and it appears to
me that p2p sip idea as being proposed  seems to have a real "conspiracy"
behind it.

Why are are we trying to standadize some thing in hurry that is so
ill-defined and is not yet ready for standardization?  How many research !
or analytical papers have been published in this area? Perhaps none! Several
people, I talked to seem to favour sip over p2p rather than what is being
proposed by the current crop of people that are pushing their solution with
limited implementation experience. May it is some IPR thingy or something I
don't understand well the politics of it. When a company and University work
together, I usually become suspicious of their motivation.

Hmm....

kind of trust is easier to obtain! in small groups than

I see your point - it appears that technology needs more research
before it can be standardized. I believe there is an IRTF sub-group
researching into DHT implementations and other P2P area.  Formation
of this group should perhaps wait till some more input from IRTF is
available in this direction. Moreover, I didn't see a very compelling use
case that says the p2psip is needed right away. It does not do any thing
that cannot be done with sip at least in the enterprise network
that I am familiar with.

> What is wrong with Chord that is being suggested?

I would rather b! e modest here -- Chord is a nice piece

--mike

  _____  

New Yahoo!
<http://us.rd.yahoo.com/mail_us/taglines/postman4/*http:/us.rd.yahoo.com/evt
=39666/*http:/beta.messenger.yahoo.com%20>  Messenger with Voice. Call
regular phones from your PC for low, low rates.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060327/234981fa/attachment.html

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Mon, 27 Mar 2006 10:17:00 -0800 (PST)

Oops!
   
   - the second sentence should have read:
   
  As a matter of fact, I applaud *your* efforts in maintaining p2p sip site, but do not necessarily agree, as others have pointed out too, that the technology is at a stage where standardization is possible or a wise choice yet.

  (there was an extra "not" inserted in the half sleepy state)
  
Mike Robinson <mike_robnson at yahoo.com> wrote:
  Hello David:

Let me be very clear that I have nothing against your draft and I am aware that you have been putting great efforts in developing a version based on p2p sip. As a matter of fact, I applaud *your* efforts in maintaining p2p sip site, but do not necessarily agree, as others have pointed out too, that the technology is at a stage where standardization is not possible or a wise choice yet.  Karst has given many specific issues that range security, node insertion, dynamics of DHT maintenance etc. As a research project - please go ahead and publish your papers, your results, your code, let some of us try it and see if it is really worth standardization, or where we need improvements. SIP took over 10 years to be where it is today and still sip and sipping group is dealing with many many new drafts addressing a lot of new issues or problems. So, is p2p sip in a shape where a standards body should bless it?  Where are the data points to support one choice over others? My opinion is !
 that if
 p2p file transfer applications can survive without standardization for some time and flourish, p2p sip can too. 

--mike

--David Bryan

---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060327/00aa6c23/attachment.html