Minutes for MPTCP at interim-2016-mptcp-01
minutes-interim-2016-mptcp-01-1

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