Subject: [p2p-sip] Updated minutes for P2PSIP BOF

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 3 Apr 2006 15:34:49 -0400

Folks:

Below are the minutes of the P2PSIP BOF, updated with the
corrections I have received so far.

Please send me any more correction you might have.

- Philip

--------------

P2PSIP BOF, Wed 23 March 2006, 9 - 11:30
Minutes by Philip Matthews
(with additional notes from Avshalom Houri)
===========================================

Intro by Chairs
---------------
* 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:
      o This is about decentralized resource location
      o For multimedia session establishment for SIP only
      o Cannot redo work being done in other working groups
      o Need to keep the scope narrow

Use-cases presentation by Bruce Lowecamp
draft-bryan-sipping-p2p-usecases-00
----------------------------------------
* 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:
      o Global VoIP provider	 -- can be either restricted membership  
(closed) or unrestricted membership (open)
      o Proxy server farm
      o Phone system for multi-site organization
      o Content sharing for consumer electronics devices - connect  
cameras or PDAs to share photos or calendars.
      o Systems where there is impeded Internet access
      o Systems for anonymous communications
      o Systems for ad-hoc communication (a "bar BOF" or disaster  
situation, for example)
* 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.

P2PSIP Requirements - Henning Schulzrinne
draft-baset-sipping-p2preq-00
-----------------------------------------
* 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:
      o Distinguish requirements for three models: small-scale  
("zeroconf and "broadcast"), built-in DHT, generic (external) DHT.
      o Characterize security 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.

Draft Charter Presentation by Dean Willis
-----------------------------------------
* 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 at 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 Chang - 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:
         o Use-cases and Requirements - Dec 2006
         o Architecture and Framework - May 2007
         o Protocol Documents - Dec 2007
* 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.]

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 4 Apr 2006 13:13:09 -0400

One more version, this time with Tim Chown's name spelt correctly.
- Philip

Intro by Chairs
---------------

* Comment: Tim Chown - Don't want to require NAT in IPv6 environment.