Multipath TCP (MPTCP) Meeting : IETF80, Thursday March 31, 2011, 1740-1940 Location : Prague, Congress Hall I Chairs : Philip Eardley Yoshifumi Nishida AD : Wesley Eddy URL : http://tools.ietf.org/wg/mptcp/ Note Taker: Olivier Bonaventure ------------------------------------------------------------------------------------ 1: Introduction - Chairs Two RFCs were published. RFC6181 and RFC6182 Need reviewers for protocol draft. Implementation available check inl.info.ucl.ac.be/mptcp ------------------------------------------------------------------------------------ 2: Mptcp Protocol - Alan Ford Alan: Please send us the feedback Michael Welzl: I volunteer for reviwing Lars eggert: Is there another implementation besides ucl's implementation? If you are doing an implementation, please send feedback ------------------------------------------------------------------------------------ 3: MPTCP Proxies - Mark Handley Lars Eggert: why wouldn't the mobile open connection to both proxy and server? Mark: it could do. But, you'll need to figure it out which one works and need to kill state on the server. Scott Brim: are the slides available? Phil: It's in the congestion control slide. Scott: cool thing you can use to do this is mobile IP homeagentr. This is winning combination. you want an initial rendez-vous point anyway for privacy Mark: not exactly the same role, it is similar, but proxy would need to behave differently with normal server and mptcp server Randall Stewart: there is IPR on this at a former employer, did similar thing for SCTP Scott Brim: had no idea this patent covered this, we'll ask later. extremely excited to see this model, you get 3 for 1, grab people who like mobile ip, don't need route optimisation, get privacy and get optimisation with mptcp Mark: one thing we need to do is to tell the proxy where to connect to and you need to do this in the syn would like to put an address in the syn, but we don't have space for this principles are easy, but in practice not easy to find the bytes should we try this on the first path in the protocol spec ? Anantha Ramaiah you seem to indicate mobility use case, but mptcp could be a general proxy, in such case all connections will go through the proxy. If the proxy knows that the server is mptcp capable and it does not need the flow anymore Mark: it might want to relay data at the beginning of the subflow to reduce latency you could do after the syn, but looks difficult Anantha: take it offline Tim Shepard: mptcp proxy is used for everything and you have a long term relationship and have state in both ends, why not tunnel the information to the proxy Mark: gre would not go to nat Tim: TCP goes through NAT, could tunnel over TCP? Mark: maybe over UDP? Scott: mobile ip Tim: if you have wifi access point that is causing problem, does mip work Mark: there is nat on all these links Tim: tunnel might make sense Mark: udp tunneling makes sense to me, but don't like udp. it's cleaner to do it natively. Lars Eggert: assuming you could reuse some bits of the source ports, fragment ids, etc Alan Ford: data in the syn, wait for discussion in tcpm and work on spdy in google Tim Shepard: you know you are talking to a special box and you could use special acks to discuss with this box, think more evil Mark: Do we want this in the normal spec? Scott Brim: keep separate Lars Eggert: agree with Scott, don't hold the draft in the wg longer Tim Shepard: should not be in the spec? spec needs to encourage people to implement mptcp. this is just for proxy Alan Ford: don't know if this will be useful and wireless is uncontrol Phil: keep it separate but there is interest in the room ------------------------------------------------------------------------------------ 4: MPTCP API - Michael Scharf Authors have corrected some minor issues based on reviews Document pretty stable, please provide further feedback Phil : There will be a WGLC after the next revision ------------------------------------------------------------------------------------ 5: Coupled Congestion Control - Mark Handley 3 reviews received for the previous draft, mainly wording and interpretation bytes/packets stacks. Draft has been updated to cover both and avoid rounding errors. Packet based version assumes that mss is same on all paths and draft describes how to handle the case if mss are different. NSDI2011 paper describes the algorithm in details and its performance Phil: We're running WGLC for this draft. ------------------------------------------------------------------------------------ 6: Demonstration of Linux MPTCP implementation - Sebastien Barre Demo setup: two servers on 100Mbps links in a LAN with a programmable router that inserts delay or losses between the two servers. servers are running latest mptcp linux kernel implementation iperf running between the two servers, gets almost 200 Mbps at the application level Tecco Boot: why did loss on the blue link caused a reduction in bandwidth on the green one? Sebastien: related to retransmission that are done on the other flow, retransmission timeout may cause delays and fill receive buffer Mark Handley: congstion control is linked between the two subflows and this explains. when both flows are equal loss, they get the same performance in modelling congestion Tim Shepard: all point is to move traffic away from congested path Tecco Boot: I would like to have a solution to react differently to losses and congestion. Looking for solutions taking traffic from satcom to 3G to wifi, mptcp could do some job there, you should use reliable link Mark: How do you detect whether the loss is due to congestion or due to something else? Without this info, we need to assume that they are caused by congestion and not by link errors Georg Hampel: demo is very nice. What happens if there is a large delay, up to 3 or 5 seconds? Yoshifumi: How do you create delay and loss? Sebastien: It's tc. artificial Michael Scharf: I like this demo, but independant of mptcp design, did the same demo with another protocol. could do it with a different protocol ------------------------------------------------------------------------------------ 7: Autoconfiguring single-homed end-systems to make use of network multihoming - Rolf Winter Questions : do peole think it's useful? ??? : for experiments this is useful if you have a lot of time, but for normal usage, this is interesting for IPv6, multihoming on a single homed host with multiple addresses. how does mptcp work in this environment Rolf: other scenarios are discussed in this document some discussion on ipv4 versus ipv6 Phil: count show of hands: a dozen hands ------------------------------------------------------------------------------------ 8: Rechartering - Chair Possible topics for rechartering Advice on implementation and heuristics ? Support for singl-homed end systems Applicability and experience Alternative security Alternative congestion control Advanced api Proxy for mobility Mark Handley: intend to spend some time on heuristics section, there is a lot we don't know, need good ways Scott Brim: I consider the following topics applicability and experience alternative congestion control advanced api proxy for mobility I hope somebody would work on these, I want to work on proxy for mobility Tim Shepard: there should be a venue to do interop testing if there is a second implementation. nice to continue with a venue Phil: default option is to finish charter before the next ietf and pause while waiting for experiements and usage Alan Ford: We'll get more feedback as implementations progress Lars Eggert: nobody else is doing an implementation or knows another implementation ? Sowmini Varadhan from oracle: working on multipath for solaris Sebastien: a dozen people are helping in debuging and four are providing patches, others are downloading merge in main linux tree is too early, need to stabilise and follow the draft Lars: be great if more people could contribute