IETF 72, Dublin Meeting Minute
P2PSIP: Wednesday, July 30, 0900-1130
Chairs: David Bryan and Brian Rosen
Notes by Roni Evan, edited by chairs


Agenda bash
No comments

P2PSIP reload, Presented by Bruce Lowekamp

Open issues from list discussions

Ping

Proposal - no discussion - authors will go with their plans

Non-ICE 

Should peers be allowed to implement ice-lite?

Comments: 

Ted Hardie - peers are clients, why use lite

Jonathan Rosenberg- there are use cases that may use lite but typical
case will need ICE. ICE defines when to use lite or ICE so have the
same 

Ted - in P2PSIP you will know the network topology and implementation
may use lite but as a general solution to not support ICE is not good 

Francois Audet - if you know that you do not need ice you will not
implement so why prevent it. Add text with use case and let
implementer decide 

Dean Willis - why specify in reload - just point to ICE-lite and not
mandate here. 

Ted - believes that we need to be clear from the beginning what is the
NAT traversal solution in P2PSIP. Currently three device classes need
to be supported, understands why in deployment but in specification
will cause complexity 

Henning Schulzrinne - those that misjudge what to do will fail behind
NAT if do only lite. By not having lite we will have either ICE or
nothing which is worse. 

Ted - do not use GWs to connect to rest of P2PSIP. Want something
clean that will support the traversal underneath it 

Jonathan - if you make it MUST you will have interoperability problem
since some may just ignore while others will assume that all have it. 

Christer - note that for TCP there is no ICE-lite. Comedia is not lite
xxx- what about IPv6 

Brian Rosen - two option -
1. ICE must
2. Not a must for ICE (must have at least ice-lite)
Consensus for option 2

Error codes

Cullen Jennings - Reason phrase - some readable is useful not written in text
Henning - have a field helpful but not defined content leaving it to
the implementation. 

Consensus: Error codes definition and optional reason code left as free string.
Response codes - 

Henning - similar to HTTP will work in majority cases not work always
since close. Prefer distinct codes - suggest structure with severity

David Bryan - codes came since we started on top of SIP. There is no
match now to p2p. (who is the client and who is the server).

Consensus on own structured error code space with severity. Not
necessarily digits bit maps.


Bootstrap peers

Suggest method to determine if peer is good bootstrap peer is out of scope

Spencer Dawkins - why - it is deployment specific. Add information

Draft refers to mDNS should it stay - 

Henning - not final - suggest leave a hole for it in current draft no
normative language. Separate draft for discovery

Brian - in the past we have one mandatory method to make it
work. Would like it to work on the Internet 

Ted - not mDNS and have something for the internet. Separate draft

Cullen - work out of the box, if agree on mandatory and have it in a
separate draft OK.

Consensus - remove mDNS have way to do it?

Bootstrap Servers

Is there a need to specify any behavior for boottstrap serer and is it
different from a bootstrap peer.

Dean - no need 

Agreed.

DHT Scalability

Proposal -  not a full solution suggests  to revise mandatory DHT and
study behavior across full range of environments

Gonzalo Camarillo - agree, runs a big and small network - looking for
adaptive DHT based on network size

Henning - agree that we can study and delay decision. Add open list to
document and this should be part of it

Jani Hautakorpi - other concerns and not only the ones in the slide (keep alive traffic)

SIP TUNNEL

Do we need TUNNEL support for SIP 

Was removed in reload-04.

Alan Johnson - it is part of the rendevous functionality - so needed

Adam Roach - rendezvous is not SIP specific

Alan - need if ICE not working for SIP or no TURN.

Henning would like to keep base lean and have it a separate extension.

No SIPS and no trusted proxy and tunnel not fully specifying how to
route secure SIP messages.

Cullen - this is not a short text and have some current text that
relies on TURN and ICE. So is there a real need for it considering the
complexity

Eric Rescorla - if option you will not know if other side support
TUNNEL.

Henning - need SIP specific reload specification in the general
documents. Want to allow easier solution for those who do not support
SIP for example only jabber. So maybe have that if you build a SIP
based (Aware) system you MUST support SIP TUNNEL.

Jonathan - need to define how to negotiate support. 

Consensus - bring use cases in list and finalize by next meeting
(possible MUST have in SIP case)


Methods

Should we use generic methods or have each overlay algorithm its own.

David - it will be ugly to allow for each algorithm its own methods -
may lead to different names for same semantics

Henning - easy to monitor and debug if generic. Is there a strong
reason for it. Generic will make DHTs think about how to work in the
framework of methods.

Consensus - leave generic

Service Discovery

Do we need a base (mandatory) service discovery algorithm?

Cullen - need something minimal for SIP since otherwise not
working. Depends on the percentage of servers that support TURN. Need
number

Brian - out of the box requires base. Is the current works, not
sure. If need 25% on the internet need TURNfor it to work - not
practical.

Xxx - maybe need flag in the routing header to let the ime
 
Ted - Case of servers behind NAT will not have ICE.  Deployment base
on environment will make it work so maybe have it optional based on
deployment.

Summary

MUST have a service discovery - no consensus on if current is enough -
need some tests results. (other view does not to be optimal need a way
to implement) - still open


Other open issues:

Presented.

Comments

Spencer - where is layering - answer in the overlay draft

Does reload support only DHT (unstructured DHT) - take it to the
list. Brian asks people to review what the problem in current
document.

Brian - Was adopted as a WG item on the list but suggested a HUM in
the meeting (look insane).  Did not take place. 

Ask if someone will appeal (needed for writeup) 

Jonathan - Appeals would be on the work or people won't say in open meeting




P2PSIP concepts, Presented by David Bryan

Presented changes from 01 to 02

For 03 want more major revision.

Propose - 
* Have a decision to a section (history?) 
* Remove alternate architecture/ protocols and mentions them in history section.
* Explain relationship between SIP and P2PSIP 
o Henning - belongs to the protocol specification and not here. 
o David  - reason is that the document keeps the process and this is
introduction.
o Henning - need to be clear the purpose of the concept document.
o Spencer - say that reload is not a SIP extension.
o David - idea to give introduction to reload for people outside the WG
* Describe application scenario as overview to managers. Take from app scenarios
* Clarify the peering protocol - not only for SIP



Overlay pointers, Presented by Ted Hardie

Who read - 4 people

How do you find p2p network - you hear about them 3 mechanisms to
discover p2p network using p2p tools.  

Overlay node URI

Cullen - semantic good syntax should be better. (combine overlay node
with resource)  

Ted - can have context to the overlay node.

Cullen - suggest overlay node and scheme merged

Cullen - overlay pointer - why IANA for schema

Ted -  can add otype - like reload core or other

Ted - overlay node - is it generic allowing any e.g. reload, bit
torrent, not sure. How to merge. 

Bruce - like the idea - the xml file is protocol specific 

Ted - current document is vey basic.

Henning - description should be simple - no mismatch or
repetition. Should be generic and not replicate the core
prototcol. Should have also service discovery but then will not be
generic 

Ted - do you mean that the currently very high level and if add will
not be generic for global discovery.

Ted - way to supply a pointer that can be used to tell others to test
it. Once connecting it will be specific to figure if you can use it. 

Progress?

Should it be discussed on the main mailing list - yes!!
Take the issues discussed here to the list



Relay peers and direct response routing, Presented by Jiang XingFeng

Routing modes
Add to symmetric direct and relay peer - reduce number of hops.

Bruce -  not a problem to add to reload but does it help. We have
existing mechanism that work with NATed environment - do we need it,
it reduce the hop count, not important if not using DTLS. You still
need the fall back. Not clear in environment 

Henning - oppose - no advantage adds complexity.

Ted - support - environment with large hop count will give
advantage. Time is long on cellular network. 
 
Spencer - large overlay will benefit, leaving it open since there will
be non SIP application scenarios

Cullen - what is the reduction in case of hop count. 

Ted - will bring to the list xml document.

Cullen - recollect - not by half, and this may fail in some use cases.

Ted - say the deployment want response in 3 sec

Cullen - on the list - metric for success in order to add it.

Henning and Bruce - keep the bearer for the response

Consensus call:

Interest as a WG

Kill it?
Hang on see what involves?

Consensus - keep it as personal draft and wait for better consensus
before a WG items

Security merge

Brian - read the draft!!




P2P diagnostics, presented by Song Haibin

No questions

People read and have interest

Brian - one more cycle of discussion on the list.