Subject: [multipathtcp] Socket API for MPTCP

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 8 Jul 2016 17:56:45 +0200

Hello,

During the last years, we have received on a regular basis questions 
from users of Multipath TCP on how they could control the utilisation of 
the subflows. In the Linux implementation, the default solution was to 
tune the path manager, but this is kernel code and few users actually 
managed to change this path manager.

Benjamin Hesmans has spent some time to think about simple extensions to 
the socket API to allow applications to control the underlying Multipath 
TCP stack. He has implemented his ideas and has running code. A first 
draft describing his API has been submitted to the IETF :

Title:		A socket API to control Multipath TCP
URL: 
https://www.ietf.org/internet-drafts/draft-hesmans-mptcp-socket-00.txt

Abstract:
    This document proposes an enhanced socket API to allow applications
    to control the operation of a Multipath TCP stack.

A related paper will also appear at the ANR workshop :

https://irtf.org/anrw/2016/anrw16-final16.pdf

We have requested a slot to present in Berlin. We expect that agreeing 
on a common socket API exposed by Multipath TCP implementations would 
help its end-to-end deployment.

Olivier and Benjamin

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 10 Jul 2016 13:40:49 +0200

> https://www.ietf.org/internet-drafts/draft-hesmans-mptcp-socket-00.txt

Hi Olivier,

I've only had a quick look at the draft, and haven't read the paper, so
I could get this wrong.

I don't see a way to receive asynchronous notifications of subflow
creation and destruction.  If my application is using a select-based event
loop, there is apparently no way to request that the select should be
interrupted when a new flow is created.

Is that correct?

-- Juliusz

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 10 Jul 2016 14:18:33 +0200

Juliusz,
> interrupted when a new flow is created.

The first draft does not yet describe how to support notifications. 
Benjamin is finalising the implementation of these notifications, 
currently on top of recvmsg and sendmsg. We will then look at select. 
These notifications will be documented in the next version of the draft.

Olivier

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 10 Jul 2016 14:21:06 +0200

> The first draft does not yet describe how to support
> notifications. Benjamin is finalising the implementation of these
> notifications, currently on top of recvmsg and sendmsg. We will then
> look at select. These notifications will be documented in the next
> version of the draft.

Excellent, thanks.

-- Juliusz

---

From: Rui Paulo <[email-masked]>
Date: Mon, 11 Jul 2016 11:41:30 -0700

On Jul 10, 2016, at 05:18, Olivier Bonaventure <[email-masked]> wrote:
> 
> We will then look at select. These notifications will be documented in the next version of the draft.

Does it make sense to talk about kqueue-style notifications in the draft?  Some operating systems have notification mechanisms that can be extended to support MPTCP events in a way that’s cleaner than select().

--
Rui Paulo

---

From: Alan Silva <[email-masked]>
Date: Wed, 13 Jul 2016 21:38:16 -0300

Hi,

On Mon, Jul 11, 2016 at 3:41 PM, Rui Paulo <[email-masked]> wrote:

> Does it make sense to talk about kqueue-style notifications in the draft?
> Some operating systems have notification mechanisms that can be extended to
> support MPTCP events in a way that’s cleaner than select().
>

I agree, but I think the choice for look at select-style notification for
now is because it is based on the linux version of mptcp. I think in the
future with mptcp for BSDs more stable, this draft will be updated.

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 14 Jul 2016 14:00:46 +0200

Rui,

> Does it make sense to talk about kqueue-style notifications in the draft?  Some operating systems have notification mechanisms that can be extended to support MPTCP events in a way that’s cleaner t…

My suggestion in Berlin will be to ask to include an API item in the 
charter and suggest the socket draft as a starting point. I hope that 
other implementors will participate to the draft so that we can have an 
API that it common to all MPTCP implementations. select is one option 
for the notifications, recvmsg/sendmsg, kqueues, etc. Ideally, we should 
document the available API and ask feedback from developpers to improve 
them.

Olivier