Subject: [p2p-sip] Draft minutes for P2P-SIP BOF at IETF 65

From: dean.willis at softarmor.com (Dean Willis)
Date: Sat, 01 Apr 2006 14:46:46 -0600

Here are the draft minutes most nobly edited by Philip Mathews. Please 
review, and bring any discrepancies to the attention of the list.

--

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: ?? - Must have IP version independence. Would like to see 
IPv4 and IPv6 interoperability as a requirement. 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: 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: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Sun, 2 Apr 2006 12:56:30 -0500

At the very end of the session (during discussion of the milestones), I 
asked about producing the protocol specification as an experimental RFC 
since there seem to be a fair number of technical open issues lying around.

I did not say this at the mike, but was remembering that the description of 
Proposed Standard from RFC 2026 is "should have no known technical omissions 
with respect to the requirements placed upon it".

Greg Daley expressed a concern that we need a standard, not just a 
specification, or we'll miss the window (if I got this correctly).

I was, of course, the jabber scribe so this exchange didn't make it into the 
Jabber logs (but it should be on the audio). Cullen asked me afterwards to 
make sure that it appeared in the minutes.

Thanks,

Spencer

---

From: tjc at ecs.soton.ac.uk (Tim Chown)
Date: Sun, 2 Apr 2006 19:10:02 +0100

The IPv6 requirement comment (in two places in the minutes) was
from me, for info.

I did also say that it would be nice to see the IPv4/IPv6 interworking
explicitly in the Charter, even though the 'default' position for WGs
is that IPv6 is on the table unless explictly stated otherwise.  This
will help focus minds on the issue being there. 

Dual-stack SIP components today give some interworking, but in a p2p
environment you face an IPv4-only and IPv6-only node combination, so
some translation is required at the network/transport/app layer...

-- 
Tim/::1

---

From: threelions0916 at yahoo.com.cn (Michael Liu)
Date: Mon, 3 Apr 2006 11:28:40 +0800

I'm interested about the service capability of p2psip, some one say p2psip can do everything that c/s sip can do, including voice?video?real-time text?presence?voice mail, etc , but how should these services be implemented in p2p sip? which service should be distributed on p2p network and which service can be hosted on a central server? 

In my opinion,  nat traversal and voice mail should be distributed on the p2p network, voice?video?real-time text session can be established using sip after a location service is completed by p2p layer . but I 'm not sure if the authority service and presence service should be distributed on the p2p network or  be hosted on a central server? which way is more practical ?

I took part in the NGN summit meeting hosted by china information industry ministry ,most experts from the telecommunication equipment manufacturers and service provider agreed that IMS is the target of  network evolution to NGN, but one expert expressed the opposite opinion. he said p2p sip may be another way to NGN, to achive this goal p2p sip must at lease offer all the services IMS can provide technically. 

regards

Michael
Apr.3 

----- Original Message ----- 
From: "Dean Willis" <dean.willis at softarmor.com>
To: <p2p-sip at cs.columbia.edu>
Cc: "Jon Peterson" <jon.peterson at neustar.biz>
Sent: Sunday, April 02, 2006 4:46 AM
Subject: [p2p-sip] Draft minutes for P2P-SIP BOF at IETF 65

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

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Sun, 2 Apr 2006 23:29:46 -0700 (PDT)

Spencer:

You made excellent observation with regards to 2026. I also would
like to bring attention to the requirements of RFC 2418 with 
regards to BOF:

    - Is the proposed work plan an open IETF effort or is it an attempt
      to "bless" non-IETF technology where the effect of input from IETF
      participants may be limited?

      Well - a lot of discussion in the BOF appeared to me as if a 
      set of guys were simply trying to get the "blessing" of IETF on 
      whatever "architecture" they have come up with. I would like to
      see more drafts and more discussion about possible designs, and 
      alternative architectures before we create a WG and start pushing
      the first design that someone could put together.

    - Is there a good understanding of any existing work that is
      relevant to the topics that the proposed working group is to
      pursue?  This includes work within the IETF and elsewhere.
          It seems that  thinking VoIP over P2P in terms of sip created and    
        managed DHT  is the only trick till now. Is this good enough understanding
         of    the possible realization of VoIP over P2P? IRTF researchers say that
        they are still studying P2P architectures, but some sip engineers think
        they can  standardize a particular "DHT" design  any way . Just think about
         the contradiction in claims.

    --mike

Spencer Dawkins <spencer at mcsr-labs.org> wrote: At the very end of the session (during discussion of the milestones), I 
asked about producing the protocol specification as an experimental RFC 
since there seem to be a fair number of technical open issues lying around.

Thanks,

Spencer 

			
---------------------------------
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/20060403/d37f575e/attachment-0001.html

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Mon, 03 Apr 2006 10:39:28 +0200

Mike Robinson wrote:
>       whatever "architecture" they have come up with.

As far as I'm concerned, the purpose of the arch discussion was just to
say: "Hey, look: this won't be a heresy".  It showed that:
+ in an environment with limited resources it will be possible to
  initiate sessions (not VoIP sessions, _sessions_!) through
  the SIP protocol replacing the role of the registrar/proxy with an
  _external_ lookup function (e.g. a dht);
+ if such a limited environment wants SIP connectivity with the whole
  Internet it will achieve that in the traditional way (e.g. binding
  some of its peers acting as "P2P proxies" with a name like:
  "myoverlay.dyndns.org").

The work - as described in the charter - satisfies all 2418's
requirements and, beeing very early, leaves the door open to any further
architectural proposal, IMHO.

>          the contradiction in claims.

Studies about p2p and, more generally, distributed systems started some
decades ago and will never end.  So far, the group has "good
understandig" of the tools (i.e. dhts) which can be used for
establishing a SIP framework in the scenarios listed in the charter.

A common mistake is to expect this group working on a replacement for
Skype: in that case we really won't have enough knowledge, but that's
not the aim.  For whom's interested in that, I'd suggest to look at a
notably open project hosted at www.openwengo.org.

Enrico

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 3 Apr 2006 08:57:55 -0400

> make sure that it appeared in the minutes.

Spencer:
Thanks for reminding me about this. I vaguely recall it from the  
meeting.
I'll add the following to the minutes:
* 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).

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 3 Apr 2006 08:35:00 -0400

Folks:

It would be very much appreciated if we could restrict this thread to
corrections on the minutes.

If you want to comment on some aspect of the discussion captured
in the minutes, then PLEASE start a different thread.

This will make it easier for me and others to sort out what are  
corrections and
what are your points of view.

Thanks in advance for your co-operation.

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 3 Apr 2006 10:17:32 -0400

> some translation is required at the network/transport/app layer...

Tim:

I have changed:
     * Comment: ?? - Must have IP version independence. Would like to  
see IPv4 and IPv6 interoperability
       as a requirement. Cullen Jennings - IPv4/IPv6 interop is a  
requirement. Henning - Agree.
to:
     * 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.

(The minutes already had your name against the second comment).

- Philip