Re: [multipathtcp] Initial ideas for API requirements

[Olivier Bonaventure <[e-mail]>]

Michael,
> 
> draft-scharf-mptcp-api-00 contains a list of potential requirements on
> the MPTCP API towards application. This list is of course just a
> starting point. Currently, it is certainly not complete and may also
> include requirements that will be removed in later stage, once the MPTCP
> architecture spec evolves.


I am frightened by the long list of requirements and I fear that this
would make the API far too complex. The layering principle tells us that
we need to hide some of the details of the underlying layer to the upper
layer and experience should that this works well in practice.

To take an analogy, let's look at how the socket API evolved with
changes in TCP such as the introduction of congestion control, the fats
retransmit, the selective acks, timers computations, ... All of these
mechanisms have changed the behaviour of the TCP stack and its reaction
against losses but we never had to update the API to reflect this.

>    REQ1:   Turn on/off MPTCP: An application should be able to request
>            to turn on or turn off the usage of MPTCP.  This means that
>            an application should be able to explicitly request the use
>            of MPTCP if this is possible.  Applications should also be
>            able to request not to enable MPTCP and to use regular TCP
>            transport instead.  (This can be implicit in many cases,
>            e.g., by the use of binding to a specific address versus all
>            addresses).

I would love to have a higher layer API where the application indicates
that it needs a reliable delivery and the stack chooses the most
appropriate transport protocol (tcp, sctp, mtcp, ...) automatically.
This would allow the application and the transport to evolve independently.


>    REQ2:   An application will want to be able to restrict MPTCP to
>            binding to a given set of addresses or interfaces.

why ?

>    REQ3:   An application should be able to know if multiple subflows
>            are in use.

why ? today's application do not ask whether there have been retransmissions

>    REQ4:   An application should be able to extract a unique identifier
>            for the connection (per endpoint), analogous to a port, i.e.
>            it should be able to retrieve MPTCP's connection identifier.

this looks reasonable

>    REQ5:   An application should be able to enumerate all subflows in
>            use, obtain information on the addresses used by a subflow,
>            and obtain a subflow's usage (e.g., ratio of traffic sent via
>            this subflow).

why ? today's application do not ask whether there have been retransmissions

>    REQ6:   Set/get application profile, as discussed in the previous
>            section.

remember that for intserv we almost never managed to have application
developers define their QoS requirements

>    REQ7:   Constrain the maximum number of subflows to be used by an
>            MPTCP connection.  (Or just infer from application profile?)

the stack should do this automatically

>    REQ8:   Request a change in scheduling between subflows? (i.e. a more
>            granular version of application profile?)

why ? today's applications do not set for example the MSS to be used

>    REQ9:   Request a change in the number of subflows in use, thus
>            triggering removal or addition of subflows.  (A finer control
>            granularity would be: Request the establishment of a new
>            subflow to a provided destination, and request the
>            termination of a specified, existing subflow.)

this is the job of the tcp implementation, not the application

>    REQ10:  Control automatic establishment/termination of subflows?
>            There could be different configurations of the path manager,
>            e.g., 'try ASAP', 'wait until there is a bunch of data, etc.
>            (Tied to application profile?)

i don't see why an application should want to do this

>    REQ11:  Set/get preferred subflows or subflow usage policies?  There
>            could be different configurations of the multipath scheduler,
>            e.g., 'all-or-nothing', 'overflow', etc.  (Again, tied to
>            application profile).
> 
>    REQ12:  Set/get sporadic sending of segments on unused paths
>            ("keepalives").

no

>    REQ13:  An application should be able to modify the MPTCP
>            configuration while communication is ongoing, i.e., after
>            establishment of the MPTCP connection.

we should have as few mptcp configuration as possible, otherwise pmtcp
will be too complex for the application developers



Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium