Dean Willis notetaker, edited/posted by and comments/corrections to David Bryan.
Chairs
Slides Presented
Philip Matthews proposed to move client discussion to first item, let run until it stalls as it is a long-standing issue. Eric Rescorla opposes, as other discussions may influence this. Counter proposal is to have a hard stop near end and do clients then. JDR notes that the "role of HIP" is a major issue on the table that isn't on the agenda. Discussion ensued as to best way to come to some resolution path for actually making forward progress. Agenda may be re-examined following discussion of open questions.
Led by Spencer Dawkins
Slides Presented
Noted that the NAT traversal discussion seems to be driving the routing discussion.
Philip notes: There are two ways to get a request there : direct and hop by hop. Three ways to get request: hop by hop, reverse route, or direct.
Henning observes that the the choice of routing algorithm may vary based on the current situation, so it might be reasonable to implement many in the protocol and pick at run-time. What we need to do is learn how to characterize them and learn what the cost of supporting them is.
Bruce notes two issues:
From Jabber, jiang_xing_feng: I think semi-recursive routing mode should not be excluded now due to its advantages in day over other routing mode.
JDR proposes a general guideline that it is better to have just one way than many ways. Can we pick one mode that always works relative to others that just work sometimes? Bruce responds that recursive always works, but that many DHT algorithms don't because they presume things learned during iterative routing. Ted argues that considerations of optimality may lead one from a technique that to one that works works well in a practical deployment. The characteristics of the devices and real hop count need to be taken into consideration. Hui Deng voiced a similar concern. Cullen notes that it is important to know when to use each mode.
Question from chairs: Can we come to any conclusions here? Can we throw anything off the table now? Poll taken, very few people believe that any path can be discarded now.
Led by Philip Matthews
Slides Presented
Issue: Opening a Connection Poll on slide 2: Anyone think we are not using ICE here? No responses noted.
Issue: Finding STUN/TURN Servers
Two solutions proposed so far -- through overlay maintenance, by random probing. Eric Rescorla noted that ASP document discusses the math here some. Salman will send references for some search approaches to list. Bruce noted that reload has an additional technique. Henning raises the question of whether we want specific solutions for each service or a more general solution.
Issue: Large messages over UDP Options: 1 IP fragmentation, 2 peer protocol fragmentation, 3 use TCP.
Bruce L. notes that many things break with out-of-order fragmentation, so we should avoid IP fragmentation. Henning notes that as soon as you don't do option 3, you may find that the complexity vastly increases when fragmentation kicks in. Francois Audet reports that many enterprise routers fail option 1, and that #3 is only reasonable solution. Jonathan Rosenberg also endorses option 3. Noted that this may require more frequent use of TURN. Ingmar Baumgart asks if we're talking about TCP for large packets or all packets -- answer is all. Brian Stucker noted that this is a transport protocol solution and there are other things like SCTP that are not TCP and don't have UDP's frag issues. Cullen notes that people seem to be predicting a 90% success rate for UDP direct connect and under 40% for TCP. Noted that many people believe there will be no TURN servers, due to lack of incentive. Henning wonders how much transport flexibility we want to build in.
Next issue skipped for time.
Led by Marcin Matuszewski
slides presented
Issue: Difference between Client, Peer, and SIP UA
Question from Henning: The amount of awareness that a client has of an overlay may vary. Do clients know what DHT is in use, or what routing model is in use? Do they know what peer IDs look like?
Issue: The Role of Client
Henning notes that there may be good reasons not to become a peer even when you can. Example: longer path to search if there are more peers. Rather, we should have the smallest number of peers needed to meet the load of the overlay.
Issue: Reasons behind having a client node type
Issue: Measurements
Question from Eric: What happens to battery based on multiple connections with keepalives? We need a control group for comparison.
Bruce notes that all of the proposals seem to deal with clients, but none deal with clients providing storage.
Question from chairs: How many people think we will eventually need to have some sort of client protocol? many. never: few
Defer the work? many. now? few.
Cullen notes that naming and routing to things that aren't peers.
Philip: we will have to address many points in peer protocol anyhow, like some connections between peers that are flaky while others solid. This may mean a modal protocol, sometimes peer-like, sometimes client-like, sometimes split. Better to work from peer protocol. Also note that applications have natural client protocols, like SIP.
Spencer asked are there peer protocols that won't support clients?
Dean noted that peer-client transition is not a fixed subset, but is probably dynamic, and along several axes (capabilities, services) rather than singular (routing/non-routing). A fixed client protocol is much less useful than a dynamic adaptive peer protocol.
Henning observed that it doesn't seem that important to implement a fixed simple subset, when the costs for fuller functions are marginal and incremental. This means it probably isn't worth spending a lot of time on it now.
Henry asks if it would be reasonable to define a client only for SIP? It seems likely that real systems will use other interfaces as well.
Philip notes that one of the applications of the overlay is a distributed database, and that "get and put" might be the "natural client protocol" of that application.
ZhengHewen spoke further supporting a need for get and put operations. Essentially the client protocol is not completely different from the peer protocol, many proposal contains it
Conclusion from chairs: We will have clients that will have to do at least a get-put, all protocols will have to do that, and we'll not put a lot more meeting time into that for now.
Led by Eric Rescorla
slides presented
Issue: Crypto-generated peer IDs
Question from Henry: Why is the peer ID generated by the peer instead of an enrollment server? Ans: It's so we can run without an enrollment server. Henry finds this doesn't fit his model of operational identity assignment. Response is that there are other models of peer-ID generation.
(question cycle missed over name confusion)
Issue: Chosen Location Attacks
Noted by Salman that the the current analysis is specific to DHTs.
Issue: Proof of work, force attacker to do work
Issue: Invitations
Dean observed that a delegated PKG (partial key model) could potentially solve the problem of cryptographically binding a key to a peer-ID produced by an inviting peer.
Noted by Henning that these sort of bindings don't prevent naughty behavior, they just give us certified naught behavior. The crypto merely decorates the pig. EKR responds that the crypto here is being used to limit the damage that a misbehaving node can do. Henning counters with a botnet that enrolls once per bot. Further discussion ensued.
Henry asks that, if we have anything we can claim is better than an enrollment server, we need to examine those claims closely. Philip concurs.
Issue: central Enrollment Server
Poll: Who is in favor of last sentence of charter? Strong consensus on not doing non-centralized enrollment process. Charter is unchanged.
Poll: In favor of central enrollment server as a key solution to prevention of peer-ID attacks as discussed in the preceding?
Chairs: In PH, we will settle "is HIP in or out?"
Chairs: People are encouraged to converge their protocols. Coalescing increases probability of adoption.