Subject: [multipathtcp] Adding a new work item on MPTCP API

From: <[email-masked]>
Date: Wed, 9 Nov 2016 10:21:42 +0000

Following the earlier discussion, there is support to add a charter item as follows:
<<RFC6897 defined an optional, basic application interface for MPTCP-aware applications, including a set of socket operations. Now there is more experience of how MPTCP is being used, the WG will re-visit this work, and consider adding more advanced socket operations. The document will be Informational.>>
If you disagree with this being added, or suggest some mod to this item, please say.
Thanks
Phil & Yoshi

From: [email-masked] [mailto:[email-masked]]
Sent: 31 July 2016 20:37
To: Eardley,PL,Philip,TUB8 R <[email-masked]>
Cc: MultiPath TCP - IETF WG <[email-masked]>
Subject: Re: [multipathtcp] potential new work item on MPTCP API

On Jul 26, 2016, at 7:35 AM, [email-masked]<mailto:[email-masked]> wrote:

Christoph,
https://tools.ietf.org/html/rfc6897#section-5.3 is “Sockets Interface Extensions by the Basic MPTCP API”
(also https://tools.ietf.org/html/rfc6897#appendix-A “Appendix A. Requirements on a Future Advanced MPTCP API”)

Ok, I see. Fair enough. Extension to RFC6897 seems fine to me then.

Cheers,
Christoph

phil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 22 July 2016 09:48
To: Eardley,PL,Philip,TUB8 R <[email-masked]<mailto:[email-masked]>>
Cc: MultiPath TCP - IETF WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] potential new work item on MPTCP API

Hello,

On Jul 21, 2016, at 5:43 PM, [email-masked]<mailto:[email-masked]> wrote:
Yesterday Olivier presented about his & Benjamin’s recent work on MPTCP socket api. We didn’t have much discussion whether to add this to the charter. One comment was that any work should build on /reference RFC6897.
https://www.ietf.org/proceedings/96/slides/slides-96-mptcp-4.pdf
Please can you comment whether you see this as a useful work item, or you think it shouldn’t be worked on, or how it should be adapted to something you think the WG should work on.

yes, I think it is a very useful work item and am willing to contribute to this work.

I'm not sure whether this can be seen as an update to 6897. I'm under the impression that 6897 takes a different approach, giving users a high-level overview of how using MPTCP might look like to an application that is talking to a TCP-socket (which happens to end up using MPTCP).

Olivier's work seems to rather make MPTCP entirely explicit to the application. So, I think both works take a different approach.

To help prompt the discussion, here’s a very first version of some possible charter text
RFC6897 defined an optional, basic application interface for MPTCP-aware applications, including a set of socket operations. Now there is more experience of how MPTCP is being used, the WG will re-visit this work, and consider adding more advanced socket operations.

RFC6897 was Informational – would this new Milestone be Informational or Experimental?

I think it should be Informational.

Christoph

Thanks
phil

Philip Eardley
Research and Innovation
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 9 Nov 2016 11:52:48 +0100

What do you mean by "including a set of socket operations"? I'm not sure if 
RFC6897 define any operations. I'm actually not sure what socket operations 
are...

Mirja

On 09.11.2016 11:21, [email-masked] wrote:
> <<RFC6897 defined an optional, basic application interface for MPTCP-aware
> applications, including a set of socket operations. Now there is more
> experience of how MPTCP is being used, the WG will re-visit this work, and
> consider adding more advanced socket operations. The document will be
> Informational.>>
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* 31 July 2016 20:37
> *To:* Eardley,PL,Philip,TUB8 R <[email-masked]>
> *Cc:* MultiPath TCP - IETF WG <[email-masked]>
> *Subject:* Re: [multipathtcp] potential new work item on MPTCP API
>
>
>
>
>
>     (also https://tools.ietf.org/html/rfc6897#appendix-A “Appendix A.
>     Requirements on a Future Advanced MPTCP API”)
>
>
>
>     *From:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]]
>     *Sent:* 22 July 2016 09:48
>     *To:* Eardley,PL,Philip,TUB8 R <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* MultiPath TCP - IETF WG <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:* Re: [multipathtcp] potential new work item on MPTCP API
>
>
>
>     Hello,
>
>
>
>         Yesterday Olivier presented about his & Benjamin’s recent work on
>         MPTCP socket api. We didn’t have much discussion whether to add this
>         to the charter. One comment was that any work should build on
>         /reference RFC6897.
>
>         Please can you comment whether you see this as a useful work item, or
>         you think it shouldn’t be worked on, or how it should be adapted to
>         something you think the WG should work on.
>
>
>
>     I'm not sure whether this can be seen as an update to 6897. I'm under the
>     impression that 6897 takes a different approach, giving users a
>     high-level overview of how using MPTCP might look like to an application
>     that is talking to a TCP-socket (which happens to end up using MPTCP).
>
>
>
>     Olivier's work seems to rather make MPTCP entirely explicit to the
>     application. So, I think both works take a different approach.
>
>
>
>
>         RFC6897 defined an optional, basic application interface for
>         MPTCP-aware applications, including a set of socket operations. Now
>         there is more experience of how MPTCP is being used, the WG will
>         re-visit this work, and consider adding more advanced socket operations.
>
>
>
>         This email contains BT information, which may be privileged or
>         confidential. It's meant only for the individual(s) or entity named
>         above. If you're not the intended recipient, note that disclosing,
>         copying, distributing or using this information is prohibited. If
>         you've received this email in error, please let me know immediately
>         on the email address above. Thank you.
>         [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Alan Ford <[email-masked]>
Date: Wed, 9 Nov 2016 13:38:27 +0000

That reads as if it is adding more advanced APIs over and above what’s in 6897. Given a lot of this work has already been covered in 6897, I think it would be useful to determine what exactly it is that is desired in addition. Is it an update to 6897 based on operational experience? I feel it should also be clear that this builds upon 6897 and not re-invent the wheel.

Regards,
Alan

> On 9 Nov 2016, at 10:21, [email-masked] wrote:
> 
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: 31 July 2016 20:37
> To: Eardley,PL,Philip,TUB8 R <[email-masked] <mailto:[email-masked]>>
> Cc: MultiPath TCP - IETF WG <[email-masked] <mailto:[email-masked]>>
> On Jul 26, 2016, at 7:35 AM, [email-masked] <mailto:[email-masked]> wrote:
>  
> Christoph,
> https://tools.ietf.org/html/rfc6897#section-5.3 <https://tools.ietf.org/html/rfc6897#section-5.3> is “Sockets Interface Extensions by the Basic MPTCP API”
> (also https://tools.ietf.org/html/rfc6897#appendix-A <https://tools.ietf.org/html/rfc6897#appendix-A> “Appendix A. Requirements on a Future Advanced MPTCP API”)
>  
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: 22 July 2016 09:48
> To: Eardley,PL,Philip,TUB8 R <[email-masked] <mailto:[email-masked]>>
> Cc: MultiPath TCP - IETF WG <[email-masked] <mailto:[email-masked]>>
> On Jul 21, 2016, at 5:43 PM, [email-masked] <mailto:[email-masked]> wrote:
> https://www.ietf.org/proceedings/96/slides/slides-96-mptcp-4.pdf <https://www.ietf.org/proceedings/96/slides/slides-96-mptcp-4.pdf>
> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>
>  
> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 9 Nov 2016 16:30:59 +0100

Phil,

> <<RFC6897 defined an optional, basic application interface for
> The document will be Informational.>>
>

Fine for me. When RFC6987 was published, nobody had experience with an 
API for MPTCP. With the existing deployments, there is experience with 
such APIs and it makes sense to define an API that would allow 
applications to interact with an MPTCP stack. The availability of such 
an API will be very important for those who want to deploy MPTCP 
end-to-end. There are various use cases where it makes sense for an 
application to control the utilisation of the underlying subflows and 
the WG should support those use cases.

When MPTCP was designed, we refrained from doing any modification to the 
socket API to ensure that it could be incrementally deployed and support 
existing application. Looking at the largest deployment, it turns out 
that this deployment is an application that does a clever utilisation of 
the underlying MPTCP stack and not a generic application that simply 
runs on top of MPTCP...

We should probably start the work by looking back at RFC6897 and examine 
which parts of this document have been implemented or can be implemented 
and which parts should be updated based on the operational experience.

Olivier

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 9 Nov 2016 19:41:39 +0100

Hi all,

if we ‚only' talk about an update of 6897, I guess that could be even done with the current charter…

Mirja

> Am 09.11.2016 um 14:38 schrieb Alan Ford <[email-masked]>:
> 
>> On Jul 26, 2016, at 7:35 AM, [email-masked] wrote:
>>  
>> Christoph,
>> On Jul 21, 2016, at 5:43 PM, [email-masked] wrote:

---

From: Christoph Paasch <[email-masked]>
Date: Sat, 12 Nov 2016 23:31:36 -0800

Hello,

> If you disagree with this being added, or suggest some mod to this item, please say.

I support this work as well.

But, I also agree with Mirja's comment that "socket operations" is not a
well-defined term. I guess, what has been meant was "socket options" - the
ones that are available in many operating systems.

I think the API should not limit itself to a specific way on how to
configure the stack (e.g., through socket-options, ioctl, netlink,...).
But rather be agnostic as to the technical details on how the higher
layer configures/controls the MPTCP-stack.

Christoph

---

From: Fabien Duchêne <[email-masked]>
Date: Mon, 14 Nov 2016 03:03:48 +0100

Hello,

> layer configures/controls the MPTCP-stack.

I support this work and I agree with Christoph and Mirja.

Cheers,

Fabien

---

From: <[email-masked]>
Date: Mon, 14 Nov 2016 05:09:55 +0000

re socket operations.
this is the term used in https://tools.ietf.org/html/rfc6897#section-5.3
happy to use whatever term is clearest - operations, options or sometihing else!
phil
________________________________________
From: multipathtcp <[email-masked]> on behalf of Fabien Duchêne <[email-masked]>
Sent: 14 November 2016 02:03
To: [email-masked]
Subject: Re: [multipathtcp] Adding a new work item on MPTCP API

Hello,

Cheers,

Fabien

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 14 Nov 2016 06:53:26 +0000

As far as I recall, I think the term "socket operation" was intentionally used instead of "socket option", since it was considered to be applicable to any TCP API, e.g., also the APIs used by high-level programming languages such as Java. 

The feedback was that the term "socket option" is not applicable to all TCP stacks. And even on TCP stacks that use the socket interface, many applications may have no access to socket options since they use a more abstract API (e.g., a library). The objective of RFC 6897 was to apply to all potential TCP stacks.

Possibly better terms can be found.

Michael

> -----Original Message-----
> From: multipathtcp [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, November 14, 2016 6:10 AM
> To: [email-masked]; [email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 15 Nov 2016 07:23:31 -0800

BTW, just FYI.. the texts I showed during the meeting were a slightly
different and doesn't have socket operation term.
I thought about it the night before the meeting, but couldn't come up
with other words. So, I decided to omit it as I thought this part is
probably not very crucial. But, of course, better terms are welcome.

https://www.ietf.org/proceedings/97/slides/slides-97-mptcp-chair-slide-01.pdf
--
Yoshi

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Nov 2016 08:45:25 -0800

FWIW, the operation IMO should be referred to as "connection
configuration" or "connection parameters".

A socket is defined in RFC793 as an IP address and port. A connection is
defined by *two* sockets.

The Unix "socket" data structure and commands configure parameters for
an OS interface to a connection.

Joe