Multipath TCP (MPTCP) Meeting : IETF81, Wednesday July 27, 2011, 0900-11:30 Location : Quebec, 204B Chairs : Philip Eardley Yoshifumi Nishida AD : Wesley Eddy URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Andrew McGregor ----------------------------------------------------------------------------- 1: Introduction - Chairs Congestion Control went through WGLC Protocol spec addressed detailed reviews and need to finalize open issue in this meeting. Thinking about going WGLC ----------------------------------------------------------------------------- 2: API update - Michael Scharf Don't have further plan for update unless there's any issue. (No comment) Doc is ready for last call. ----------------------------------------------------------------------------- 3: Congestion control update - Mark Handley Minor comments from IESG and David Black have been solved. Got approval for publication. ----------------------------------------------------------------------------- 4: Protocol update and discussion of open issues - Mark Handley Section 2, which describes protocol overview has been completely re-written. It would be great if someone can review this part to see if it's comprehensive. Security negotiation has been changed. We use 3rd packets of 3 way handshake to send a key. Tim Shepard: If the packet is lost? It might be complicated. Janardhan Iyengar: How about B echoing back the received options? Mark: The issue is how to trigger stopping option sends. Costin Raiciu (from Jabber): This issue is already addressed in the draft. Mark: We will double-check if the issue is covered and resolve if required. Open issue: Fallback mode. When mptcp finds something is messed up by middleboxes, it should fallback. Andrew McGregor: Isn't that OK? Can't you just say, if the ACKs haven't arrived, oh well, RST it. Mark: What we haven't found yet is how to do this reliably. Georg Hampel: The draft says that there's no more multipath signalling in fallback. So you can't use mptcp options. Mark: So, the only resolution seems to be that if you end up with un-ACKed data, you lose. Costin: You have signalling in the SYNs Mark: Which gives you a way out, if that is possible. Georg: I have a proposal for how to cover this later. Mark: It probably isn't worth trying to optimize this case. Might not be able to optimize. Another open issue: What to do if all subflows are in time out? When we should give up? Phil: You're saying that is an implementation specific heuristic? Mark: I don't think protocol spec doesn't have to specify this kind of behavior. Phil: Plan is, get these three issues resolved on the list, give it a week or so, and WGLC it. Experiments on "Is MPTCP deployable?" Georg: You can't name service providers or enterprises, to what extent are the harmful boxes installed in providers vs enterprises? Mark: Cellular providers have more, but no monopoly. We can't claim this to be completely representative. ----------------------------------------------------------------------------- 5. Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks – Georg Hampel Mark: Best path probably has lowest energy per byte Georg: If you have money or energy to burn, you might not care Mark: About Proxy. One part of me is revolted by supporting transparent proxies explicitly, and we should support them. Calling the flag I_AM_A_PROXY is more explicit. Andrew: I agree there are always proxy devices "there" there are good features here (is it important to tag this as "min" complexity, images are getting big for this part of the stack) Georg: How about recv buffer reduction? Andrew: that's a good idea Mark: I'm not totally convinced that buffer reduction is necessarily. You have to buffer data in the kernel anyway until missing packet arrives. Georg: It's implementation complexity. Mark: I guess I don't consider it important requirement. Costin: Receive buffer reduction is orthogonal to implementation complexity. Mark: The other question, if you're in path selection mode, do you get the right behaviour over mobile networks. You might be able to tell from signal strength etc. But, it can be risky. It might be congested. I can't easily predict from wireless if it's decent, I have to actually try it. Georg: The signal is not necessarily indicative, could have other variables. Sending small burst. Andrew: Wifi links have to train up, which can take a few hundred packets to infer performance. David: I have in mind a satellite PEP setup rather than Wifi, where RTT could be radically different. There might be different use cases. Mark: Our intuition is that you should only use one path most of the time, but you want to transition make-before-break and do a soft transition. You need to get the links adequately probed. Gerge: Both of our points are based on speculation, we need to know how well you do if you shorten the overlap Costin: the paper assumed there is an oracle that knows the best path that chooses the best path. yes: 15% compared to an optimal path selection algorithm that can't be achieved in practice Gerge: Yes, we still don't know how to pick the best path. But, you might want to mitigate hol blocking by path selection. Costin: you can also have redundant data if you want to probe and avoid hol blocking Mark: The spec does not prohibit you sending data on multiple paths. It's implementation question how to use it. Phil: We've had quite a lot of discussion now on heuristic stuff, how you might make this work in practice. It would be nice to have more experiments. My impression is that BTO doesn't seem to gain very much Mark: We would like to know if there something we should add before IESG. Andrew: Suggest not doing bulk transfer optimization, it could be really expensive for little gain. Andrew: Very much in favour of proxy flags, they're everywhere Mark: I am in favour of adding a bit to support transparent proxies, 1) address of proxy 2) remote supports mptcp - could decide based on this Andrew: It can be a content inspecting firewall that just wants to do its job Michio: Currently, there's no such middle box to handle MPTCP options. You will have to implement something to investigate this. Gorry: There are proxies that need to inform L2 what is going on and teak transport. The flag might be useful. Andrew: Could have network architectures that wouldn't otherwise work that way. Mark: As summary We should probably try to address this before we move the protocol spec forward. Phil: Would like to see people get together in the remainder of the week. Andrew: I think the bottom three lines of the slide are OK, up to naming. ----------------------------------------------------------------------------- 6: Call for news on Implementations Linux version being updated as http://mptcpinfo.ucl.ac.be, also for Nokia N900 & Android Nexus-one George: We're in progress on 'lightweight' implementation Tim: Implementation is not SMP capable yet?, does anyone know if it is fixed? (No response) (It should work but will need more tests. by Christoph) Sebastien Roy: Oracle are working on a prototype in Solaris. Don't know if it can be released yet. ----------------------------------------------------------------------------- 7: Discussion on future of WG Discussion last time (roughly) concluded that we pause for experiments & usage: WG hears about implementations, heuristics etc; hears about investigations on possible extensions; not do any protocol standards work. Re-charter in ~ 1year when understand better what the needs are & where the energy is (No comments) Chairs will work with AD on re-chartering text, when the current charter is done.