Subject: [multipathtcp] Interest in hackathon in Berlin?

From: <[email-masked]>
Date: Mon, 20 Jun 2016 09:16:38 +0000

At the Berlin IETF meeting, there's a hackathon on the first weekend - is there any interest in doing something with MPTCP at this?
https://www.ietf.org/hackathon/96-hackathon.html

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 20 Jun 2016 14:44:08 +0200

Phil,

> At the Berlin IETF meeting, there’s a hackathon on the first weekend –
> is there any interest in doing something with MPTCP at this?
>

We are currently finalising an extended socket API that enables 
applications to control the operation of the Multipath TCP 
implementation in the Linux kernel. If there are people interested in 
looking at how applications can be modified to better utilise MPTCP, 
this could be a good objective for a hackathon

Olivier

---

From: "Igor Lopez Orbe" <[email-masked]>
Date: Tue, 21 Jun 2016 15:01:52 +0200

Hello,

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

Best regards,

Igor

-----Mensaje original-----
De: multipathtcp [mailto:[email-masked]] En nombre de Olivier
Bonaventure
Enviado el: lunes, 20 de junio de 2016 14:44
Para: [email-masked]; [email-masked]
Asunto: Re: [multipathtcp] Interest in hackathon in Berlin?

Phil,

> At the Berlin IETF meeting, there's a hackathon on the first weekend - 

We are currently finalising an extended socket API that enables applications
to control the operation of the Multipath TCP implementation in the Linux
kernel. If there are people interested in looking at how applications can be
modified to better utilise MPTCP, this could be a good objective for a
hackathon

Olivier

_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 24 Jun 2016 11:55:06 +0200

Hello,
> 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

Olivier