Peer-to-Peer Session Initiation Protocol (p2psip)
Real-time Applications and Infrastructure Area Advisor:
Notes taken by Spencer Dawkins
9:00-9:10 Agenda bash
- 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
- 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
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
- 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
- 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
- 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
- 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
- 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,
: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
- 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
- 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
- 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,
: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
- 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
- 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
- Kevin - do ordinary peers behind the same NAT communicate
- 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
- 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
- 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
- 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
- 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
- ??? - hosted entity protocol can globally address devices behind
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,
:10 minutes for presentation, remainder discussion
Henning (presenting own slides)
- Reliable transport mechanism
- Support basic DHT operations
- Provide routing protocol in overlay
- Provide redundant storage, accommodate multiple DHTs, provide NAT
- 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
- Cullen - ASN.1 and XML, then we're done
- Bruce - these are things we need to decide, not a complete list
- Keith - need to leave some things until you're designing the
- 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
- 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?
- 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
- 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
- David - will revive the draft after this meeting (Spencer joining
- 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,
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
Approaching question the wrong way talking about mechanisms. We
should talk about what we are trying to achieve. We need to focus
From Brian Rosen:
Understand why people want to connect normal sip UAs. We should
that, but not cater to it. I don't understand why we have a
client. We should get rid of it.
Can't answer this question until you get to fundamental
What;s the real issue?
We do want to be able to interact with existing SIP UAs. The
here should not be called a client -- it needs to be called a SIP
A client is something different.
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
support devices that have batteries. Also, the requirements in
client protocol (if Put/Get) are not a good map to SIP.
From Henry S:
Example of mobile device. Because of battery, have constraints.
want more than SIP, doing something with DHT. This means you need
Question about what you want to "get" with protocol. Getting
contact won't work. If you just glued on a proxy in outbound mode
What are you getting and putting here?
Might want to do a search for all the Rosenbergs in Prague. This
beyond SIP proxies.
Brian Rose, Chair:
I want use cases. What are you trying to accomplish and don't have
do with a battery-equipped peer?
People who want a client need to submit a draft by Chicago
up requirements above "a SIP UA"
Henry asked for search. Thought that was outside our charter
I like this picture. We need things to fill it out, but it is a
We agree we want to be able to connect a SIP UA to a peer with
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
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
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
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
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.
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. ]
- 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
[ 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
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
- should relay on transport mechanism to guarantee reliable
- 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
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
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
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.