[06:55:00] yoshifumi.nishida joins the room [08:00:05] yoshifumi.nishida leaves the room [08:15:59] iljitsch joins the room [08:16:59] all the audio is dead [08:17:08] (and I don't know which channel we're on) [08:19:13] WUQIAN joins the room [08:19:32] WUQIAN leaves the room [08:22:23] tmonca joins the room [08:24:46] gorryf joins the room [08:30:17] let me know when things start so I can go hunt for the right audio channel (a few of them seem to be working again) [08:32:30] Let me know if you work out which one it is... [08:33:46] Andrew McGregor joins the room [08:33:57] if someone starts talking I can try... [08:34:15] I'm on channel 4 now but nothing happening yet [08:34:47] Ruri Hiromi joins the room [08:35:56] karen.s.seo joins the room [08:36:42] swb joins the room [08:37:15] I'm going to try to take notes and paste them here about once a minute [08:37:20] mlepinski joins the room [08:37:37] If we had google wave we could all edit the meeting notes in real time, without need for jabber :-) [08:37:39] Lars joins the room [08:37:41] I like audio better :-0 [08:37:54] i meant: :-) [08:37:58] audio is great, but not when I'm trying to monitor several rooms [08:38:04] @@ [08:38:26] Iljitsch, where are you? [08:38:31] jlcJohn joins the room [08:38:33] @home [08:38:38] fabinader joins the room [08:38:45] are the audio files available immediately now? [08:38:49] ꈲ joins the room [08:38:50] don't know [08:38:50] that would help A LOT [08:39:05] it's my day off today... [08:39:15] I think they become available after a few hours... [08:39:32] used to be weeks [08:39:38] karen.s.seo leaves the room [08:39:39] Lars says there will be live audio [08:39:45] by then I don't care anymore [08:39:54] does he know the channel? [08:39:54] The problem is the tools agenda only lists 1 audio stream (the one in Cammelia) [08:40:23] IM Lars, he's on [08:40:40] we're starting [08:40:43] welcome [08:40:56] it's channel 8 [08:41:03] the links are back on the tools page now [08:41:06] just worked that out. Thanks! [08:41:07] intros [08:41:37] Philip: welcome Introductions Andrew will also scribe [08:41:42] Wes joins the room [08:42:56] Note Well Agenda [08:43:32] Concentrate on the architecture [08:43:48] NB WEdnesday 3:00 implementors meeting [08:44:30] I will not just write down the slides, but I will post what slide they are on and any discussion that is not on the slide [08:44:34] CHENGANG joins the room [08:44:36] slide: What is MPTCP [08:45:09] sftcd joins the room [08:45:16] Slide: what is the MPTCP WG doing [08:45:40] Slide: assumptions. We have to live within some constraints. [08:45:51] Six work items to make progress on. [08:46:31] Schedule [08:46:42] arifumi joins the room [08:47:22] propose wg last call on architecture in Feb, allowing revision for ietf 77 [08:47:24] calvin joins the room [08:48:26] March 2011 congestion control - evaluate alternatives [08:48:43] Switching to Jana Iyengar, architecture slides [08:49:33] draft-ford-mptcp-architecture-00 [08:49:49] resnick joins the room [08:49:52] making the mike work [08:50:32] Trying to do a few things in this architecture document. Recommend that you take a look at it. -00, extremely drafty form. [08:51:21] High order bit: Many high level decisions can apply to any multipath transport. Lay out the design space. Then show how MPTCP specifically fit into this design space. [08:52:00] goals slide [08:52:27] shikob joins the room [08:52:37] Goals slide. Once you have 1-3, what information needs to be exchanged (4). Then put MPTCP in this framework. [08:52:46] 1a slide [08:53:54] csp joins the room [08:53:58] question: what does "compatible with middleboxes" mean? work through any and all of them??? [08:54:07] Performance and efficiency goals. [08:54:21] different paths though different middleboxes, or all paths through the same? [08:54:34] He says ask when he's done. I'll try to remember. [08:54:58] yoshifumi.nishida joins the room [08:55:42] functional decomposition slide [08:57:21] Funcitonal decomposition slide. Need to maintain backward compatibility with the app and with the network. One component handles network-oriented functions and the other handles semantic functions. The network-oriented flow functions are of interest to middleboxes and you don't want to change those. Also avoid changing interface to apps. [08:57:56] This decomposition allows us to understand where to do the work. See graphic. Also allows where to put security functions. [08:58:31] Pete Resnick: This is all in the draft, and assuming we have all read the draft you could go a lot faster. [08:58:50] becarpenter joins the room [08:59:13] Discuss protocol design considerations. [08:59:48] Discuss interfaces among components and implementation suggestions. [09:00:31] MPS/PM implementation architecture. [09:01:16] MPS/PM implementation architecture. PM is path manager. MPS is multipath scheduler. [09:01:43] I feel discriminated against, the non-jabber people don't have to wait till the end... [09:02:20] shamus joins the room [09:02:23] Hui Deng: Today most multipath hosts use a kind of connection manager. How does that relate to path management? Jana: lets Alan Ford speak. Alan: Yes, the split like this is a way we could get a connection manager interfacing with little effort. Hui: so interface between CM and scheduler ... he'll comment later. [09:02:44] I was trying to make the end get here faster. :-) [09:02:58] but this will only take a second :-) [09:03:35] Example MPS/PM interface. Discuss how MPTCP drafts fit in this multipath arch framework. [09:04:18] High-level MPTCP design in the architecture. [09:04:20] abaire joins the room [09:04:46] karen.s.seo joins the room [09:05:27] High-level MPTCP design in the architecture. Doing this mapping also verifies implementation against design decisions. Design decisions - not exhaustive list. [09:06:18] Where next? (1) Can separate this work into general MP transport architecture. (2) High-level design decisions for a MPTCP. (3) Analysis of MPTCP drafts' detailed design against architectural goals and high level design. [09:06:22] mathis joins the room [09:06:39] Wants feedback on document goals and is it a good start? Right now it's rough. [09:07:22] Iljitsch: you are discriminated against [09:07:25] Who has read the document? [09:08:06] Iljitsch, your question was just asked [09:08:11] thanks [09:08:30] the answer is "yes" they can go through different middleboxes [09:08:40] shamus leaves the room [09:08:47] (presuming that works sanely with those particular middleboxen) [09:08:47] magnus joins the room [09:08:58] ok so that means this wg is going to spend 75% of its time on NAT and firewall traversal (not a question) [09:09:01] If you have a question please phrase it. [09:09:50] we don't _have_ to work through middleboxes (except the primary path!) if we don't want to, unlike other protocols this doesn't render the communication non-working [09:10:07] Pete REsnick: what about failover. Can understand failover in mobility sense but what about here. What if all paths fail momentarily and a new path shows up quickly thereafter, like handoff. In that kind of failure case, are you going to be able to recover back? That would be a wonderful goal. Jana: this is a decision the group needs to make. He's trying to document these decisions. [09:11:14] What should we do about design questions? Just document them? yes unless brief responses. Costin: current thinking is similar to TCP. When get a timeout on a subflow, just move to a subflow where you can transmit. If TCP backs up enough, then have no interface over which to send data, the interface is dead. [09:12:26] Tim Shephard: if SSH connection to somewhere and no data to send, it's idle. All my interfaces go away, and later get a new interface with new address, can session continue? Costin: yes it can. Jana: it's a great goal to have as well. [09:13:25] Marcelo Bagnulo: With the behavior described by Costin, we can support mobility but behaving the way TCP does today. Don't get fully into the mobility area but have behaviors that can easily be extended to support mobility, that's good. [09:14:02] Mark Handley: in response to Tim: yes, like to be able to resume, no technical reason why can't do it, modulo reasonable security story. If get that, no issue with protocol supporting it. [09:14:22] Marcelo: security story is the same? Mark: in principle very similar. [09:15:48] Hui Deng: interaction with MIF. Coordinate about connection manager etc. Lars Eggert: thinks he understands connection manager -- you are associated with a WiFi interface, do you want to use it, and pick that one as _the_ interface. If you want to do MPTCP on that phone might want to use more than one so need to change CM. [09:16:39] Hui: path manager could get policy from connection manager, could interwork (I think that's what he said) [09:17:32] Jana: a flow manager manages a flow. If you use a couple of instances of connection manager that's fine ... Costin: there's an implication that the CM gives you the user-defined policy, which path etc. [09:19:24] Jana: how will policy impact scheduling or choice of path? Mark Handley: There's nothing in the protocol that reflects policy but we do need a way to tell a sender we don't want to use a particular path at a particular moment. We have given thought to it but not sufficient. Murari from Microsoft: Look carefully at scope. Assume that routing layer is handling policy of its own. Maybe incorporate policy there. [09:20:15] Hui: need to coordinate before get too deep. [09:20:56] Jana: gaps or stuff that shouldn't be in draft? Any other high-level design decisions? [09:21:21] Hui: consider what is already happening today. [09:21:23] Done with Jane [09:21:25] Jana [09:21:26] sorry [09:21:29] phew [09:21:59] Alan Ford, multi-addressed multipath TCP [09:22:14] draft-ford-mptcp-multiaddressed-02 [09:22:47] Objectives [09:23:54] basic scenario: throughput [09:24:17] sftcd leaves the room [09:24:53] mptcp operation [09:24:59] mptcp example [09:25:20] session init [09:27:26] nnnshin joins the room [09:27:47] Need for address signaling - example. [09:28:35] I think his firewall example is strange but probably because I don't understand it. [09:28:57] Firewall doesn't allow incoming SYN, so signal and make it outgoing. [09:29:47] looks like context-based access control. [09:29:51] Pete Resnick: can retransmit failures. If using a new path MUST also retransmit on original for continuity. Clarification: must retransmit on it if you intend to continue to use it. [09:30:03] andrew: but then it's unidirectional. [09:30:11] now on Data Sequence Numbering [09:30:21] No, it's a normal TCP, you just can't initiate from outside the firewall [09:30:31] aha, the light dawns [09:30:41] I have extreme concerns about carrying addresses as payload, ever [09:31:15] Data Sequence Numbering. Need not be in every packet. Lars: what if seq # is lost? To be sorted out. [09:31:25] arifumi leaves the room [09:31:35] Closing connection [09:31:43] Glenn Parsons joins the room [09:32:18] Security and threats [09:33:24] Security and threats ... Magnus: as he sees it as soon as you can be on-path for any flow, you can hijack the entire session. Alan: you would have to set up a separate subflow yourself. [09:33:24] PasiS joins the room [09:33:44] What if the second address announced as payload by the peer is a NATed one? Am I the only one who didn got the point? [09:33:44] Marcelo: this is basically what the third presentation is about. [09:34:09] we'll try to fit that in later, he's gone on [09:34:12] Open Issues [09:34:37] csp leaves the room [09:34:52] Not a mic question, just checking if Iḿ the only one. [09:35:12] I think there are certainly problems there but I haven't stared at it yet [09:35:57] Jana Iyengar: option for data sequence numbers: do you need an option for this or can it be part of the TCP "payload"? Alan: would be like TLS, and that's not what they want to do. Jana: why not? Costin: why is it a good thing? Jana: you're using less option space that way. [09:36:17] @fabinader: I think the answer is the same as the firewall thing: [09:36:33] Mark: if you put it in the data you're vulnerable to anyone who resegments the data. [09:36:48] You'd have to start from the other side. [09:36:57] pete: re nats? [09:37:23] Tim Shephard: that's only true if you put it in the data in particular ways, it's possible to avoid that vulnerability. [09:39:01] Stuart Cheshire: add address option: this is to identify the endpoints after packet has gone through NAT? Alan: it's to say "I have another address". May not work if go through NAT. Stuart: if every host in the world thinks it's 10.0.0.2, does it work? Alan: No. Stuart: you have a problem. Costin: The answer to that is in Host Routing presentation, later. [09:39:12] ha [09:39:18] why not use STUN? [09:39:35] I mean if we want to work through middleboxes we should do it right. [09:39:51] Take the HIP NAT Traversal approach? [09:40:39] Scott: but your packets might get to the wrong host. Stuart: and it looks like it's the right host because the address matches. Alan: need good security. [09:42:11] Juan-Carlos Zúñiga: single-ended? Philip: Not now. [09:42:35] yes, that makes sense: REQUIRE changes on both ends, regardless of whether it's needed... :-) [09:42:56] gee, Iljitsch, I'm shocked that you should feel that awy [09:42:57] way [09:43:38] Matt Mathis: sequence numbers need to be reliably delivered. Can collide with sequence numbers used by SACK. [09:43:40] well I can understand some of the logic that came up with the charter, but saying it like "it has to change both ends" makes little sense... [09:44:06] Martin Stiemerling: have you tested that the TCP option survives NATs/firewalls? Alan: some tests underway. [09:44:45] Lars Eggert: paper in 2004 looked at whether you could stick unknown things in TCP packets. 0.4% failed. [09:45:17] Was that in TCP OPTIONS ? [09:45:20] Murari from Microsoft: don't give up on one-ended approach that early. Incremental deployment is attractive, especially if we can get it to work [09:45:38] Dan Wing: please show up at BEHAVE and GROW [09:45:50] Done with Alan [09:45:53] did dan say "grow bof"? [09:46:07] Yes, GROW and BEHAVE - "please show up" [09:46:11] oh wait [09:46:13] I guess he did not [09:46:20] did he? [09:46:39] Costin, linked congestion control ================================== [09:46:56] 0.2% of connections fail [09:46:58] http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps [09:47:02] because grow is a well established wg... [09:47:10] no, he means GROBJ [09:47:32] aha [09:47:36] that's the referral bof [09:47:42] yep [09:47:50] slide: multipath TCP at work [09:48:15] Lars: I was co-author for a little while but ran out of time [09:48:26] slide: Aims [09:49:30] goal 3 implies resource pooling [09:50:06] can we use existing algorithms? [09:51:50] Ted Hardie: if go back to goals, this indicates need some time scale in which you're going to meet these goals. A flappy algorithm would meet the goals in some time scales. Sometimes an app will be happy with a poor algorithm. [09:51:59] Linked increases algorithm [09:54:08] To get throughput we want, tune alpha [09:55:13] costin: can't use the current value of the congestion window as an estimation of the loss rate, because it changes all the time. you need to use the slow start threshold for this. [09:55:24] To get throughput we want, tune alpha. Don't have to compute alpha on each ack. Can compute it when cwnd grows by one mss. [09:56:03] danwing joins the room [09:56:05] did you hear that? [09:56:11] iljitsch? [09:56:18] csp joins the room [09:56:19] yes [09:56:49] thanks [09:57:29] Aaron Falk joins the room [09:57:33] slide: ... implemented in [09:58:12] in overwhelming majority of cases, get throughput within 10% of best TCP on best path. Sufficiently well-behaved to be deployed. [09:58:19] experiment: throughput [09:58:40] Aaron Falk leaves the room [10:01:19] resource pooling experiment [10:02:12] csp leaves the room [10:02:54] Tim Shephard: small comment on resource pooling experiment slide ... compared to "perfect". Why is "perfect" on there? [10:04:53] We are aware that the current dynamics are not ideal but if we want to work in the current Internet we have to be fair. To adjust fairness, change alpha. Tim: need to adjust use of paths according to policy. A: Yes. [10:05:24] Michael Luby on bottleneck: with combination of two flows, do they get same throughput as if had single path? Yes. [10:05:43] how many have read this draft? A few. Previous draft, "a few more". [10:06:33] João Taveira Araújo: I was busy typing his name so I missed the comment. [10:06:45] Done. Next up is Marcelo. [10:06:58] It seemed to be to do with whether the l;ack of precision made things worse as you got more interfaces [10:07:57] (what about different paths having different MTUs, btw?) [10:08:16] Matt Mathis: algorithm in BSD code fails if window size in packets is bigger than MTU. Costin: multipath is more susceptible, so they fixed it. Round up by 1. Also look at modulo left by division and randomly increase by 1. A little bit of fixed point. [10:08:34] Marcelo Bagnulo, Threat Analysis =================================== [10:08:36] see slides [10:08:45] shikob leaves the room [10:11:04] There is a difference between this and work in MIP or Shim6. In those the whole identity of the host is in danger. In this case it's only a single connection. [10:11:45] someone else please jabber for a few minutes ... assuming something worth jabbering comes up. Be right back. [10:12:03] arifumi joins the room [10:13:18] next slide [10:13:26] MPTCP (cont) [10:13:55] mathis leaves the room [10:14:17] next slide [10:14:19] scenario [10:14:26] next slide [10:14:29] redirection attacks [10:14:43] arifumi leaves the room [10:14:52] next slide [10:14:53] flooding [10:15:32] swb back [10:17:24] next slide [10:17:27] additional threat [10:17:44] flooding ... [10:18:37] Lars: flooding attack not possible with proposed ... A: Yes. How is this prevented in spec today? They do a three-way handshake. That's standard. But it wasn't there to avoid attack, it was there to traverse NAT. [10:19:03] connection hijacking [10:19:38] calvin leaves the room [10:20:23] csp joins the room [10:20:55] He's not speaking about the current proposal, just making general statements about threats [10:21:16] mlepinski leaves the room [10:21:51] Hijacking and MPTCP with cookie-based security. Time-shifted/future attacks: attacker needs to be on path when cookie is exchanged, then can move away. [10:23:28] Current TCP is not vulnerable to time-shifted attacks. Apologizes for going fast. How many read draft? Not many. --> please read it. [10:24:00] becarpenter leaves the room [10:24:14] Michael Scharf: draft-scharf-mptcp-api [10:24:14] sk joins the room [10:24:17] =------------------------------------- [10:24:21] TPLUNKE joins the room [10:25:23] currently very incomplete, goal is to make you aware and get feedback. [10:26:14] impact on performance [10:27:19] implications on existing interfaces [10:28:17] iljitsch leaves the room [10:28:22] open issues [10:29:16] abaire leaves the room [10:29:17] anthony.baire joins the room [10:29:32] Martin Stiemerling: will this be a completely different socket from tcp? Completely backward compatible so standard socket. [10:30:48] Joe Touch: implications on existing interfaces. Idea of returning "first" address pair ... there is no order. "going down with the ship" scenario. [10:32:03] Joe Touch: implications on existing interfaces. Idea of returning "first" address pair ... there is no order. "going down with the ship" scenario. Costin: Joe, biggest app that would break was BGP (if don't "go down with the ship") and Mark's presentation shows you how to make BGP work. Joe: every app that uses any sort of identification between endpoints, if IP address goes away and connection keeps going, it doesn't make sense. [10:32:21] Costin: another host won't get your connection, that's impossible. [10:33:04] Magnus: Joe is concerned about cases that bind connections to certain hosts at certain time. [10:33:38] Murali from Microsoft: agrees with Joe. [10:34:59] Hui Deng: cannot modify socket in hosting vendors. They have several layers above and below socket. [10:35:20] Taking Joe's issue to the list. [10:35:35] Mark Handley: routing of outgoing packets for mp-tcp. draft-handley-mptcp-routing-00. --------------------------------------------------------- [10:35:54] How to make sure the packets go the right direction to get diversity. [10:36:39] iljitsch joins the room [10:37:20] Sites don't address sites with multiple addresses. [10:38:09] For multipath tcp you want essentially strong host behavior. [10:38:09] for the one-ended you need the weak host behavior... [10:38:23] I was wondering if you were going to speak up ... you came into the room at just the right time [10:38:38] it's not entirely true that weak doesn't work for the multiaddress solution, it just makes it less optimal [10:38:55] Host must have a route to the dest via a nexthop router. Do longest prefix match. [10:40:59] Among those with longest prefix, source address dictates which interface to use. Among routes on that interface, pick route with lowest metric. Maybe choose interface by source address first. Arguments in each direction. Mark likes longest prefix first. [10:41:37] TPLUNKE leaves the room [10:42:12] Lorenzo Vicisano: which first? May have different policies on different ISPs. If do source first, can have separate routing tables. Mark: if mobile host then longest prefix might not work for you, but if you're a server and you have some controls, longest match can work best for you. [10:45:07] Yuri Ismailov, Ericsson: Use case: send HTTP GET on one path. If decide to split download over multiple connections, does that mean 4 more sockets? Mark: no one socket, multiple subflows. Costin: the ACCEPT on the additional subflows is done implicitly, don't need listen on socket to accept them. Costin: this is not against TCP behavior, the end that does the active open ... --> taken to list. [10:46:28] Lars leaves the room [10:46:35] Julien Laganier: if using IPv6 don't know which interface ... Mark: for IPv6 need to be able to bind route to subnet address ... (lost it) [10:46:50] resnick leaves the room [10:46:55] nnnshin leaves the room [10:47:07] calvin joins the room [10:47:10] calvin leaves the room [10:47:21] csp leaves the room [10:47:44] shikob joins the room [10:47:58] magnus leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [10:48:05] shikob leaves the room [10:48:44] yoshifumi.nishida leaves the room [10:48:58] Wes leaves the room [10:48:58] Matt Mathis: has this already been solved in a different space? Thinks using multi-path TCP is not that important. Most cases just need one flow. Do liveness tests on all paths and for the next connection just pick a good one. Policy may overwhelm multipathing. [10:49:13] Ruri Hiromi leaves the room [10:49:16] ok bye [10:49:17] danwing leaves the room [10:49:17] swb leaves the room [10:49:35] karen.s.seo leaves the room [10:49:43] PasiS leaves the room [10:49:49] tmonca leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [10:50:02] sk leaves the room [10:50:35] CHENGANG leaves the room [10:51:04] fabinader leaves the room [10:53:59] Andrew McGregor leaves the room [10:56:56] iljitsch leaves the room [10:59:18] Glenn Parsons leaves the room [11:00:31] anthony.baire leaves the room [11:27:21] Ruri Hiromi joins the room [11:28:19] Ruri Hiromi leaves the room [11:29:16] ꈲ leaves the room [11:34:08] gorryf leaves the room [14:32:56] PasiS joins the room [14:33:03] PasiS leaves the room [14:45:14] Andrew McGregor joins the room [14:45:43] Andrew McGregor leaves the room [15:47:19] Lars joins the room [15:50:21] Lars leaves the room