Philip Matthews' Notes from IETF 65 P2P SIP BOF

P2PSIP Ad-Hoc

Wednesday March 23, 2006, 0900-1130
Dallas, Texas
Minutes recorded by Philip Matthews with additional notes from Avshalom Houri
Edited for format by Dean Willis.


Agenda and Introduction

Led by the Chairs

Slides Presented

There will be additional ad-hoc meeting on Friday afternoon, 12 - 2pm in the Cortez meeting room.

The purpose of the BOF is primarily to agree on a charter, and that the technical discussion will happen at the Friday ad-hoc. To that end, the BOF will start with two presentations ("use-cases" and requirements) that give a "birds-eye" view of what the work will entail, before getting down to the serious charter discussion.

Brief high-level overview:


Topic: Use Cases

Led By Bruce Lowekamp
Slides Presented

Draft talks about how P2PSIP could be used.

Some of these use-cases require P2P, while others could be P2P or Client-Server (CS).

Scenarios:

Question: Rohan Mahy - Can you provide an example of an open P2P network w/o central authorization? Bruce - Don't know any. Is it a requirement that we be able to do it? [After brief discussion, decided not to decide this question now].

Comment: Medhami (?) - These use-cases are not specific to P2P. If a use-case is solvable with Client-Server (CS) SIP, it should also be solvable with P2P. Key question is how to do this at low cost.

Comment: Rohan Mahy - Use-case for IP PBX. Server does not necessarily mean expensive. Don't have to be P2P to be cheap.

Comment: Greg Dermott - Accountants visiting the office of another company to do an audit often do not have access to local Internet infrastructure (except wireless). P2PSIP would be nice here.


Topic: P2P SIP Requirements

Led By Henning Schulzrinne
Slides Presented

A defining characteristic is that the resources of participants are shared to provide services (but may use some limited centralized resources)

WG participants come from different backgrounds and use different terminology. We need to work on this.

Suggested definition: DHT: a means of mapping an opaque string to an opaque value. There are no restrictions on strings (except, perhaps, for some basic ones like max length).

Basic goal: MUST support voice, video, interactive text. SHOULD support async messaging and presence.

Need to distribute resources: location service, NAT/Firewall traversal servers, voicemail servers, etc. Best if we can have a generic mechanism so other services can be added later.

Should have an architecture that can accommodate different DHT algorithms, as DHT design is still an area of active research.

Question: Cullen Jennings - Node using one DHT will not interoperate with a node using a different DHT. What interoperability do we want? Do we want to standardize the DHT algorithm? [There was some discussion on this point. Henning talked about standardizing the abstract interface to the DHT algorithm, and then standardizing perhaps one or two DHTs as an example of this interface. He talked about a service on Planet Lab that happens to use Bamboo, but provides an abstract interface so the details of the underlying DHT are not important. When asked the question "Is a DHT an essential part of P2P", the answer was "No, we can do P2PSIP without a DHT".]

NAT Traversal: SHOULD distribute NAT Traversal functions (e.g., STUN and TURN servers) to peers; SHOULD allow a peer to select a nearby server

Protocol SHOULD scale from small to large systems (see use-cases). MUST handle churn in peer membership.

Naming: SHOULD allow both centralized and non-centralized naming authorities.

System MUST work well when entire system rebooted. Not clear that existing systems can do this.

Some services may be centralized.

Security: Inherently different requirements and trust model. Well-known result: there is no solution if 2/3 of the peers are evil. P2P breaks fundamental assumptions. Analogy: hard to be secure when the web-server your browser is connecting to is operated by Mr. Evil. Different types of evil nodes: those that don't contribute resources, those that eavesdrop on communication, and those that actively disrupt.

Need to encrypt media and signaling end-to-end.

Comment: Rohan Mahy - Would be good to separate security into DOS attacks and other attacks.

May have to have probabilistic security models rather than black/white models: Rather than absolute protection against an attack, one can make the chance of having a successful attack of a certain kind smaller and smaller by doing more and more of a certain prevention scheme.

Open issues:

Question: Anwar Siddiqui - Should this support conferencing and bridging. Henning - Yes, inadvertent omission.

Question: ?? - What about regulatory issues? Henning - 911 calls should be covered by interop with CS systems. Lawful intercept is harder - basically cannot be done.

Comment: Dan Petrie - I assume we want heterogeneous systems (i.e., interoperability). Need tighter constraints on implementations. In other words, need stronger constraints on peers to get interoperability. Henning - Agree, but need a common interface. This is no different than what parts of DNS we are going to implement. Dan - For example, all peers need to implement forking consistently. Henning - Not speaking for my co-authors, a proxy must behave as in RFC 3261. Then the question is: can we agree on a minimum set of services. Dan - Agree, but 3261 is not sufficient.

Comment: Tim Chown - Must have IP version independence. Would like to see IPv4 and IPv6 interoperability as a requirement, and see it mentioned in the charter. Cullen Jennings - IPv4/IPv6 interop is a requirement. Henning - Agree.

Comment: Rohan Mahy - Would like a system where an ordinary CS node can send to P2P network. No requirement for overlay network, no requirement to use DHT.


Topic: Draft Charter

Led By Dean Willis
Slides Presented

We need to take a very large scope and squeeze it down into something small. This charter is an attempt to do this.

Proposed Purpose: Develop mechanisms for using SIP where establishing and managing sessions is either partially or entirely handled by endpoints.

Scenarios: (1) Self-organizing proxy farms; (2) topologies with ephemeral relationships (e.g. emergency response systems, etc); (3) recovery functions to allow peers to communicate when central server fails. [Comment from minute taker: The group has also discussed other scenarios not mentioned on Dean's slide. See, for example, the use-cases document and the previous presentation. It seems that the use-cases document and the charter need to be brought into sync.]

Comment: Eric Rescorla - "Self-organizing" can be either tactical or social. Tactical is more trustful.

Assumption 1: Need namespaces for resources (including users). May have format bob@example.com.

Question: Eric Rescorla - Must the RHS (= "right-hand side", i.e., the part after the "@" sign in the name) be a DNS name? Dean - If you are doing DNS, yes. Otherwise, no. Eric - So LHS is new and introduced by P2PSIP, while RHS is some existing system (e.g., DNS or equivalent).

Comment: Greg Daley - P2PSIP might not just be looking at LHS (= part before the "@" sign). P2PSIP MAY use and define entire name, not just LHS.

Comment: Bruce Lowecamp - Need to emphasis that we MAY use DNS. For example, a system where there is limited connectivity may not use DNS. Dean - Yes, but to talk between two P2PSIP systems, use standard SIP server lookup mechanisms.

Comment: Jonathan Rosenberg - P2PSIP must be maximally interoperable. Not a closed, Skype-like network. Want maximum interoperability with existing Client-Server (CS) SIP.

Comment: Aki Niemi - Nodes typically move around. Today may be connected to Internet, but tomorrow not. Want to use the same name. Dean - May be hard to do this. Aki - Are we saying my name must be different? Dean - I am saying that this interesting question, we must discuss.

Assumption 2: Use existing SIP functions for everything except locating resources.

Assumption 3: May bootstrap using DNS when we have it, but use something else when we don't.

Assumption 4: Interactions between different P2PSIP systems will use the model of RFC 3263 ("Locating SIP servers"). In other words, use standard CS SIP between P2PSIP systems.

Assumption 5: Authenticity of identity with vary by P2PSIP system. However, group will define at least one mechanism equivalent to the "SIP Identity Mechanism" RFC.

Tasks:

  1. Document usage scenarios where P2PSIP is appropriate.
  2. Develop general architecture for P2PSIP applications.
  3. Define distributed location mechanism for locating users. [Comment from the minute taker: Or more generally, a distributed mechanism for locating resources, as a number of people have suggested]
  4. If extensions to SIP are needed, define requirements to be acted on by other working groups.
  5. Select NAT/Firewall traversal technique. If extensions necessary, define requirements to be acted on by other working groups.

Comment: Rohan Mahy - Like these tasks. For task 3, could use zeroconf and have this be the location mechanism. Dean - Need to define a generic set of operations, and show at least one binding to one existing system. [General discussion on this point. Agreed that we wanted to define an abstract interface to the distributed lookup scheme, as well as at least one concrete implementation.]

Comment: Jonathan Rosenberg - In task 5, rather than select, should state that we will use the existing SIP NAT traversal scheme, unless this is not sufficient. Philip Matthews - Jonathan, there is already a statement in the charter that we will reuse existing protocols whenever possible. Does this make you happy? Jonathan - Would like something more explicit. [There was then a discussion of this point, and the chairs displayed on the overhead screen Jonathan's proposed text for task 5 which he had posted to the mailing list, which basically said "use ICE unless it doesn't work". There was some discussion of this text, and some alternative wordings were proposed.]

Comment: Michael Slavich - ICE is defined only for media. Need a solution for signaling.

Comment: Philip Matthews - I agree with Michael. ICE works fine for media, but we need some sort of ICE-like solution for signaling and the P2P overlay maintenance messages.

Comment: ?? - Like proposed new text. Don't want to spend 3 years doing NAT traversal again.

Comment: Tim Chown - Don't want to require NAT in IPv6 environment. What about IPv4/IPv6 interworking? Dean - Need to add to mission parameters slide.

Comment: Jonathan Rosenberg - For signaling, SIP outbound should work.

Comment: Anwar Siddiqui - Plug and play is very important here. Skype has set the standard, and we have to meet it.

Comment: Eric Rescorla - Let's talk about task 3. We need to choose an architecture.

Comment: Jonathan Rosenberg - I agree. Need an architecture. There are different P2PSIP architectures, and they can be very different. Tasks may change dramatically depending on the architecture chosen.

Comment: Henning Schutzrinne - We have broad agreement on certain models that we seem to want. One model is a abstract interface to some distributed mechanism for locating resources, another model is one or two specific implementations of this mechanism, the third model is a Zeroconf-like scheme for advertising SIP AORs in the local network (like Apple's iChat). [Comment from minute taker: In discussions afterwards, people seemed to more-or-less agree with Henning.]

Comment: Jon Peterson - Getting increasingly worried. Different architectures, broad design choices, etc. Sounds like a research group. I am hearing 10-year scientific effort.

Comment: Henning Schutzrinne - Have at least 3 working prototype implementations that implement some of the models we have talked about. There is more concrete understanding than is reflected in the charter. For example, have an implementation of the abstract DHT interface running at Columbia.

Comment: Jon Peterson - Must identify the pieces that we are going to standardize, and not how we are going to build a product. May not standardize all details required for a product. May just standardize some tools.

Comment: Dan Petrie - Not clear that defining services that peers are going to provide are in the charter. Eg. Voicemail, etc. Dean - See next slide. Dan - Need more details on services provides in P2P network, in contrast to CS network. Eunsoo Shim - Don't want to describe all services in our first go. Need to leave some things for future work. Dan - (gives example of rendezvous as a service we need to cover). Jonathan Rosenberg - I think you two are talking past each other. For example, want a consistent call forward no answer. All peers must do same functions. Philip Matthews - This is fine, but we need to start simply. We need to walk before we can run.

Comment: Darin Lorrie - (Repeats Eric Rescola's earlier point about social vs. tactical self-organization, and wants this to be a charter item.)

Question: Jon Peterson -- (Talks more about the need to limit the initial scope of the work) How do people feel about scope of the work? For example, which is more important: media or signaling?

Comment: Philip Matthews - Signaling and overlay maintenance are the most important things to work on. Media stuff is well-understood.

Comment: Aki Niemi - We need STUN and other components as well. And we need to define some basic services.

Dean presents slide of proposed milestones:

Comment: Jon Peterson - Still worried about the size of the task. I don't like building systems, I like building tools.

Comment: Jonathan Rosenberg - Must do NATs as part of first effort.

Comment: Cullen Jennings - If we do look at the problem of finding media relays, then we need to address the problem of finding the one we want. That is, a nearby relay.

Comment: ?? - I think we need to work on media nat traversal. Dean - That may be sufficient separable to be the work item of another working group.

Comment: Anwar Siddiqui - Comment on Jon's architecture vs. tools comment. I think we need tools, but must give a complete system. We may not standardize an architecture, but at least provide guidance on what the architecture might be. Dean - Perhaps the first two tasks are not so important.

Comment: Jonathan Rosenberg - Can avoid writing an architecture document if you understand exactly what you are going to build. Otherwise, an architecture document is important.

Comment: ?? - I think we really need to use-cases and requirements documents.

Comment: Spencer Dawkins - (Suggests making the protocol document an experimental RFC). Greg Daley - (Expresses concern that we need a standard, rather than an experimental RFC).

Comment: Jonathan Rosenberg - Can you produce a document that demonstrates that there is an architecture that everyone agrees on. Henning says that there is broad agreement. Can you produce an architecture document that demonstrates this before the next meeting? Dean - Are you asking that we finalize the architecture document before the working group even gets chartered? This seems unreasonable. Jonathan - We need a clearer architecture.

[At this point, there was a discussion on trying to finish the architecture document before the group got chartered. On the one hand, people like Jon Peterson, Cullen Jennings, and Jonathan Rosenberg said that they didn't understand the architecture of what the group would develop. On the other hard, people like Dean Willis thought it was unreasonable to expect the group to complete it architecture document before it was chartered, because many other groups had been chartered where there was only a very vague understanding of what the architecture would be. The session ran out of time before any agreement or conclusion was reached.

It should be noted that Jon and Cullen were attending the BOF in their role as the responsible Area Directors, while Jonathan and Eric were attending as IAB members. These four have a major say in whether the WG gets formed or not.]

[There was a meeting later in the day between Cullen, Jon, the BOF chairs, Bruce Lowecamp, and Philip Matthews to discuss this point some more and see what conclusions could be reached. Though no firm decisions where taken, it was re-emphasised that the group needed to be clearer about its proposed architecture.]

Back to the IETF Work Section
Back to the IETF 65 BOF Page

Page maintained by David A. Bryan (dbryan at p2psip dot org) and Tiffany Broadbent (tbroadbent at p2psip dot org).
Thanks to the many people who have contributed links to this site.
Last modified: 3 July, 2009