P2PSIP meeting minutes Notes by James Polk and Spencer Dawkins, edited by Brian Rosen Agenda Bash, chairs, 10 minutes, 1520-1530 eclients draft, Vidya Nayayanan, draft-vidya-p2psip-eclients-00, 20 minutes, 1530-1550 Does have IPR on this draft, an IPR statement should be coming ÒsoonÓ. - background (see slides) - mostly having to do with bluetooth attached devices - overview of issues wrt destination lists - introduced terms (DAP and OAP) - discussed how clients discover DAP via out-of-band process - discussed failures and handoffs - Francois Ð why is this even a client (as opposed to a peripheral)? Because you might move and want to connect through some other DAP/OAP. - ?? comment about this ID in relation to the "base" draft - ?? questioning the point of attachment of this vs. SIP AORs wrt destination lists - EKR - not much of an optimization Ð at best, 50 percent, but itÕs much worse, because clients donÕt store data and donÕt get unsolicited requests? - Vidya thinks they will get more unsolicited requests in the futureÉ. - David Bryan Ð still cases where you can get unsolicited requests without storing data Ð convinced on this. RELOAD base draft, Bruce Lowekamp, draft-ietf-p2psip-base-03, 1 hour 35 minutes, 1550-1725 Only one revision since last IETF, promise on our children to get more done before Hiroshima. No update to SIP Usage draft. Modified discovery process (donÕt need DNS SRV for enrollment, can be entirely out-of-band), added max_length_response. Lots of list discussion on resolving fragmentation/reassembly (do NOT have consensus on congestion control/reliability now). If a peer failed (in previous draft), node would look at nodeID and drop the message. Now looks at compressed ID, but should have the same behavior. Lots of text changes on overlay algorithm (thanks, Vidya). Now specifies periodic stabilization with an option to do reactive stabilization Ð is this OK? Adding text about clients in RELOAD base draft. RouteQuery doesnÕt tell you about replica sets. - Adam Lake - what happens in the case of an intermediate peer fails? - Bruce - previous ID said node look at Node ID and drop message, now looks at indexing to see if the - now specifies periodic stabilization, with option to do reactive - now have user-key-match and node-key-match - 3 client update options - Vidya - authorization comment, does not satisfy storage model, - Cullen - wants clarification on what was asked, and is open to leaving it on, or it out - Bruce - maybe right approach to is to summarize problem - Dave - Asked Vidya if her original complaint isn't being addressed - Vidya - yes - Bruce - let's take off-line, to list or side conversation - Cullen - need to get use cases clear, but this is offering editors no guidance - Brian - wants to know if user-key-match and node-key-match is in or out, and it seems the room believes (with no hum) that they should be taken out - That doesn't satisfy Vidya's original concerns, so something needs to be added, but the question is what. - Vidya - - Bruce - answer - peer and client will attach in the same manner - Vidya - but that doesn’t make sense - Bruce - yes it does, there is no semantic difference - Ted - recommended change in the slide, but not sure if this is to the text in the ID now - also got onto theme of peers acting as clients too, which Bruce didn't agree with - Vidya - now believes the client does participate in the routing algorithm - Bruce isn't so sure - Overlay Link Changes and Path Forward discussion - - attach issues - want to use TCP without ICE - proposal is to remove *Lite methods by merging functionality into main methods. - about the role of clients in the base draft - Bruce didn't agree at all with what commenter suggested - Brian - WG made a decision on this a long time ago, so if this idea is to move forward, write a draft about it - about app-attach port numbers - Bruce - it wasn't implementation complexity that drove that decision, and he isn't sure why - comment about advertising addresses - Bruce - NATs make this inappropriate - discussed ICE TCP "that doesn't exist" and how he doesn't want to write 15 more pages that will be duplicated in an ICE TCP draft once it is (ever) written. - Dave - discussed common parts of how message is routed - Revision plans - 1 is purely editorial - 1 is on open technical issues - 1 revision focusing on each topic - Adam commented on reviewing and reviewers - Four reviewers for the next revision? Lucy Yao, Ning Zong, -Reviewers for the editorial revision? Brian Rosen -Roni Ð need the revision in timely fashion because of documents with dependencies. Diagnostics draft, Song Haibin, draft-ietf-p2psip-diagnostics-01, 15 minutes, 1725-1740 Removed ECHO method because of security issues (although itÕs more efficient than PATHTRACK in some scenarios). Cullen Ð understand there are problems with late update to base draft, but not sure why you need new methods? Roni Ð that was the Minneapolis meeting request Ð donÕt add parameters to existing methods. Cullen Ð but they have parameters? Roni Ð we were asked to do that then. Do you want to extend the message in the base draft, or have a separate diagnostics draft? Cullen Ð I thought that was about retrieving stats Ð surprised when I saw this, didnÕt understand what these methods did that the methods in the base draft didnÕt do. Bruce Lowekamp Ð this is diagnostic, and itÕs atomic Ð if you send two messages during route flaps, thatÕs not deterministic. Brian read the minutes from MinneapolisÉ Waiting for comments on the draft (do we need more kinds of data?) Want to change IP layer hops mechanism to use PathTrack method. This is simpler and doesnÕt interrupt the routing rule. Brice Ð could you change the word ÒunderlayÓ to Òoverlay linkÓ? ItÕs confusing. What does an on-path peer do when it canÕt implement this? You need root access to do this on most platforms Ð donÕt want to run all P2PSIP applications as root! At least return an error code if you donÕt do it. Sense of the room was ÒcanÕt do this without root/superuser privilegeÓÉ Route log has been removed from base draft Ð add to INSPECT message, and limit the size of the diagnostic information? And move from header to payload? Bruce Ð you can do this with the Forwarding option, thatÕs what itÕs there for. Draft can do connectivity test and collect diagnostics Ð do we need anything else? Brian Rosen Ð the whole Internet runs on PING and TRACEROUTE Ð what else is there? J Brian thank you guys for doing this work in parallel with the protocol work Ð thatÕs unique. ??? Ð do SNMP in the header? Brian Ð donÕt think we can get everything from a MIB, but if youÕre volunteering, please do it! Russell Wang - Battery status? David Bryan Ð donÕt want to require SNMP, concerned about the implementation burden of TLS and similar already. People want to put this stuff on very small devices. Ted Hardie Ð There are places in the past when weÕve standardized protocols that required TTL setting. Theo Ð actually, setsockopt can set TTL from userlandÉ Security requirements draft, Roni Even, draft-matuszewski-p2psip-security-requirements-05, 15 minutes, 1740-1755 - Roni isn't an author - discussed that although this is a requirements filename, it will be changed based on IETF73 meeting to a Security Tutorial document. - Thanks to Dave York for structure and content improvements. - WhoÕs read the document? Very few hands went up. - EKR Ð this is extremely generic. - Cullen Ð donÕt know what this draft is trying to do Ð we agreed to check RELOAD against this draft after Minneapolis, but that didnÕt happen because we donÕt know how to do it. - Sohel Khan Ð I have found this draft useful. - EKR Ð this draft is about a hypothetical P2P protocol, but weÕve got an architecture. - Cullen Ð if this documentÕs goal is to be a general tutorial about P2P security, thatÕs fine, but itÕs not a risk analysis of P2PSIP/RELOAD. - EKR Ð if itÕs a tutorial, it should have no normative content. Every 2119 uppercase needs to be removed, right? Right É- EKR wants agreement all 2119 language is removed - chairs agree to this - Brian taking a hum on adoption Calls consensus is *for* adopting the doc as a WG item Relay draft, Ning Zong, draft-jiang-p2psip-relay-02, 15 minutes, 1755-1810 Consensus at last IETF was to have Direct Response in a separate draft (not in base specification). Separated relay peer part from direct route part, added relay peer use cases, moved text about investigating connectivity to informational section. - open issue IGNORE-STATE-KEEPING (verbose slide) - Cullen Ð how do you know you can set IGNORE-STATE-KEEPING safely? First thing a node does is setting up a lot of connections. If some succeed and some fail, your topology is unstable and things just break. This is exactly when you DONÕT want to set the flag. Need to discuss whether we should be injecting heroin before we talk about the needle gauge we should be using. - Brian Ð this is an optimization, right? - Cullen Ð there are deployments where there is not a requirement to put all of the state in the via list, thereÕs a good reason why this isnÕt in the base draft. As long as weÕre clear about when we can set this flag, we can use it. Configuration would be fine, but donÕt think that the current discovery algorithm works (yet). - EKR Ð would like to understand performance implications when DRR works 40 percent of the time Ð what about the impact on the other 60 percent? Extra delay? - Francois Ð when do we think this will actually work? Went through this before with regular SIP, didnÕt work enough to justify the effort. Cost to do this is high. What has changed since we reached the opposite conclusion in SIP? Adopt DDR and RPR as WG item? - Bruce Ð biggest issue was having forwarding option in base draft. After we decided not to, we can adopt this draft and just understand the constraints where it might not work. - Cullen Ð we didnÕt get any answers to questions like Òwhat kind of performance this will provide?Ó Put all the forwarding options in the base draft? - EKR Ð adopting a work item is a commitment Ð should answer the questions about whether we can actually use this before we adopt it. - Cullen Ð donÕt need simulation output showing performance, just need a reasonable argument that this will make things better. IÕm arguing that it will make things work when youÕre joining an overlay. No counterargument is being presented, and we do this meeting after meeting. - Bruce Ð there is a section about why youÕd use this, but it doesnÕt discuss cost of using it, and cost of failure. If we had that, maybe it would be enough. I think there are use cases where this is useful. - Brian Ð have had a lot of discussion and a lot of general interest. Suggest that authors spin this again and try to address these concerns. - hum to adopt this as a WG - sounded like the room was split 50/50, therefore the chairs called "no consensus" to adopt this. - Split the document and adopt RPR? Bruce Ð Relay is basically TURN. If anything is going to work, it would be relay??? Francois Ð problem is that people may not like the details Ð when it fails, it fails badly. Brian Ð best path forward is to try to address the objections.