Multipath TCP (MPTCP) Meeting : IETF, Monday November 2nd, 2015, 9:00-11:30 Location : Webex Chairs : Philip Eardley Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/mptcp/ Note Taker : Chirstoph Paasch Attendees : Alan Ford, Andreas Ripke, Christoph Paasch, Costin Raiciu, Geoff Ladwig, Matt Sargent, Mirja Kuehlewind, Olivier Bonaventure, Philip Eardley, Yoshifumi Nishida --------------------------------------------------------------------------- 1: Intro - Chairs --------------------------------------------------------------------------- 2: Application Layer authentication for Multipath TCP - Alan Ford Yoshifumi Nishida: In case of load balancer, server should select the token B that can identify the route to it. But, client can select token A randomly? Alan: Yes, Token A can be entirely random. Yoshi: When mptcp stack try to start a new flow, but key is not ready, what will happen? Alan: It can only create a new subflow once key are exchanged at application layer Yoshi: So, mptcp stack has to wait until key comes from application layer Alan: Yes. That's a limitation described in the draft. We assume the application aware of the limitation and choose to use it when it's appropriate Costin Raicu: Does this mean we have to do TLS handshake on a single subflow and then we can use other subflows? Alan: Right. We are not saying that this solves all the problems. We solve use cases where this is appropriate costs. Christoph Paasch: mptcp only allows to create the first flow after the first data is acknowledged. We won't be delayed for establishment of new subflows for very long. Costin: TLS handshake is also data to mptcp. It doesn't have to be application layer. It could need couple of RTTs to get keys from apps. Phil: So, people like this? We should include it? Costin: I like it, but it's completely independent from bumping version number. If we keep the version number, it's a good idea. But, not enough for new version number. Alan: Bumping version number was already accepted by the WG. Costin: It's not big enough to break the current deployment. Yoshi: 6824bis has new handshake mechanism. If we keep the version number, the stack has to support both handshake mechanisms. The implementation become complex. Costin: We have two solutions to solve load balancing issue. Both works. Why do we want to change the version number for this? Christoph: In case of stateless server, mptcp has to fallback to tcp due to the 3rd ACk lost, while TCP doesn't have the issue. The impact is not small. I think this is worth it. Costin: Can you provide some data? Christoph: I don't have data at this moment. I can try. Phil: tcpinc has a similar proposal. Alan: We might do some optimization with it. I need more analysis before Berlin. Olivier Bonaventure: Is someone working on implementation? Christoph: Not yet. Not sure I can finish by Berlin. We can try. Phil: In Berlin, we can discuss two things: the relationship to tcpinc and data pointed by Costin. We will need more discussion for the bis draft before Berlin. --------------------------------------------------------------------------- 2: Load balancing MPTCP - Costin Raiciu Yoshi: So, the client doesn't have to change anything in this proposal? Costin: Yes. whole idea is server changes, but client doesn't. You have controls on server because you can deploy load balancer. But, you don't have control for clients. Yoshi: Are you proposing two solution or just solution 2? Costin: Solutions 2 is superior. But, we haven't done full analysis. We start from the first one and are working on 2 now. Christoph: With solution 2, I have a bit concern on using different destination port numbers. It's common that some cellular networks might block some ports. Costin: Good point. We are based on the Michio Honda's middlebox research. Yoshi: What's your security concerns in the approach? Costin: Not sure, but you can attack the same one server by using the same destination port number. Alan: People configure FW to permit well-known port number, but less well-know port could be a problem. Costin: Yes, we can see some data in Michio's paper, 5% cannot go through, but our solution is for subflow. It won't be so bad. Christoph: How token collision will happen on server? Costin: Both Solutions won't have a collision problem. Solution 1 could have a problem, but we can use some approach to avoid it. Our experiments shows it takes 2ms to generate keys that falls in the range. Christoph: 2ms can be big for very busy server. Costin: That's a good point. We need to look at it. But, this is only a problem for solution 1. Phil: So, What's the next step to choose or to include? Costin: Our approach doesn't change anything. So, question is if we want to change the spec or not. --------------------------------------------------------------------------- Load balancing for Multipath TCP – Olivier Bonaventure Christoph: What I like is subsequent subflows don't need to go through the marks any more. Would it need to make address reliable in this case? Olivier: For v6, it will be probably easy. In case of V4, for scale of google or MS, it might be tricky. Costin: Yoshi: Is there any big different between this and Costin's solution 2? Costin: It's exact the same except the no join bit. It's more efficient. Alan: Costin: Are we converging that we include this and stop bumping the version number? Alan: No. But, I don't see any problem with this proposal. Yoshi: Flag is very scarce resource. Do we really want to allocate one for this? Alan: Even if we don't bump the version, we will eventually need to bump the version number when we run out of the flags. Costin: That's fine. It gonna take 10 years. Christoph: With regard to version number, one advantage is we gain 8 bytes in the first SYN. Alan: That's was one of the driver for bumping version number. so, any reason cannot be a reason to bump version number? Costin: We have to be certain this is the really important use case. The draft talks about some cases that mptcp fallback to tcp, but mptcp has lots of case to fallback. We need critical cases. Alan: It's great opportunity for us. We are moving from experiment to standard. Christoph: First time, we have designed SYN cookie solution, we haven't changed the version number. But, when we found we can gain 8 byte in the first SYN, we decided to change the number. Alan: Is it possible to send a short SYN to infer what we are doing without changing number? Christoph: 　　I will need to think about if there's a good way. Phil: So, the original version was not dumping the version number? Christoph: Yes, but we have just use one bit in SYN to indicate reliable handshake. Olivier pointed out we can reduce the size of mptcp options, then we decide to change the number. Costin: Don't you think it will be problematic when we change the version number? Christoph: The 6824bis already changed some formats like ADD_ADDR. So, it's already challenging. Phil: We should continue the discussion in Berlin