Agenda

Peer-to-Peer Session Initiation Protocol (p2psip)

Chair(s): Real-time Applications and Infrastructure Area Advisor:

Notes taken by Spencer Dawkins

9:00-9:10 Agenda bash
presenter: chairs
9:10-9:20 what charter is, what we are doing here, how we are going to
move forward
presenter: chairs
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
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
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
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
Henning (presenting own slides)
Discussion
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

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.