Re: [multipathtcp] Interest in hackathon in Berlin?

Olivier Bonaventure <> Fri, 24 June 2016 09:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7DBB12DA01 for <>; Fri, 24 Jun 2016 02:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bBHC7dGeXV7j for <>; Fri, 24 Jun 2016 02:55:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6693812D14D for <>; Fri, 24 Jun 2016 02:55:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 8BEAF67E24D; Fri, 24 Jun 2016 11:55:05 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 8BEAF67E24D
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1466762105; bh=tU2YM90Gu56EHLqo1o9swncDVkjMj/hmlB80ZNjZEzA=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=a5N92TKdVReW3UYVbolUnd/VfjC1bD9RLT2MgN1T57Hbos051hrHyHxqb+QZUni/X luxio+KrCgkuqGN1imKY9PyBzADIpX23LArzffIXwUMvQphUod84NMTrK1ga8+8XwY crHX1qCsKGlDw/uRtNqOXt+Fstn7ubiEvENM+FIk=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-2
References: <> <> <003801d1cbbd$15185a30$3f490e90$>
To: Igor Lopez Orbe <>,
From: Olivier Bonaventure <>
Message-ID: <>
Date: Fri, 24 Jun 2016 11:55:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <003801d1cbbd$15185a30$3f490e90$>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 8BEAF67E24D.A4DB1
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Subject: Re: [multipathtcp] Interest in hackathon in Berlin?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jun 2016 09:55:17 -0000

> Will this extended API also fit the requirements defined for the advanced
> API (Appendix A) in the RFC6897?

We will prepare a draft for the Berlin meeting that explains the 
operation of the API. Looking at the requirements from RFC6897, the 
following ones are supported :

>    REQ5:   An application should be able to establish MPTCP connections
>            without using IP addresses as locators.

We currently expose the IP addresses to the application and the 
application used them to create subflows.
It could be possible to add an abstraction about the low-level socket 
API to meet this kind of requirement.

>    REQ6:   An application should be able to obtain usage information and
>            statistics about all subflows (e.g., ratio of traffic sent
>            via this subflow).

The API exposes subflows to the application. On Linux, the TCP_INFO 
socket option allows to retrieve stats about the subflows. Our API 
supports that on a per subflow basis.

>    REQ7:   An application should be able to request a change in the
>            number of subflows in use, thus triggering removal or
>            addition of subflows.  An even finer control granularity
>            would be a request for the establishment of a specific
>            subflow to a provided destination or a request for the
>            termination of a specified, existing subflow.

Our API allows the application to create/terminate subflows at any time.

>    REQ8:   An application should be able to inform the MPTCP
>            implementation about its high-level performance requirements,
>            e.g., in the form of a profile.

This is beyond the scope of a low-level API, but a higher level API such 
as socket intents could be built on top of that.

>    REQ9:   An application should be able to indicate communication
>            characteristics, e.g., the expected amount of data to be
>            sent, the expected duration of the connection, or the
>            expected rate at which data is provided.  Applications may in
>            some cases be able to forecast such properties.  If so, such
>            information could be an additional input parameter for
>            heuristics inside the MPTCP implementation, which could be
>            useful, for example, to decide when to set up additional
>            subflows.

Same comment as REQ8

>    REQ10:  An application should be able to control the automatic
>            establishment/termination of subflows.  This would imply a
>            selection among different heuristics of the path manager,
>            e.g., 'try as soon as possible', 'wait until there is a bunch
>            of data', etc.

This is not currently supported but the API exposes events that allow 
the application to control the creation/termination of subflows.

>    REQ11:  An application should be able to set preferred subflows or
>            subflow usage policies.  This would result in a selection
>            among different configurations of the multipath scheduler.
>            For instance, an application might want to use certain
>            subflows as backup only.

The API allows to set MP_PRIO on a per subflow basis. Selecting a 
scheduler on a per connection basis could be possible but it not yet 
completely implemented.

>    REQ12:  An application should be able to control the level of
>            redundancy by telling whether segments should be sent on more
>            than one path in parallel.

The Multipath TCP implementation in the Linux kernel does not currently 
support this kind of redundancy.

>    REQ13:  An application should be able to control the use of fate-
>            sharing of the MPTCP connection and the initial subflow,
>            e.g., to overwrite system policies.

I'm not sure that I understand this requirement

>    REQ14:  An application should be able to register for callbacks to be
>            informed of changes to subflows on an MPTCP connection.  This
>            "push" interface would allow the application to make timely
>            logging and configuration changes, if required, and would
>            avoid frequent polling of information.

This is part of the ongoing work