[p2p-sip] P2PSIP, Kademlia and caching

[henry at pulver.com (Henry Sinnreich)]

The DHT layer can be (1) inside the SIP Peer UAs as suggested by Eunsoo
Shim:

http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt

See Fig. 2

...or (2) just to start, one can use openDHT as an emerging _DHT service_.

I guess we need to evaluate the criteria what to use in the DHT layer. 
SIP in the DHT layer is wrong IMHO. This is explained in:

http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt  

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: Friday, May 26, 2006 10:51 AM
To: henry at pulver.com
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

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