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

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:multipathtcp-bounces@ietf.org] On Behalf Of
> philip.eardley@bt.com
> Sent: Monday, November 14, 2016 6:10 AM
> To: fabien.duchene@uclouvain.be; multipathtcp@ietf.org
> Subject: Re: [multipathtcp] Adding a new work item on MPTCP API
> 
> 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 <multipathtcp-bounces@ietf.org> on behalf of Fabien Duchêne
> <fabien.duchene@uclouvain.be>
> Sent: 14 November 2016 02:03
> To: multipathtcp@ietf.org
> Subject: Re: [multipathtcp] Adding a new work item on MPTCP API
> 
> Hello,
> 
> 
> On 11/13/2016 08:31 AM, Christoph Paasch wrote:
> > Hello,
> >
> > On 09/11/16 - 10:21:42, philip.eardley@bt.com wrote:
> >> 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.
> > 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.
> >
> 
> I support this work and I agree with Christoph and Mirja.
> > Christoph
> >
> 
> Cheers,
> 
> Fabien
> 
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp