Re: [multipathtcp] Initial ideas for API requirements

[Costin Raiciu <[e-mail]>]

How about redundancy? I can think of cases where the app might like  
to send all segments on all paths, to reduce end to end rtt, etc.

Costin

On 12 Nov 2009, at 11:33, SCHARF, Michael wrote:

> Dear all,
>
> 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.
>
> Still, we would really appreciate comments on the scope of the
> (optional) extended API. Please find below a copy of the list in the
> draft.
>
>    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).
>
>    REQ2:   An application will want to be able to restrict MPTCP to
>            binding to a given set of addresses or interfaces.
>
>    REQ3:   An application should be able to know if multiple subflows
>            are in use.
>
>    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.
>
>    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).
>
>    REQ6:   Set/get application profile, as discussed in the previous
>            section.
>
>    REQ7:   Constrain the maximum number of subflows to be used by an
>            MPTCP connection.  (Or just infer from application  
> profile?)
>
>    REQ8:   Request a change in scheduling between subflows? (i.e. a  
> more
>            granular version of application profile?)
>
>    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.)
>
>    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?)
>
>    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").
>
>    REQ13:  An application should be able to modify the MPTCP
>            configuration while communication is ongoing, i.e., after
>            establishment of the MPTCP connection.
>
> Thanks
>
> Michael
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp