[12:25:06] mlm.michael.miller joins the room [12:28:06] erikmartinfranzen joins the room [13:03:12] sanchiii joins the room [13:05:53] stefan.sayer joins the room [13:06:16] sanchiii leaves the room [13:08:03] Wolfgang Beck joins the room [13:11:03] Wolfgang Beck leaves the room [13:13:26] Wolfgang Beck joins the room [13:16:25] John.Elwell joins the room [13:21:26] jani_h joins the room [13:23:53] Olle E. Johansson, Sollentuna, Sweden (GMT+1 DST) joins the room [13:24:20] Adam Roach joins the room [13:24:21] Simon Perreault joins the room [13:24:30] Olle E. Johansson, Sollentuna, Sweden (GMT+1 DST) is now known as oej [13:24:43] Ted(with knees) joins the room [13:25:01] Magnus Bergman joins the room [13:25:22] KaiFischer joins the room [13:25:32] Gabriel Hege joins the room [13:25:38] Adam Roach has set the subject to: http://www.ietf.org/proceedings/75/agenda/p2psip.html | http://feed.verilan.com/ietf/stream01.m3u [13:25:44] Thomas Stach joins the room [13:25:52] Cullen Jennings joins the room [13:25:54] shamus joins the room [13:25:56] Note well being mentioned [13:26:05] Agenda up [13:26:13] lol on Ted's Knees [13:26:14] eclients now going first, then RELOAD [13:26:33] Sufficient time to get everything discussed; please be prompt at mic [13:26:34] NYX joins the room [13:26:44] Bruce joins the room [13:26:55] mlepinski joins the room [13:27:00] martin.thomson joins the room [13:27:02] tomkri joins the room [13:27:06] note taker sought [13:27:18] Glenn Parsons joins the room [13:27:26] vidya joins the room [13:27:30] James Polk is now note taker [13:27:38] One more volunteer sought [13:27:54] Spenser now the second note taker [13:28:01] He's lying about it being a pleasure. [13:28:05] is anyone using the stremaing audio ? [13:28:09] yes [13:28:24] Vidya coming up. [13:28:41] Does everyone in the chat room have the slides? [13:28:56] Motivation, then brief discussion. [13:29:13] She notes that Qualcomm does have IPR on this, and that a statement will be coming soon. [13:29:29] Background slide [13:29:40] (No slide numbers, sigh) [13:30:05] There is very bad flicker on the slides in the room; somewhat hard to watch. [13:30:38] Discussing situations when a client cannot connect to its identity owner (because of NATs) [13:30:56] metricamerica joins the room [13:30:56] It may also happen when something can use proximity based connections (using a nearby peer) [13:31:28] Now on "Using Destination List" slide [13:31:48] required to get unsolicited requests to be routed [13:32:19] problem: app needs to be aware of need to include reachability information [13:32:34] ekr joins the room [13:32:55] we tried a different dvi->vga adapter and confirmed the display is @60hz, but it didn't cure the flicker [13:33:15] Now on Client, Dap and OAP slide [13:33:20] suzukisn joins the room [13:33:41] OAP is overlay attachment point [13:33:48] Now on eClient Operation [13:33:59] whoever is having a conversation near the mic, please stop. [13:34:56] Now on "Join Process" [13:36:00] Mark Thompson joins the room [13:36:15] Wait, if you can't form a direct connection to the OAP, then there is no optimization here over the native RELOAD client mode. [13:36:59] Now on Message routing [13:37:34] Now on Failures, Handoffs [13:39:09] Francois: if you're trying to solve is near topology, why use client protocol instead of a peripheral? [13:39:46] Vidya: it's a motivation, not the only use case; there may be a need to move, so a peripheral model wouldn't work [13:40:42] Gao Yang at the mic [13:40:53] Gao Yang at the mic: The base draft says that a responsible peer can be used for clients [13:40:57] How is this different? [13:41:35] Gao: Do you think we can select a responsible peer and routing requests by a client to avoid the need for this? [13:41:46] So, rethinking this, I don't think this is much of an optimization. [13:42:04] As Vidya has already observed, this only improves the situation for unsolicited requests *to* the client. [13:42:07] Bruce Lowekmp at the mic [13:42:12] So it looks like at best it's a 50% optimization. [13:42:13] Lowekamp [13:42:28] Magnus Bergman leaves the room [13:42:36] But actually it's much worse, because since clients *don't* store data, they almost never receive unsolicited requests. [13:42:49] So, as a practical matter, you only get an optimization for an incredibly small number of cases. [13:43:03] What am I missing. [13:43:04] Bruce: the SIP usage uses AOR to derive destination lists [13:43:08] (Ted, that was for the mic, I think) [13:43:15] okay [13:44:05] nils joins the room [13:44:14] Bob Penfield joins the room [13:44:35] heard that? [13:44:40] yep. [13:44:46] RjS joins the room [13:45:44] Okay, now it is Bruce. [13:45:57] Base draft -03 [13:46:38] change make shooting motions for only one rev [13:46:53] sip-usage not revved; based on Gao's comments, some editorial needed [13:46:56] Slide 2 [13:47:02] (yay slide numbers!) [13:47:57] Now slide 3 [13:48:23] reviewing long discussion on fragmentation and reassembly [13:48:56] no consensus on congestion control, but there was some on fragmentation. So these were decoupled [13:49:44] via-list is now variable format supports compressed id, node-id, opaque/extension types [13:49:48] Bruce apparently has a 5-watt green laser for pointing at things. [13:50:05] It is bright, isn't it? [13:50:17] i thought he was pointing straight in my eye [13:50:24] I was expecting him to start with "In brightest day, in darkest night..." [13:51:11] you can use laser pointers like that for training cats, and ADs [13:51:31] Question on what happens when an intermediate fails due to churn/other [13:51:46] With 16bit ids and this is stateful? [13:52:49] The behavior depends on the source to regenerate the request [13:52:59] now on slide 4 [13:53:22] Exposing some ignorance here -- we're sending SIP directly through the overlay, right? So won't we run into issues with INVITE 200s? [13:53:34] No, we're not. [13:53:37] Or am I thinking on the wrong layer? [13:53:38] Algorithm specifies periodic stabilization with an option to do reactive; this is a compromise [13:53:48] You use ICE to form a direct connection and then send SIP over that. [13:53:56] Ah, okay. Never mind then. [13:54:11] Now turning off twitter feed for presentation laptop [13:54:23] Support for new kinds (slide 5) [13:54:34] adding user-key-match and node-key-match [13:54:59] Configuration file can specifcy NodeIDs allowed to sign new kinds [13:55:09] Now in 6 [13:55:48] vijay.gurbani joins the room [13:56:15] Describes non-client use case for connections without Update [13:56:45] Wolfgang Beck leaves the room [13:56:51] Added requirement that connected nodes be sent update when responsible ID range changes [13:57:24] Slide 7 [13:58:04] update options: ping check, routequery when update it doesn't understand is received, new generic method [13:58:32] metricamerica leaves the room [13:58:59] Vidya asks to go back to slide 5 [13:59:04] metricamerica joins the room [13:59:26] says that this does not quite handle keyword like storage [13:59:30] For the mic: what's the use case for this for SIP? [13:59:50] Cullen to the mic [14:00:12] Ted, hold that... [14:00:12] Asks for a clarification [14:00:17] lifenghua joins the room [14:00:19] You need to be at the mic? [14:00:25] No, it's fine. I'm happy to remove thse. [14:01:44] spencerdawkins joins the room [14:02:01] Vidya agrees to take use cases to the list [14:02:32] Show of hands for folks who want these to remain in the base draft? [14:02:44] Talking about the current mechanism. [14:02:58] No hands to keep them in, so they will come out [14:03:09] stefan.sayer leaves the room [14:04:00] Now discussing whether the use case motivating this feature is in scope [14:04:09] stefan.sayer joins the room [14:04:18] Vidya confirms that she is fine removing these [14:04:31] Moved to 6 [14:05:10] Vidya believes that you are getting the same behavior as client, without it being explicit [14:06:23] Staffan Kerker joins the room [14:10:43] Sorry for the interrupt, I was at the mic [14:11:25] Now on slide 8 [14:11:58] Discussing stop-and-wait and simple receiver [14:12:10] AIMD and TFRC moved to an appendix [14:12:28] Longer term: ICE-TCP is completed and will succeed (doesn't look likely now) [14:12:55] or TCP over UDP; if it were complete and succeeded, as well as SCTP over UDP [14:13:01] Algorithm from another source [14:13:51] who is speaking? [14:14:02] That was James polk [14:14:09] Discussing SCTP over UDP [14:14:31] TCP over UDP is not being presented because the authors are not present [14:14:38] It did rev [14:14:54] Magnus Bergman joins the room [14:14:58] SCTP over UDP were persuing NAT traversal instead [14:15:09] Not comfortable trying to move SCTP over UDP at this time. [14:15:25] vijay.gurbani leaves the room [14:15:32] Brian believes SCTP over UDP is unlikely to be our solution right now. [14:15:57] Now slide 9 [14:16:59] Adam Roach leaves the room: Computer went to sleep [14:17:22] Propose to add TLV and destination_critical [14:17:25] Vidya strongly supports [14:17:45] Cullen says "it does no harm" and might be a good safety valve [14:17:51] Adam Roach joins the room [14:17:57] Now on slide 10 [14:18:09] Can anyone scribe for a moment, so I can step out? [14:18:24] I can do it [14:18:27] thanks [14:18:55] problem with ICE-TCP being stalled [14:19:34] Proposal is to remove *lite methods and only allow TCP when no ICE is inovlved [14:20:35] Gao: Attach for clients is not critical [14:20:56] Attach for peers is mandatory, but, not for clients [14:21:04] client routing by node id is not overlay's responsibility [14:21:22] Attach and AppAttach for clients should be optional [14:21:45] Bruce: Clients need a way to attach to the overlay, and right now there is no other way [14:22:07] Gao: it is possible to have an overlay that does not guarantee client routing by node id [14:22:30] Bruce: if there is another proposal, please submit a draft; as of now, there is a clear requirement for the protocol [14:22:42] Gao: what is not critical can be out of hte base draft [14:22:50] Bruce: clients are considered crictical [14:23:05] Brian: there was a clear consensus on having clients be critical [14:23:08] bnsmith joins the room [14:23:14] bnsmith leaves the room [14:23:35] no need to revisit that consensus; unless there is new information, it should not be revisited [14:23:39] how to determine what addresses are known to accept inbound connections without ice? [14:23:51] bnsmith joins the room [14:23:51] only use turn candidates? [14:23:52] Gao: client routing can be done at the usage level [14:23:56] bnsmith leaves the room [14:23:58] Simon: A good question. [14:24:03] I'm not actually sure what Bruce wants to do. [14:24:08] i'll go to the mic [14:24:11] David: we can; but, there was consensus to have client routing as part of the overlay [14:24:17] This particular slide wasn't an author consensus. [14:24:39] NYX leaves the room [14:24:42] ekr: are you referring to slide 11? [14:25:16] vidya: yes. [14:25:23] Dave Craig: AppAttach isn't necessarily easy to implement [14:26:04] Simon: Advertise addresses which are known to accept connections? Do you only accept turn candidates? [14:26:24] Bruce: for any internet scale deployment, this is inappropriate [14:26:30] This is for static configuration [14:26:31] Haipeng [14:26:52] says we use TCP when ICE is not needed; we use UDP generally [14:27:29] Wouldn't re-inventing something that doesn't exist simply be inventing it? [14:27:32] Bruce says he did not want to write 15 pages to re-write ICE-TCP [14:27:42] The problem isn't existance--it's usefulness [14:27:54] Folks aren't convinced using it will result in actual traversal [14:28:12] mic: The argument for AppAttach is as Bruce says. When I sat down with people to try to explain how this works, they kept getting Attach for RELOAD and Attach for applications. So, I choked down my urge to tell them they should just read the document more carefully and concluded that it actaully was necessary to avoid confusio. [14:28:16] confusion. [14:28:17] How far do we go using TCP? [14:28:30] Vidya, can you reflect ekr? [14:28:41] She will do [14:29:09] Haipeng: if udp is allowed for reload transport, then the direct response and relay best response should be supported as an extension, since they will improve efficiency [14:29:09] The argument for AppAttach is as Bruce says. When I sat down with people to try to explain how this works, they kept getting Attach for RELOAD and Attach for applications confused. So, I choked down my urge to tell them they should just read the document more carefully and concluded that it actaully was necessary to avoid confusion. [14:29:15] (That's my rewrite) [14:29:34] Bruce: this needs a cost analysis [14:29:43] Staffan Kerker leaves the room [14:29:45] Haipeng and Bruce talk about the costs of DTLS handshake [14:30:47] people are chuckling [14:31:16] David is currently reviewing the document; he thinks the technical things are getting there, but the complexity is making the presentation difficult [14:32:31] A lot of the behavior for each method is common; when we think about this, can we avoid explosion and yet keep things clear? [14:32:47] Cullen notes he was on the side of merging [14:33:07] It's a matter of taste, but we need to pick one description [14:33:43] well, I'm happy to live with one as long as Cullen and David agree to tell them that they're idiots when they don't understand it. [14:33:59] Who is "them" in the statement above? [14:34:09] implementors? [14:34:39] Now on slide 12 [14:35:31] looking for open tech issues, high-level editorial feedback [14:35:35] Will release one for each [14:35:59] rababy joins the room [14:36:09] procedural comments from chairs: two would be great, 3 will flabbergast [14:38:08] Asking for full-cover to-cover review from 4 folks for September 18th draft. [14:38:47] Lucy Yao from Huawei, [14:38:48] j9jgm [14:38:51] Ning Yong [14:38:53] Apparently it's a highly powerful sedative. [14:38:53] Theo joins the room [14:39:18] Two more will be trapped using humane methods [14:39:28] cullen: http://www.flickr.com/photos/larse/3749422918/sizes/l/ [14:39:31] Brian will be one of the pure editorial methods [14:40:47] Wolfgang Beck joins the room [14:41:03] rababy leaves the room: Computer went to sleep [14:42:36] Now on Disagnostics draft "Overview of the dianostics draft" slide [14:44:14] Cullen asks why new methods? [14:44:26] The meeting in Minneapolis requested these, rather than parameterize existing methods. [14:46:17] Bruce argues that these provide is atomicity [14:46:44] Cullen agrees that this is valuable [14:48:14] Simon Perreault leaves the room [14:49:06] Now on IP layer hops [14:50:08] Hmm. Are we building a new routing layer? TCP over p2psip over IP? [14:51:03] Bruce says can we change underlay to overlay link? [14:51:09] oej: is that for the mic? [14:52:14] Bruce has concerns that this can be implemented on the majority of common stacks [14:52:47] (this is the IP ttl modification question) [14:53:41] Now on Route Log [14:54:24] /hmm doesn't Bonjour or LMMNR set the IP TTL? [14:55:03] This breaks the signature. [14:55:13] Cullen suggest that moving the log into the payload avoids fragmentation issue [14:55:17] For the mic? [14:55:38] Nah. [14:56:12] Ted: no, just a side comment from a bystander sitting down in the room. But thanks for asking :-) [14:56:50] oej leaves the room [14:57:15] Russel Wang: instead of defining specific diagnostic methods for reload, encapsulating snmp into reload header [14:58:06] dmw.winter joins the room [14:58:15] +1 on the batter status [14:58:29] Magnus Bergman leaves the room [14:58:29] oops battery, not batter [15:00:24] I can't find anything that indicates that normal users can't call setsockopt(sock, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl)) [15:01:08] OTOH, I can't find anything that lets you read the TTL out of a received packet [15:02:07] AD kills break for lack of cookies [15:02:23] So, I'm sitting here at home with a bunch of cookies Cullen's mom made last night [15:02:24] that was uh, not the AD, [15:02:26] I'll have one for you. [15:02:32] Take that as my chennleing EKR [15:02:32] thanks ekr! [15:02:34] You're a prince [15:02:50] p2psip security overview now up [15:02:57] now on History slide [15:03:05] (no slide numbers) [15:03:59] Now on "Took out security requirements" [15:04:18] Did not change the name because of timing [15:04:40] Now on Document content [15:05:14] Thomas Stach leaves the room [15:05:30] Now on Adoption? [15:05:44] mic: I'm sort of concerned by how generic this is. [15:05:45] Show of hands for readers: a few [15:05:51] 3 peopel had read it [15:06:28] IT seems almost totally detached from RELOAD as it currently is. [15:07:57] Oh, wait. I figured it out. You use recvmsg, and then iterate the cmsghdrs until you find the one with a cmsg_type of IP_TTL [15:08:09] waiting by mic, ekr [15:08:09] So it looks like there's no problem doing the TTL trick on either end [15:09:16] okay heading back [15:09:20] mic: I think Cullen has sort of hit my concern. This seems like a security analysis of some hypothetical unspecified protocol that sort of is vaguely connected to P2PSIP. But we're way beyond that point. We've got a specific architecture and protocol and so it's odd to have a security analysis that's unconnected to that. [15:09:27] nice [15:09:43] timing that is [15:09:46] (yeah) [15:10:33] MING joins the room [15:10:45] stefan.sayer leaves the room [15:10:51] who is speaking? [15:11:01] Sohel Khan [15:11:04] thanks! [15:12:22] Bruce at the mic,saying this is twixt and tween [15:12:45] Mark Thompson leaves the room [15:14:36] hscholz joins the room [15:14:57] mic: If people want to have a general tutorial on P2P security, that's fine, then then it needs to have no normative content. [15:15:53] It's full of shoulds [15:15:55] erikmartinfranzen leaves the room [15:16:29] Requesting hum on adoption [15:16:56] mic: so every RFC 2119 SHOULD/MUST will be removed? [15:17:01] hscholz leaves the room [15:17:22] ekr: the previous nods seemed to agree with that [15:17:27] Do you still want that at the mic? [15:17:33] Well, I'd like it to be very clear. [15:17:41] okay [15:19:04] Consensus to adopt called from hums [15:19:56] Hendrik Scholz joins the room [15:19:59] Now on relay draft, ning zong presenting [15:20:05] Now on "history" slide [15:22:44] Now on rpr flows [15:26:18] Now on open issue [15:31:01] MING leaves the room [15:31:16] mic: I'd like to understand what the perfromance of this is in heterogeneous networks. If you can do SRR say 40% of the time, then doesn't this create significant additional latency for the remaining 60% of request/response pairs? Either that, or we're down some parallel ICE-type rathole. [15:32:20] To elaborate: you're going to offer it with the other 60% but it's going to fail, right? [15:32:43] KaiFischer leaves the room [15:33:38] still in line ekr [15:33:49] sure. [15:34:30] That should say DRR, obviously. [15:36:17] nah. [15:38:45] wave [15:38:50] w/w [15:40:10] Now on Next step [15:40:21] Adam Roach leaves the room: Computer went to sleep [15:40:24] RjS: don't follow your comment? Do you need something? [15:40:36] Ted: w/w == wrong window [15:40:40] mic: can that get repeated? I can't hear [15:40:44] Gabriel Hege leaves the room [15:40:49] ah, thanks [15:41:02] mic: I'm seeing a lot of skepticism about whether this is a good idea, let alone maturity [15:42:38] I'm hunkered by the mic, ekr [15:43:08] you can't make a real argument from here. I'll just hum :) [15:43:12] Cullen asks Bruce to repeat, resummarize [15:43:22] I'll try, if you want [15:44:46] mic: Adopting something as a WG document is a commitment to work on it. If there are real concerns about whether this is viable, then we should answer those question before making that commitment. [15:45:43] Gabriel Hege joins the room [15:50:59] hum: no [15:50:59] Call is no consensus [15:51:13] and now I know how much latency there is :) [15:51:41] Sorry [15:52:03] it's not you. It's the audio [15:54:15] mlepinski leaves the room [15:55:40] Adam Roach joins the room [15:56:39] I have to say that the chair's previous estimate on our departure was overly optimistic. /me misses the break now. [15:57:05] shamus leaves the room [15:57:14] tomkri leaves the room [15:57:16] Bruce leaves the room [15:57:16] we're done [15:57:17] RjS leaves the room [15:57:19] Cullen Jennings leaves the room [15:57:21] Ted(with knees) leaves the room [15:57:30] Gabriel Hege leaves the room [15:57:42] martin.thomson leaves the room [15:57:49] jani_h leaves the room: offline [15:58:01] Bob Penfield leaves the room [15:58:10] nils leaves the room [15:58:15] John.Elwell leaves the room [15:58:15] lifenghua leaves the room [15:58:17] metricamerica leaves the room [15:58:24] Wolfgang Beck leaves the room [15:58:36] suzukisn leaves the room [15:58:51] Hendrik Scholz leaves the room [15:59:13] spencerdawkins leaves the room [15:59:18] Wow. It's really amazing how well you can hear the "hallway conversations" that happen after the meeting is done [15:59:28] (on the audio feed) [15:59:48] Magnus Bergman joins the room [16:00:18] mlm.michael.miller leaves the room [16:00:36] Theo leaves the room: Computer went to sleep [16:01:05] vidya leaves the room [16:05:55] Magnus Bergman leaves the room [16:21:42] Hendrik Scholz joins the room [16:43:39] dmw.winter leaves the room [16:49:43] Hendrik Scholz leaves the room [17:07:47] Glenn Parsons leaves the room [18:14:18] ekr leaves the room [21:18:01] RjS joins the room [21:24:09] Adam Roach leaves the room [21:31:10] Magnus Bergman joins the room [21:53:18] Hendrik Scholz joins the room [22:06:51] Magnus Bergman leaves the room [22:06:51] Hendrik Scholz leaves the room [22:06:51] Magnus Bergman joins the room [22:08:35] Magnus Bergman leaves the room