[multipathtcp] Open /closed issues from WG meeting

[<[e-mail]>]

>From the WG meeting I think we have a proposal on various Issues that seemed open before the meeting.
This email is to check consensus, especially amongst the WG people who aren't in Quebec or didn't listen in.

Of the issues, (1) was raised in the meeting, (2) & (3) are from Mark's slide 12, (4) and (5) are from Georg's slide 34.

(1) Ack of MP_CAPABLE.
See Mark's email to the list a short while ago, which explains & proposes a resolution.

(2) Mobility in fallback
The doc needs to correctly describe the case - when it works OK & when it doesn't (ie what the limitation is). We accept the limitation (it isn't too clear how to do a solution but seems it would be complex)

(3) Teardown of state when all subflows fail
This is a heuristics issue rather than a protocol issue.
(Hopefully in the future we can write a doc with lessons learnt from experiments, with suggestions how to deal with all sorts of heuristics issues)

(4)  Add Bulk_transfer_optimisation flag to MP-Capable?
Don't add, seems like extra complexity for not much gain

(5) Add support for transparent proxy?
Rough consensus in the room in Quebec to add an "I'm a proxy" flag to ADD_ADDRESS.
Need the precise text to add to the draft.

We'd like to resolve all these issues within the next week or so - hoping that proves possible!

We will WG last call as soon as there's an updated draft that deals with these issues.

If I got something wrong, please shout.

thanks to everyone for the efforts to try and resolve the hopefully last remaining issues with the protocol spec.
Best wishes,
phil
________________________________
From: [e-mail] [[e-mail]] On Behalf Of [e-mail] [[e-mail]]
Sent: 27 July 2011 23:34
To: [e-mail]
Subject: [multipathtcp] Draft minutes of WG meeting

thanks to Andrew for taking notes.

Here are the draft minutes of the meeting, please send corrections /improvements
thanks
phil/

Minutes of MPTCP WG Meeting
WEDNESDAY, July 27, 2011
0900-1130  Morning Session I
Main aim:
Conclude on all protocol issues. So that we can WG last call protocol (& API) docs immediately after IETF.

1. Agenda bashing, note well, Milestones – Chairs

2. API update – Michael Scharf
Doc ready for last call, no comments.

3. Congestion control update – Mark Handley
Done. Minor comments from IESG and David Black have been resolved.

4. Protocol update & discussion of open issues – Mark Handley
Reviewers could review section 2 (overview)
Small changes to protocol

Discussion over sending key-A on the third Ack; there is an issue over the reliable delivery of the key.
Jana: B could echo back the options.
Mark: The issue is how to trigger stopping option sends.  We will double-check if the issue is covered and resolve if required.

Discussion on mobility in fallback mode
It doesn't seem that it is possible to reliably use mobility in fallback mode.
Andrew: Isn't that OK?  Can't you just say, if the ACKs haven't arrived, oh well, RST it.
Georg: The draft says that there's no more multipath signalling in fallback.  So you can't get here.
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 optimise this case.
What to do if all subflows are in time out?
Phil: You're saying that is an implementation specific heuristic?
Andrew: What say no interfaces are up?
Mark: Yes, doesn't need specified.

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. (new draft) 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: 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"
Andrew: ... 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: good idea
Mark: I'm not totally convinced that buffer reduction is real.
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.  Assert: you should be able to tell from signal strength etc. if it is a good link... not really.  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
Andrew: Wifi links have to train up, which can take a few hundred packets
David: I have in mind a satellite PEP setup, where RTT could be radically different.
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.
Georg: Both of our points are based on speculation, we need to know how well you do if you shorten the overlap
Costin: that 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
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
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
Andrew: Suggest not doing bulk transfer optimisation, 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
Georg: Proxy is not optimisation, it's a feature
Michio: No such middle box
Mark: If we can preserve the benefits in the presence of boxes that want to be on path, then we should.  If we don't want the content inspected, we need to encrypt.
Georg: 3G providers still get to bill it.
Gorry: There are proxies that need to inform L2 what is going on.
Andrew: Could have network architectures that wouldn't otherwise work that way.
Mark: We should probably try to address this before we move the protocol 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.
Costin: +1

6. Call for news on Implementations
Linux version being updated as http://mptcpinfo.ucl.ac.be<http://mptcpinfo.ucl.ac.be/>e/>, also for Nokia N900 & Android Nexus-one
Tim: Implementation is not SMP capable, does anyone know if it is fixed?
<apparently not, docs still say no SMP>
Georg Hampel - in progress on 'lightweight' implementation
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 - Chairs


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.