Minutes of P2P Ad-Hoc Meeting

Reported by Dean Willis

SIP P2P Ad-Hoc
Thursday March 10, 2005 2200-2400
Notes recorded by Dean Willis

Topic: Overview
lead by Cullen Jennings
Slides presented

Discussion:

Hannes T:  One approach is using distributed hash tables at the edge, sort of based on proxy servers. This seems fairly simple. Another design decision involves replicating the P2P protocol using SIP.  However, architecture assumptions change. ECRIT and others make assumptions about how things are related, and the sort of changes that come from P2P change these. Hannes has started writing these down with Joerg Ott, but it is hard and there are many things to care about.

Henning: Existing systems don't solve hard identity problem in a decentralized way (like Skype) and they don't play nice with others. They don't deal well with multiple P2P systems with other namespaces. It may be of interest to look at how P2P architectures can play nice with traditional SIP. It would be important to change the protocols as little as possible to make this happen.

Richard S; What are we trying to do here? Set up a proxy system that can connect to the global system? This would seem to need to be centralized, and the only "fair" centralized system is DNS.

Henry S: When you mentioned no centralized server, I presume that you don't exclude clouds of servers as long as they are self organizing.

Cullen: My slides actually talk about multiple "rings".

David: Must consider what we mean when we say "server" -- sometimes clients and servers are the same thing.

Henry: Servers have long-lived IP addresses and are stable.

Willie: Some nodes might function as server-peers and others might function as user peers.

Mathews:  Limited environments like PBX systems may success using existing external relationships. This doesn't scale into larger environments -- we need to answer "Why are people doing this?" This isn't clear to me . . .

AG:  Clients should talk to both worlds.

Richard S: About identity . . . if we separate the establishment of communications from identity, we can use the communication channel to establish identity. Checking is an end-user issue.

Willie: Do end points ask an independent third party to validate identity?

Cullen: Some systems use intermittent connection to central authority to cache this sort of thing.

Hannes T: Zeroconf stuff is attractive.

RjS: Want to reinforce that users don't care about arch. They just want it to work. Want to study a p2p-like approach. Can we design a global-scale system that doesn't have the property of being messable-up by a stupid service provider/operator?

Ben C: Thing about large deployments is it is expensive to build large server farms. That's a lot of hardware, even for simple things. granularity is even more difficult because service providers like big instead of little boxes.

Cullen: There are p2p networks that are storing a lot more than 6 billion blocks, so there is some hope they could scale.

Dean: P2P is usually deployed in opposition to service provider business interests. That;'s why SIP has so many proxies -- operators trying to recoup money from transport networks.

Hannes T; We need to consider end-host mobility.

Henning: The number of supernodes tends to be relative small compared to the number of users.  There is a inverse-log relationship to search depth. Most of these deployments assume relatively stable nodes, and high node mobility would tend to thrash the DHT mechanism.

Willie: Localization is a matter of address spaces.  Predict that traffic stays sort of local.

RichardS: What do we wish to achieve with a P2P network. In the PSTN, anybody can already call anybody. Isn't this P2P?

Mathews: How would these things be deployed?

RjS; Did not mean to mischaracterize that there would be a large collection of actual service providers. Don't care whether there are large or small networks. We need to tease apart what we are thinking of as service providers in this context -- things like identity and location. In each of these problems, as you look at them individually, you remove the ability of a single entity to disrupt even one of these small networks through configuration.

Cullen: It would be nice to be able to control which ring you join, be able to merge them without losing namespace, and switch between contacting through a ring or traditional approach. Might be nice if traditional systems could reach the "ring dwellers" .

Richard: A P2P network is distinguished by NOT having a service provider.

HenryS: in the extreme, you don't have a service provider -- just a software provider. The software provides its own service.

jdrosen: If we build p2p that can't connect to traditional nets, we might as well have invented a different protocol. It's important that they interconnect. The key is in the definition of identifying a namespace -- essentially, a reference to a bootstrap that provides entry to the namespace.  This raises questions about centralized naming providers.

henning: With one ring, naming is a local collision problem. They key to multiple rings is to allow them to evolve independently, but be able to connect to each other when they "bump". Two models: 1) a hierarchy of DHTs. 2) Ownership is around registration -- perhaps a domain gives you a ring. What is implied by interworking rings?

henry: Jonathan, do you think we should emulate the user@domain naming structure.

jdrosen: anything that KEEPS us from interworking would be an error.

Adam: A lot centers around whether nickname collisions is a tragedy or just something to let people disambiguate. Our world does NOT have unique names for every individual. As long as you can tell them apart (and certs do this) then we have enough.

JonP: Once upon a time there was newnet and its friends. They though ICANN was unjust. They thought that the solution would be many alternate roots, and a user could choose a root to honor. This didn't work.

jdrosen: We need to be able to take an identifier off a business card and find somebody with it.

Adam: This can be human disambiguated.

JonP: We have names that are not actually used to route in the system, and others that may be search strings. But note that if you go to the trouble of building a uniqueness function with hierarchy, it may be useful to route on it.

HannesT: The last two years in EAP have been spent on naming, and what you want to use a name for makes a big difference. 

EKR: The key thing here is that URNS are unique, and names  are not  uniquely resolvable as a search string.

Henning: We use standard SIP URIs. If a URI exists on the "regular:" network., we use that. If not,. the whole AOR gets hashed into a string, and that's the DHT index. The DHTs then export their namespaces via DNS.

jdrosen: In short, we are using DNS to find the entry point into a DHT.

Henning: We do nothing to assure uniqueness. If there are multiple hits, you might have to talk to them and figure it out. This works reasonably well.

jdrfosen: are we actually looking to build a system that doesn't have a centralized naming space?

Cullen: We have considered a broad range of arrangements from yes to no.

jdrosen:L What are next steps? I propose we focus not on mechanisms but on properties that people are interested in having. Essentially, we strive for requirements.

Jon Peterson: We should perhaps refer this to IRTF, not tackle it in SIPPING.

Gonzalo: The SIPPING plate is full.