Peer-to-Peer Session Initiation Protocol (p2psip)

Chair(s):

David Bryan <dbryan@sipeerior.com> ,Brian Rosen <br@brianrosen.net

Real-time Applications and Infrastructure Area Advisor:

Cullen Jennings <fluffy@cisco.com>

Notes taken by Spencer Dawkins

9:00-9:10 Agenda bash
  presenter: chairs

Have we agreed on a client? Not yet...
some scribe dragooning happened here...

9:10-9:20 what charter is, what we are doing here, how we are going to
move forward
  presenter: chairs

primary tasks - overview document, peer protocol, optional client protocol, usage document
haven't picked a particular DHT or syntactic protocol
Assuming existence of enrollment process
will work with other working groups, will not change SIP, will include NAT traversal, will think about security and privacy
Out of scope - other applications, research questions, locating resources based on something other than URIs, multicast and dynamic-DNS-based approaches for lookup
have to have serious progress on overview document by Chicago

9:20-9:40 Overview Document work: What are the major open questions in
this draft?
  presenters: Philip Matthews and Dean Willis
  relevant drafts: draft-willis-p2psip-concepts-04
  :10 minutes for presentation, remainder discussion

major changes this version - terminology, locating and joining, role of overlay, NAT and transport aspects, ???
have more detailed model for locating and joining an overlay
jonathan - three roles could be in one box? you're using P2P protocol to join, right? not an arbitrary choice? bootstrap peer could choose itself - this is wrong, concepts draft needs to say that bootstrap peer and admitting peer really can't be part of the same box
cullen - document isn't clear on whether admitting peer is the first peer you talk to, or the one where you end up in the overlay
philip - thought this is clear, admitting peer is the one in the right spot, not just the first one you talk to
cullen - still not clear
henning - putting boxes around three diffeent things, deciding if peer should be admitted, finding the place for a peer, finding peers that help you find the other two kinds of peers - call second role an inserion point, just be clear on the three roles
philip - two roles defined now, bouncer could be played by either role, concepts draft may not say this, but it could. Don't think there's a third box.
henning - focus on roles now, boxes later
users and services are both resource IDs - are there others?
roles of the overlay - redirect requests, or forward requests, or treats peer as outbound proxy
cullen - proxy would also be the same as the peer? No
jonathan - another model, what's stored is peer identity and peer protocol supports ability to connect through NAT - NAT traversal draft is ingenious, exscept that it uses SIP
dean - though of sipsec connection to endpoint, too
jonathan - would also work. like this approach
philip - thought jonathan's model was orthogonal, could be used with any of the others, can talk offline
dean - jonathan is talking about forming a tunnel instead of passing messages
vijay - sipsec? could be, that's one way to do it. some kind of tunneling as a message-passing mechanisms
two approaches for NAT traveesal and transport - two-level, and partial mesh
working assumption is that credentials are something like a certificate. Doesn't have to be that way. Are peer credentials a discrete class? how do service credentials work?
client models are still up for debate.
don't know how to select between peers that offer the same service
don't know what the visibility of messages to transit peers should be
jonathan - "don't know if I can really trust my proxies" - in any model except direct connections, proxies must be untrusted. Please capture this in the draft.
don't know what to do with hybrid domains (conventional and peer-to-peer)
spencer - this includes using same AOR in both domains
Cullen - don't have one domain going both ways
Where is this work going? is it the framework draft called out in the charter?
Jonathan - please adopt
Bruce - need to have WG change process if we adopt it
Keith - no reason to publish this document now
Philip - someone suggested keeping this document alive as a draft, not publishing in July - do this?
Henning - keep it alive, people who need it can read it. Not a huge community of implementers who won't see an ID. If it's almost done, send it out soon
Spencer - ready to have WG change control?
Henry - keep it alive for flexibility
Cullen - discusses all the possibilities, should narrow down. Don't want late surprises, get something out and reviewed before we finish all the work.
Keith - is appropriate time to move to working group item
humm - adopt as working group item
Jonathan - need formal ownership of editor token
Brian - agree, chairs will appoint an editor

9:40-10:00 Open Question: Selecting a DHT
  Charter states we will support multiple DHTs. We need to select one
(or a very, very few) "base", must implement DHTs. Leading candidates
today *appear* to be Chord and Bamboo, and possibly Kademlia.
  Discussion of Protocol Implementations of pluggable DHTs and the
tradeoffs between Chord, Bamboo, and Kademlia
  presenters: Henning Schulzrinne and David Bryan
  relevant drafts: draft-baset-sipping-p2pcommon-01,
draft-zangrilli-p2psip-dsip-dhtchord-00,
draft-zangrilli-p2psip-dsip-dhtbamboo-00
  :05 minutes for presentation, remainder discussion

three questions - choose one? require "must implement"? how to select "must implement"?
jonathan - "must use a single DHT in a ring"? different question - but can protocol support more than one, in different rings?
Henning - very possible to run multiple overlays simulteneously as "ships in the night" - pipe provider may have new fancy DHT and convince clients to support it
Spencer - don't see how we can have interoperability withoug a mandatory-to-implement
Henry - can't have a preferred DHT - for complete service, you have to have other functions
Henning - agree in theory that we need to choose one, but we may not need to do this. If we do, please choose one, but if we don't, please don't. Hope we don't have to
Cullen - inconsistent with charter - private peer protocol wouldn't be covered
Philip - would like to make multiple choices - would like to see an example of multiple choices
David - two proposals do this now
Philip - thought we offer/answer to figure this out. What happens when overlays split up and make different decisions?
Jonathan - but that requires fragments to shrink to zero before they can change
Philip - if we do multiple choices, we need to select a must-implement
Keith - DHTs that support multiple applications?
??? - everything depends on the deployment scenerio
Henning - be careful about must-implement ensuring interoperability, if someone sets up the ring with an non-default, peers who don't support the non-default can't join the overlay. Don't overpromise.
Support for more than one DHT?
Humm - multiple choices, not simultaneously, with must-implement - most agree, but some dissenters
Please look at slides on "how we make choices"

10:00-10:30 Open Question: How do NATs affect the requirements of a protocol?
  Discussion of lessons learned from proposals for NAT traversal and
how they translate into requirements for the protocol
  presenters: Bruce Lowekamp and Philip Matthews
  relevant drafts: draft-matthews-p2psip-nats-and-overlays-01,
draft-matthews-p2psip-dsip-nat-traversal-00
  :10 minutes for presentation, remainder discussion

At least three kinds of messages - peer/client control messages, SIP, RTP. For RTP, SIP recommends ICE/STUN.
Have two approaches - "super-peer", "fully-distributed" (although some people don't like these names)
Provide solutions for control messages and SIP. Could also do RTP, but we will use ICE anyway for RTP
Jonathen - "dynamically configure superpeer status"? seems profoundly hard
Henning - logically, ordinary peers are in same topology as they would be as super-peers
Philip - usually ordinary peers are more client-like (using our terminology)
david - more than "profoundly hard", because you have an incentive to cheat and refuse to do routing
Henning - no way to fight that in an open protocol - people can send anything
Kevin - do ordinary peers behind the same NAT communicate directly?
Philip - could do this either way, whatever we think is better
Fully-distributed - run routing protocol (don't want to do this), set up your connections to match your finger table, etc.
Jeff Michaels - mixing two things, NAT traversal and DHT stuff
Jonathan - that's what I LIKE about this approach!
Jeff - does that mean you don't have to do ICE?
Philip - would be good to make connections match finger table, but don't HAVE to do this
Jonathan - don't understand - finger table IS who you talk to, right? This is the way ICE works, if you can communicate SOMEHOW, you can establish a direct connection. This may be leading you to supernode approach.
Bruce - did this slide, should have bolded third bullet - connection table is superset of routing table
Philip - could also do "greedy routing" - route to person you think is closer
Jeff - NAT traversal is orthogonal, deal with it separately, make two decisions. Other considerations, not NAT traversal considerations
Jonathan - this is a no-brainer. If you do this, you can still do either model.
Henry - if people had come here with background ... how you select neighbors, shouldn't discuss it hear, please read about it the next time we discuss it
Spencer - Jonathan is saying you don't have to have a public address to be a superpeer, right? right... this is really important
Superpeer - has lots of deployment experience, but requires at least some superpeer candidates
Henning - tradeoff between complexity and implementation - not clear we have to make a choice. This is an additional layer of functionality, not required. Assume we have some number of peers existing. If a new peer node shows up, but don't have public IP address, rendezvous nodes just say "thanks, but you can't be a peer". ICE implementation isn't trivial, can't do ICE-lite in most circumstances (Philip agrees - so, do we want a hybrid? Not in the same ring, but could be public-peer overlay that turns clients away, etc.
David - two things proposed - peer protocol, mechanism for telling a node that it can be a peer or not.
Henning - yes
Jonathan - don't require ICE in SIP, implement it if you need it, can do the same thing in this situation. Not Log2 N hops as a fully-distributed Con - don't all DHTs do this?
Philip - no, some have huge finger tables
Bruce - huge carriers and single enterprises are only use cases where you don't need ICE. Vanishingly small. May not even work for single enterprises. Make this must-implement.
Henry - neighbor selection is missing from this discussion. What about neighbor nearness? Add this to ICE? (Jonathan - it's in there). If I have a tree and a circle, I can do multicast and I can do database searches.
Jonathan - ICE has arbirary-selection mechanism. Be careful with ICE, you need TURN servers someplace. Haven't figured out how to avoid this. Yes, there are people who steal public addresses. Don't make any assumptions.
Are there other approaches?
Henry - don't think we can make a decision today.
Does anyone think we've solved this? Nope, will discuss on the mailing list.
??? - hosted entity protocol can globally address devices behind NATs

10:30-11:00 Open Question: What are the requirements for the peer protocol?
  We know we need this protocol. What are the things that a protocol
proposal must do to be considered? What have we learned from the
proposals made to date? We want rough consensus on what this needs to
do, so we can have firm (real) proposals to consider at Chicago. What
sort of routing? Other properties?
  presenters: Henning Schulzrinne, Bruce Lowekamp, Jiang XingFeng
  relevant drafts: draft-bryan-p2psip-dsip-00,
draft-willis-p2psip-concepts-04,
draft-jiang-p2psip-peer-protocol-requirement-00
  :10 minutes for presentation, remainder discussion

Reliable transport mechanism
Support basic DHT operations
Provide routing protocol in overlay
Provide redundant storage, accommodate multiple DHTs, provide NAT traversal
UDP or TCP -
Philip - not sure UDP is always good for NAT traversal. More likely to get a connection, but then you have to send more keepalives - load is more.
Henning - TCP/UDP and ASCII/binary - please don't discuss this here
Cullen - ASN.1 and XML, then we're done
Bruce - these are things we need to decide, not a complete list of considerations
Keith - need to leave some things until you're designing the protocol
Security requirements - authenticate all messages, distributed mechanism for certs, resource registrationss
Ted Hardie - conflating a solution and a requirement - (certificates may or may not make sense) - comparison to non-P2PSIP is a distraction, focus on your requirements
Philip - thought distribute/aquire certificates was out of scope?
Bruce - getting a copy of a certificate - this is really a credential, not how you create a certificate
David - if I give you a mesage signed with my credential, you need a way to retrieve it - not about issuing a new one
Cullen - EKR channeling, you need to know what the threat model is (but delivered much more slowly)
Advanced requirements - neighbor detection, replication, caching mechanism for routing efficiency

Henning (presenting own slides)

Some things that must be covered
Type of data stored
Size limitations
Data expiration - assuming "soft state", can data creator modify expiration time? Is there a DHT instance policy about expiration?
Meta data for real data?

Discussion

Philip - design team for requirements? Brian would like to see drafts, then form design team
Henning - having multiple draft efforts, we have a starting point, need broader input
Brian - please discuss on the mailing list
Henning - not sure mergining more drafts is going to be right way to go
Brian - had use cases, would like to drive requirments that way. Can do this on-list, make contributors the design team
Philip - that was what Spencer tried to do, didn't get support for that
David - will revive the draft after this meeting (Spencer joining authot team)
Brian - people need to think about the requirements for use cases

11:00-11:30 Open Question: What would a client protocol need to do and
do we need it?
  Discussion of client protocol: Do we need a new client protocol
that is separate from the peer protocol and isn't SIP? If so, what
would it need to do?
  presenters: Henning Schulzrinne, Dean Willis, Spencer Dawkins
  relevant drafts: draft-willis-p2psip-concepts-04
  :10 minutes for presentation, remainder discussion

Slide: What Clients Are

Slide: Where Clients Are

Comment from Philip: This is one particular model of a client, and
there might be others.

Slide: What Problem Are We Trying to Solve

Slide: Modes of Operation

(no commments on intervening slides)

Slide: Basic Client Picture

Slide: Basic Client Questions

Question from David Bryan: What do you mean doing several things at once

from Philip:

Approaching question the wrong way talking about mechanisms. We
should talk about what we are trying to achieve. We need to focus on
"why".

From Brian Rosen:

Understand why people want to connect normal sip UAs. We should do
that, but not cater to it. I don't understand why we have a P2PSIP
client. We should get rid of it.

From JDR:

Can't answer this question until you get to fundamental requirements.
What;s the real issue?

From Philip:

We do want to be able to interact with existing SIP UAs. The thing
here should not be called a client -- it needs to be called a SIP UA.
A client is something different.

From Spencer:

You need to come up with a list of reasons to do a client

From Alan Johntson:

JDR's questions are the right ones to address. One requirement is to
support devices that have batteries. Also, the requirements in the
client protocol (if Put/Get) are not a good map to SIP.

From Henry S:

Example of mobile device. Because of battery, have constraints. Might
want more than SIP, doing something with DHT. This means you need a
client protocol.

JDR:

Question about what you want to "get" with protocol. Getting a
contact won't work. If you just glued on a proxy in outbound mode it
might work.

David:

What are you getting and putting here?

Henry:

Might want to do a search for all the Rosenbergs in Prague. This goes
beyond SIP proxies.

Brian Rose, Chair:

I want use cases. What are you trying to accomplish and don't have to
do with a battery-equipped peer?

Philip:

People who want a client need to submit a draft by Chicago bringing
up requirements above "a SIP UA"

JDR:

Henry asked for search. Thought that was outside our charter (David
confirms outside).

Wilhelm:

I like this picture. We need things to fill it out, but it is a good
starting point.

Brian:

We agree we want to be able to connect a SIP UA to a peer with some
box. (note: need to hum)

We are asking people who think they need a "client" to explain why.

Poll: Do we include a box that connects peer to SIP?
Result? All in favor. Will verify on list.

Notes taken by Vijay Gurbani


P2PSIP WG

David Bryan went through the aim and charter of the WG: what is in
scope, out of scope, etc.  Produce the following:
 - Overview document
 - A proposed standard defining a P2PSIP Peer Protocol.
 - Optionally, a proposed standard defining a P2PSIP Client Protocol.
 - A usage document: once we have identified the protocols, how
  do they work.

Initially assuming an enrollment process that provides distinct
names.

Not reinventing the communication aspects of SIP.

Firewalls and NATs exist and will be taken into account.

We are not solving "research" type questions related to
P2PSIP or P2P in general.  These will be forwarded to IRTF P2P
research group.

Will not look at mcast and dynamic DNS approaches.  Only looking
at structured P2P DHTs.

David Bryan went through the milestones (see slides.)

P2PSIP Concepts and Terminology, Dean Willis
(draft-willis-p2psip-concepts-04).

Major changes are around terminology, added discussion on
locating and joining an overlay, added credentials, and client models.
(See slides for for more detailed changes.)

[ Discussion ensued regarding the notion of bootstrap peer, admitting
 peer, etc. ]

Jonathan: Make sure that we understand that admitting Peer should
be a role of the function of the DHT algo; not an arbitary choice.

Henning:
1. Peer which admits you (gives you right to be in the DHT).
2. Insertion peer: your new neighbor.
3. A box that gets you to the first admitting peer and maybe eve
 to the insertion point.

3rd role can be played by anybody, but maybe special beacons that
direct the new peer.

[ Phillip Matthews took token to clarify this in the document. ]

Role of overlay as ddbase (distributed database): stores resources
keyed by ID.  ddbase stores users, services, and maybe others.
How does overlay work to pass messages?  Open question.

[ Dean went through slides that depicts overlay routing. ]

[ To add to the concept draft: Model that the TCP tunneing model
 gets added. ]

Open questions:
 - selecting between multiple peers offering same services.
 - visibility of messages to intermediate peers.
 - hybrid domains.

Future: Should we publish this as a concepts and terminology draft
or is the draft becoming the Framework draft that is called for in
our charter?

[ Discussion at mic ensued. ]
  
Hum - should this doc be accepted as a WG doc?

[ Hum indicated adoption; no immediate plans to publish an RFC,
  the draft will keep on progressing to iron out plans.  The
  chairs will appoint an editor. ]

DHT Selection, David Bryan

Choice: One DHT or multiple?  If multiple, then one require to implement?
 If one required to implement, then which one?

[ Discussion ensued on mic.

Hum -  Should we agree on supporting multiple DHTs and one mandatory-
       to implement?  Multiple here means supporting multiple implementations
       but not all of them working simultaneously.
 
[ Hum indicated that this is the choice. ]

---

The NAT traversal problem in P2PSIP, Philip Matthews

Went thru the problem statement (see slides.)
3 different types of messages: Peer/Client protocol messages,
 SIP msgs, and RTP msgs.

For RTP use established procedure: ICE and STUN.
For SIP and Peer/Client protocol msgs: the "superpeer" approach, and
 "fully-distributed" approach.

Went thru "Superpeer" approach (see slides.)
[ Discussion ensued on the mic on how to find peers and elevate them
  to superpeers.  This is a hard problem; people do not want to do
  storage and routing. ]

Went through the "Fully-distributed" approach (see slides.)

[ Discussion ensued at mic on
  - how to make routing topology across NATs match DHT topology.
  - whether or not ICE is mandatory.
  No concrete proposals reached.  More dicussion to be on list. ]

----

Requirements of a P2PSIP Peer Protocol, Jian XingFeng

Basic requirements:
 - should relay on transport mechanism to guarantee reliable
 delivery.
 - must provide routing finction
 - should allow communications across NATs
 - ... (see slides.)

Issue: UDP or TCP?
 [ Mic discussion ensued on which is better.  Decision not to
   pursue this slide any further since no consensus will be
   reached. ]

Issue: Security requirements
 - certs to authenticate all messages
 - mechanisms to distribute/acquire certs
 [ Mic discussion ensued on certificate vs. credentials, etc.  No
   concrete consensus reached.  ]

----

P2P SIP Protocol requirements, Part 2; Henning Schulzrinne

Any req draft would have to cover the following:
 - Data stored by the DHT (discussion needed on large messages, large
   responses, data expiration, etc.)
 - Do we need meta-data for data objects in the DHT (creation time,
   access permissions, etc.)

[ Philip Matthews asked guidance on whether a design team is needed
  to hash out the reqs or individual authors keep on going at it for
  a while?
  Chair (Brian Rosen): Need more list discussion and drafts before a
  design team will be formed.  Maybe cull reqs from the use cases. ]

----

P2PSIP Client Discussion, Spencer Dawkins

What are Clients?  Not garden variety SIP UACs, nor the equivalent of
 "peers."

Issue: Clients as storage nodes.  No credible use case so far; deferred.

[ Discussion ensued at mic.

  Philip: Why do we need P2PSIP clients?  The answer will drive whether or
  not we use them.

  Brian Rosen (as individual): I don't understand P2PSIP clients.  We need 
  to get rid of it and focus on normal SIP clients.
 
  Philip: Those that want P2PSIP Clients need to come up with a good use
  case by Chicago IETF.  If they do not come up by then, the P2PSIP Clients
  go away. ] 

Hum - Should the wg work on the normal garden variety SIP UA connected to
      the DHT via some box (a SIP proxy coupled to a peer)?
 
[ Hum indicated yes.
  Those that want a P2PSIP Client distinct from a normal SIP client need to
  get together and work on use cases. ]

11:18 AM Local time.  Meeting adjourned.