Subject: [multipathtcp] minute for Quebec Meeting

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 24 Aug 2011 03:21:14 -0700

Hello,

Sorry for the long delay. We've prepared the minute from the last meeting.
We will upload it after final check. If you have comments, please let us know.

Thanks,
--
Yoshifumi & Phil

-----------------------------------------------------------------------------------------------------------
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.