Subject: [p2p-sip] P2PSIP, Kademlia and caching

From: henry at pulver.com (Henry Sinnreich)
Date: Fri, 26 May 2006 15:19:16 -0500

>If we don't define at least one common dht, how can devices interop?

Worst case would be using the DNS domain via gateway supernodes.

Best case is if the proposed WG selects a DHT and/or uses some emerging
public DHT service.

Henry

-----Original Message-----
From: David A. Bryan [mailto:dbryan at sipeerior.com] 
Sent: Friday, May 26, 2006 2:31 PM
To: Alan Johnston; p2p-sip-bounces at cs.columbia.edu; David Bryan
Cc: p2p-sip at cs.columbia.edu; henry at pulver.com
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

My big worry there is interoperability. If we don't define at least one
common dht, how can devices interop? I definitely agree that we should allow
many, but I think we must specify at least one.
[Sent from my mobile device]

-----Original Message-----
From: Alan Johnston <alan at sipstation.com>
Date: Fri, 26 May 2006 12:32:51 
To:"David A. Bryan" <bryan at ethernot.org>
Cc:p2p-sip at cs.columbia.edu, henry at pulver.com
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

David,

Your reply seems to suggest that you think a single DHT will solve all 
these use cases.

I believe that concentrating on a single DHT or other P2P technology is 
not a good idea.  Also, I'm a little uncomfortable signing this group up 
to designing or implementing a specific DHT algorithm.

Instead, I think this IETF group should concentrate on defining 
protocols on the wire.  I'm still putting my thoughts together and will 
detail them in a draft soon, but rather than standardizing a particular 
DHT, we need to define an RFC 3263-like document that describes how SIP 
UAs can utilize a P2P Location Service.  This would include a protocol 
for how things like Contact URIs, certificates, presence data, etc. can 
be pushed and retrieved from a DHT.

With a standard protocol defined for this interaction, any DHT 
implementation or technology could implement this interface and be 
usable for P2P SIP. 

We would also need to define some discovery mechanisms, as well.

Perhaps with a clear scope like this in our charter we could get our 
working group going.  Once this basic work is complete, we can start 
discussing the merits of one DHT vs. another, and also perhaps 
architectures, although P2P SIP architectures might be better done 
somewhere like the SIP Forum.

Look for a more detailed proposal to come...

Thanks,
Alan

David A. Bryan wrote:

>Hi Henry,
>
>So obviously everyone here knows I've got a bit different approach,
>and there are a few things about an OpenDHT approach I don't
>understand.
>
>I think that my biggest concern is that using OpenDHT, I can only see
>how to address some of the use cases proposed. In the use cases draft,
>I can't see how an OpenDHT approach could solve the scenarios in 3.2,
>3.3 or 3.4, only how to use it to solve 3.1
>
>I also don't see what it is this group would standardize if we use
>OpenDHT. I don't think this WG is the right place to standardize
>OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general P2P
>working group. My idea for this group is to build a specialized,
>limited to SIP, light weight P2P mechanism, so that we can have many
>interoperable UAs from different vendors/open source development
>teams, all locating resources using P2P mechanisms, and not dependent
>on external agents for that resolution (only the UAs themselves,
>possibly not connected to the big-I Internet). In other words, we
>specify an alternate location protocol for SIP between the devices
>themselves.
>
>Am I just confused about OpenDHT?
>
>David
>
>On 5/26/06, Henry Sinnreich <henry at pulver.com> wrote:
>  
>
>>Maybe we should all talk using the same reference material, such as:
>>
>>http://opendht.org/pubs.html
>>
>>and then we can discuss the issues item by item, such as routing modes,
>>response time, delay aware routing, partial search, etc.
>>
>>Last but not least open running code and experimental results. Clearly SIP
>>has not been designed to address these issues and there is no reason to
>>duplicate all this work.
>>
>>Any opinions on the technology at http://opendht.org/pubs.html ?
>>
>>Publications Related to OpenDHT
>>
>>Distributed Segment Tree: Support of Range Query and Cover Query over DHT.
>>Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th
International
>>Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006.
>>
>>Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea,
>>Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX
>>WORLDS 2005, December 2005.
>>
>>Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik
>>Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS
>>2005, December 2005.
>>
>>OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey,
>>Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica,
>>and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005.
>>
>>A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram
>>Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph
>>Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005.
>>
>>Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp,
>>Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd
>>International Workshop on Peer-to-Peer Systems (IPTPS 2004),
Springer-Verlag
>>Lecture Notes in Computer Science Hot Topics Series, San Diego, CA,
>>February, 2004. (The OpenDHT project was originally titled "OpenHash".)
>>
>>Thanks, Henry
>>
>>
>>
>>-----Original Message-----
>>From: p2p-sip-bounces at cs.columbia.edu
>>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
>>Sent: Thursday, May 25, 2006 8:30 PM
>>To: Brian Rosen
>>Cc: p2p-sip at cs.columbia.edu
>>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching
>>
>>A bit more clarification.
>>
>>P2P over SIP means: "build a distributed lookup that SIP agents use to
>>locate each other, and use SIP messages to convey the
>>queries/organization for the distributed seach". The group would
>>standardize the extensions to SIP to do this.
>>
>>P2P for SIP means: "build a distributed lookup that SIP agents use to
>>locate each other, but it may use other message formats (I've heard
>>SOAP proposed) to convey the queries/organization for the distributed
>>search" The group would standardize that other protocol
>>
>>In both cases, the idea is regular SIP is used between the nodes. As
>>Greg points out, some (including my early work) proposed routing SIP
>>over the P2P layer as well. I backed off this a bit when many folks
>>objected in Vancouver, although I must admit that for NAT traversal
>>reasons, I'm liking it again.
>>
>>This is list of several hundred people. People have proposed building
>>a generic multi-purpose DHT using SIP here, and people have proposed
>>replacing SIP here. It has seemed quite clear from the responses that
>>the majority of people do not agree with that, and that certainly
>>those of us trying to organize P2PSIP do not support those things.
>>
>>--David
>>
>>
>>On 5/25/06, Brian Rosen <br at brianrosen.net> wrote:
>>    
>>
>>>I'm sorry, I don't get it.
>>>
>>>No one is proposing to use sip to do something equivalent to what a DHT
>>>does.
>>>
>>>Everyone is proposing to use sip messages to control session
>>>      
>>>
>>establishment.
>>    
>>
>>>A User Agent is going to send a pretty normal looking INVITE message.
The
>>>question at hand is how it routes it.  It doesn't use the procedures in
>>>3261.
>>>
>>>I don't understand the difference.  I think that means I don't understand
>>>what p2p using sip means.  As long as we are all agreeing that its sip
>>>messages to do session management, at least I think we're in a do-able
>>>situation.
>>>
>>>Brian
>>>
>>>-----Original Message-----
>>>From: Greg Daley [mailto:gregd at research.panasonic.com]
>>>Sent: Thursday, May 25, 2006 4:59 PM
>>>To: Brian Rosen
>>>Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu
>>>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching
>>>
>>>Hi Brian,
>>>
>>>There's a distinction between P2P FOR sip and
>>>P2P USING sip.
>>>
>>>P2P FOR sip is a system which handles distributed
>>>lookup of SIP location URIs,
>>>
>>>P2P USING sip is a realization of how to do P2P FOR sip,
>>>using SIP protocol (or SIP protocol-like) messages or
>>>extensions.
>>>
>>>There's broad agreement that we want P2P FOR sip
>>>(the goal), but not necessarily agreement that
>>>we need P2P USING sip.
>>>
>>>This is not surprising, because the charter discussion
>>>is about what we want to get done (P2P FOR sip),
>>>rather than on exactly how to do it (e.g. P2P USING sip).
>>>
>>>Clear now?
>>>
>>>
>>>Brian Rosen wrote:
>>>      
>>>
>>>>Okay, so here we are again.  You are looking for an approved charter,
>>>>        
>>>>
>>and
>>    
>>
>>>we
>>>      
>>>
>>>>don't know what we are trying to do.
>>>>
>>>>If there is consensus that this is to be a p2psip thing, then that's a
>>>>        
>>>>
>>>whole
>>>      
>>>
>>>>lot less work then if the sip part is still under discussion.
>>>>
>>>>I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF
>>>>land.
>>>>
>>>>So, what is it?  p2psip or
>>>>p2p-some-kind-of-multimedi-session-control-protocol?
>>>>
>>>><hint - check the name of the mailing list>
>>>>
>>>>Brian
>>>>
>>>>-----Original Message-----
>>>>From: p2p-sip-bounces at cs.columbia.edu
>>>>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley
>>>>Sent: Thursday, May 25, 2006 4:42 PM
>>>>To: Mike Robinson
>>>>Cc: p2p-sip at cs.columbia.edu
>>>>Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching
>>>>
>>>>Hi Mike,
>>>>
>>>>Mike Robinson wrote:
>>>>[cut]
>>>>        
>>>>
>>>>>Unless someone can tell us clearly why sip should be used to create,
>>>>>manage and re-configure DHT, the goal should remain a "proposed goal"
>>>>>till then. IETF, or for that matter any standard organization should't
>>>>>be a willing tool to fulfil any particular company's vested interests
>>>>>(even when supposedly supported by  (a company  funded) researchers at
>>>>>          
>>>>>
>>a
>>    
>>
>>>>>University).
>>>>>          
>>>>>
>>>>Only one of the (strawman) proposals says that SIP messages are used.
>>>>Alternative view on this have also been presented in the Ad-hoc sessions
>>>>leading up to the BoFs (and are still on the table).
>>>>
>>>>There's no clear winner, there's not even a coalition of people who
>>>>have backed one.
>>>>
>>>>Of course authors will each have points to make about their own ideas,
>>>>but that's why there's got to be a working group.  So the community
>>>>can work on the requirements and make sure that the best solution is
>>>>used.
>>>>
>>>>If we didn't care about that, we'd just use/sell a proprietary system.
>>>>
>>>>        
>>>>
>>>>>I am not opposed to p2p sip in whatever form - but don't understand the
>>>>>urgency being shown to push a certain design without evaluating
>>>>>alternative approaches. You don't  need standardization right away to
>>>>>show that your model works- post your code to sourceforge.net and let
>>>>>          
>>>>>
>>me
>>    
>>
>>>>>see how good your design is by experimenting with it.
>>>>>          
>>>>>
>>>>I think you've misread the situation.  There is code for at least
>>>>one implementation of a proposal available (is it on sourceforge?).
>>>>
>>>>AFAIK, there's no-one here pushing a particular cart.
>>>>
>>>>People here have a real desire to bring about the best system
>>>>for p2p sip.   There are people here willing to do the work
>>>>on assessing the protocol requirements, reviewing documents,
>>>>designing and building a protocol, following the IETF's
>>>>procedures.
>>>>
>>>>If we just wanted to get something out commercially and push a
>>>>particular agenda, we'd have made an industry consortium.
>>>>
>>>>It's a lot faster, it has more chance of success, and has less
>>>>inconvenient review.
>>>>
>>>>Help us to charter the WG, because that's where the IETF can
>>>>have control of the outputs, and ensure protocol quality.
>>>>
>>>>Greg
>>>>_______________________________________________
>>>>p2p-sip mailing list
>>>>p2p-sip at cs.columbia.edu
>>>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>p2p-sip mailing list
>>>p2p-sip at cs.columbia.edu
>>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>>
>>>      
>>>
>>_______________________________________________
>>p2p-sip mailing list
>>p2p-sip at cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>
>>_______________________________________________
>>p2p-sip mailing list
>>p2p-sip at cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>>
>>    
>>
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
>  
>

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

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Fri, 26 May 2006 17:28:34 -0400

I also think the best case is that the proposed WG selects a DHT.
What I hear these days is that most well-known DHTs adopted good
features of each other and now experts say there is not much difference
among them in terms of features or performances.

Certainly we don't have to review and compare all kinds of DHTs and
select the very best one. We can adopt a new one later. I believe there
is a consensus about that.
So far what have been proposed on the list are Bamboo/Pastry, Kademlia,
and Chord. Selecting one of three may not be as difficult as selecting a
DHT sounds from scratch.

Thanks.

Eunsoo

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Fri, 26 May 2006 20:02:24 -0700 (PDT)

>> Selecting one of three may not be as difficult as selecting a
>> DHT sounds from scratch.

Not sure what is the criteria you based above assertion on?  Either something is difficult to get consensus on,  or it is resolved, there are no in between status in standards. Given the mails on the topic on this list or otherwise, I don't see how study of DHTs fits in p2p sip charter.  
 
o Mike

Eunsoo Shim <eunsoo at research.panasonic.com> wrote: I also think the best case is that the proposed WG selects a DHT.
What I hear these days is that most well-known DHTs adopted good
features of each other and now experts say there is not much difference
among them in terms of features or performances.

Thanks.

Eunsoo

Henry Sinnreich wrote:
> From: Alan Johnston 
> To:"David A. Bryan" 

>> On 5/26/06, Henry Sinnreich  wrote:
>>  
>>
>>> On 5/25/06, Brian Rosen 

---------------------------------
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/20060526/b4d2256d/attachment-0001.html