Multipath TCP (MPTCP) ------------------------------------------------------------------------ Meeting : IETF78, Tuesday July 27, 2010, 17:10-18:10 Location : Maastricht, Auditorium 2 Chairs : Philip Eardley Yoshifumi Nishida AD : Lars Eggert URL : http://tools.ietf.org/wg/mptcp/ Note Taker : Alan Ford Javier Ubillos Olivier Bonaventure ------------------------------------------------------------------------ * Introduction - Chairs This first MPTCP session is to discuss whether to signal using Options or Payloads. Summary of discussions so far -- slides ------------------------------------------------------------------- * NAT measurements by Aki Nyrhinen / Costin Raicu: Iljitsch : mangle MSS what do you mean? Costin change it Joe Touch: MSS should not be updated along the path, it changes because of MTU not option Iljitsch : agree, but they do it for a reason Costin : out of topic Aki : MSS option was there in the TCP segments, observation that some change MSS option, nothing more ------------------------------------------------------------------------ * Middlebox Investigation by Michio Honda ------------------------------------------------------------------------ * Payload Perspective by Michael Scharf connections for using two paths, one is used as a fallback Iljitsch : How does this work? Can modifications to the payload (the extra information) be done in the beginning, middle or the end of the session. Does the extra control info come before, after in the middle of the data. Michael : on additional subflow : uses tlv encoded chunks, in the front of each frame Joe Touch: Is the extra information in the beginning of the frame Michael: Yes Iljitsch : what happens if you lose your frame boundaries Michael : it's in the bytestream, like TLS Michael: It's a bytestream, so you can parse it as a TLV, which is easily recognizable. It is like TLS Joe Touch : extend the option in the SYN ? Michael : no, we use a small option in the SYN (6 bytes), shorter than MPTCP Joe: Ah, this doesn't extend, just saves space. Michael: Yes, we only need 6 bytes. Joe: Because of TLV, you will reassemble the data and then lift it to the connection. Michael: We collect it from the different sockets. Joe: So you will have a set of socket buffers? Michael: Yes, we have a set of sub-sockets. Costin : what happens with ftp-aware NAT that changes sequence number ? Michael : lengthy discussion in the draft : if there is a modification in the length on the initial subflow, i can fall back Costin : should be deterministic not in "most cases", otherwise you can corrupt byte stream. Michael: At this moment Data ACKs are not defined, so it is not deterministic, but with data ACKs it would be. --------------------------------------------------- * Option Perspective by Costin Raicu Tim Shepard: Doesn't TCP fix this by it self? Costin: Because these are two different subflows. Iljitsch : What is the window in the first two packets. Costin: Doesn't matter, there is no data coming through. Iljitsch: What is the initial window? Costin: Two packets: Iljitsch: So then it doesn't need the window info to know it. The receiver will reduce the window in a way that the sender cannot now, this is a general problem, not a multi-path problem. Costin: yes it is, let me show slides [slides..] Iljitsch: what if I have a problem with the "11,3" packet, why not create a new message saying "hey, I do not want this packet", so that the sender gets a message about that the packet was dropped, but not due to congestion. Costin : we want to change tcp as little as possible, your solution does not seem feasible Iljitsch: You are proposing something that happens in every packet, what I propose happens very rarely. Costin : this does not solve all issues. memory consumption and flow control are very important in all stacks in practice. stacks are running to the limit of flow control and we need to take care of corner cases --------------------------------------------------- * Discussion for Payload vs. Option Tim : Unconvinced with Costin's talk. Don't have an issue with the talk, but: we want a MPTCP to talk to another MPTCP, and we can make them different, it doesn't matter, both ends have changed. Believe we may need more option space to make MPTCP robust Costin: The current spec does include a check, and it does fit in options, we have calculations. But we believe there might be even easier simpler solutions. Tim: I still prefer payload, but that is a very good point. separate subflows might solve. subflows would carry data in only one direction Costin: The high level point is that if you put the data in the payload, we will pay in performance independent of how we do it. We still have head of line blocking. One of the biggest points in the implementors workshop was from one of the BSD guys, "We want MPTCP, but there must be no performance penalty when going from MPTCP -> TCP". We are building a protocol that has understood consequences. If you have a protocol that has fundamental problems we won't be able to make it work. The current stack does copy from userspace and kernel, the rest is optimized (hardware). Lars: since there are middleboxes that change payload, we should stick with solutions that use options and not payload Tim : need integrity check in mptcp Lars : measurements show that home gateway devices seem to be okay for options Marcelo : this is tcp control info, architecturally clean place is option. measurements show that middlebox do not mangle options. if we we run out of space, we extend it. We might face problems, perhaps a working but unclean solution is better. The question is _why_ would we do payload? We need good reasons, but cannot see so far. Jana: we use tcp option because we know that we cannot build a new transport. Was for payload in the past. you might do encoding for the data acks only. We should be worried about limited option space. no strong opinion on option versus payload Michael : does traffic asymmetry affects this problem ? What about robustness. How do you safely fallback in case of problems? What are the future plans in the draft Costin : there is already info in the draft. If you in the middle of the connection, your routing changes and you cant pass new options any more, to survive this, just send two ACKs when you start timing out. If the middle box is trying to stop MPTCP, we should _stop_ that connection. We should only care about not failing if TCP would have worked. I don't want to hide MPTCP from the network, if we need to fall back, then fine, fallback. We are being open to the network, announcing our presence. Michael: There is an extensive discussion about this in my draft, and a fallback is not always possible, because you cannot open a new subflow. Iljitsch : Overall, Costin's presentation was very convincing. For options for TCP offloading, new options might not work. Costin : offload is already used in Sebastien's implementation Iljitsch : but the vendor will have to start making MPTCP-offloading. Alan : agree that option is the architecturally correct way to put it. If we are doing stuff in the payload, we are meddling in the application layer. Lars : There is another session on Thursday, we need to come to a conclusion on this issue. Can we make a decision or do we need more data? We need to move forward, we cannot spin on this issue forever. Phil : There will be a humm on Thursday Andrew MaGregor : putting control in payload as tlv would break tcp offload engines ------------------------------------------------------------------------ Meeting : IETF78, Thursday July 29, 2010, 17:10-18:10 Location : Maastricht, Auditorium 1 Chairs : Philip Eardley Yoshifumi Nishida AD : Lars Eggert URL : http://tools.ietf.org/wg/mptcp/ Note Taker : Olivier Bonaventure ------------------------------------------------------------------------ * Brief summary of Saturday,F"(Bs Implementors workshop see slides ------------------------------------------------------------------------ * Consensus Call for Payload vs. Option Option #1 : use a TCP option for all signaling Option #2 : Use TLV encoding in payload (for at least some signaling) estimates 20 for options, 3 for TLV ------------------------------------------------------------------------ * Threat Analysis by Marcelo Bagnulo Braun Text has been added to the document on HMAC MPTCP should be capable of supporting multiple security mechanisms to enable more secure mechanisms in the future Review from Erik Nodmark on how much analysis we need to do to support multiple solutions and how they interact Lars : clarification, multiple security does not only mean crypto agility. Marcelo : agreed Marcelo : do you want the analysis from erik in the document? Yuri Smilov : proposal, some sketch of how security can be negotiated at session startup Marcelo : this is a threat analysis Alan : What are the threats with different mechanisms with different security properties? Downgrading attacks. Lars : threat analysis must be focused on the default analysis, cannot be complete to try all possible solutions. However, we should mention multiple security mechanisms in the architecture document to ensure that this is not prevented in the feature Chairs : This will be discussed in the mailing list Phil : analyze baseline in the threats document and mention extensibility in the architecture document. If people contribute text that's fine, if not this will not block last call Alan : a bit uncomfortable going on last call on this Marcelo : Share your concern. We haven't received enough comments, go for last call to get comments Erik : does not seem to belong to the threat analysis Yuri : during last meeting, there was a question about adopting sctp mechanism. Marcelo : This is what I have done and will be done in the solution Chairs : ask for volunteers to read document, notably sctp or mobile security people. Michael Tuexen and Randy Stewart volunteered. ------------------------------------------------------------------------ * Multipath TCP Architecture by Alan Ford update on draft, very little change open points : - do we need additional content - who agrees to review the architecture document Volunteers : Illitsch, Olivier, Gorry Fairhurst ------------------------------------------------------------------------ * Multipath TCP Protocol by Alan Ford discusses differences between 00 and 01, ongoing discussions and further work Lars : does not buy the motivation for lightweight subset. Significantly increases complexity checking for interoperability etc. Do we even need a simpler stuff for data center Costin: datacenter might not need the crc or could be turned off in the feature once middlebox understand mptcp. Alan: we are looking for a few more bits in the syn option, not multiple versions of the protocol Erik : fundamental questions : what are the middlebox that modify content, the ones that I know also parse the content, what happens if they see only a subset of the content. dpi or xml what happens if xml does not make sense anymore? reset connection in firewall? Fallback will be disruptive Alan : we want to detect whether the middlebox changes something Erik : dpi try to parse and giveup if the flow is not correct, need fallback for this, in that case how fancy detection do you actually need? Alan : would be useful to have input from vendors of such boxes, we only have limited info Tim : You said you could reestablish the tcp connection so that the application is not affected, this does not work Alan : applications are used to connections being dropped and have to deal with it Costin : if DPI changes the subflow, the app will not receive due to the mptcp crc. when you detect a problem, you fallback to regular tcp and the middlebox can do whatever it wants and the app will receive the correct info Tim: crc is expensive to touch all the data Andrew knuts : middlebox, they do not work if flows can be split and they are not deployed that way. Alan : mptcp splits flows Andrew : if you use middleboxes, you need to ensure that the design will not split flows Erik : if I have a redundant setup, today a TCP connection goes through one middlebox, with mptcp this is no longer the case as the packets may go to the different middleboxes Tim : another example you could imagine a situation with wifi open for visitors with a middlebox, but a visitor has a 3G and this part does not pass through the middlebox Andrew : that makes sense, people have to tradeoff the benefits of having the middlebox and the benefits of mptcp. in between middleboxes, people want multipath to work Costin : agree with these concerns, we can apply fallback when one flow gets reset and fallback to tcp, you can probably cope with these cases Alan : We need additional review ------------------------------------------------------------------------ * Congestion Control for mptcp by Costin Raiciu Update on the congestion control draft, independent implementations Reviews are requested Erik : Do you know performance study about cpu utilization ? Costin : did first principle analysis, for our current code when the cwin grows by one mss, there is an update that involves the congestion window of all subflows, that's the difference in complexity Amanpreet Singh : when setting a new subflow, how many subflows do you open how do you make sure that a poorly performing subflow will not decrease the performance Costin : number of flows, good question which is open, might open all and close the non performing ones, haven't gone through this issue in details, if you have a big receive buffer, there should be no throughput loss due to bad subflow, but normally this is not the case, simple heuristic were you look at the proba of a subflow stalling the connection and either reduce rtt of the subflow by changing window ?? : at the moment there is no heuristic Costin : assumed, at the moment, that lots of memory Lars : This is not something that we need to standardize, but we definitely want to have proven good ideas in the document for implementors, we need people with implementations to try heuristics. SCTP work can be generalized, could be a source of subflow management schemes Yoshifumi : what do you think about slowstart Costin : assumption is that each subflow will do its own slowstart. you could be more aggressive that tcp, not a difference if flows are long lived, maybe reuse current ssthresh from other subflows. Costin : When do you turn on multiple? maybe after a few tens of KB of data Yoshifumi: you should include this in the draft ------------------------------------------------------------------------ * mptcp API by Michael Scharf comparison of mptcp/tcp stable operation of mptcp with legacy applications : changed basic api for MPTCP-aware applications : new text Advanced api out of scope of this draft appendix could move to another draft based on feedback from implementation Erik: Think it is better to have ancillary function that provide the whole list, see sctp api. We need as few variability as possible in the existing apis ?? : sctp_getladdrs and sctp_getpaddrs are not specific to sctp ?? : don't leave the stuff undefined Michael : choice 1. Expects discussion on mailing list about last slides Phil : probably need a few more people to read the draft