Re: [multipathtcp] MPTCP Schedulers

[<[e-mail]>]

A couple of things personally I’d be interested in hearing about

-          If there are differences for the schedulers deployed for end host deployments of MPTCP and the proxy deployments

-          Scheduling algorithms that prefer one interface for policy reasons (eg cost) ie the choice of interface is not primarily down to performance differences between the interfaces (but presumably kicks in at some point when it’s decided that the primary is down (how to decide that?) or that there isnt enough bandwidth on the primary interface (how to decide that?)
phil

From: multipathtcp [mailto:[e-mail]] On Behalf Of Alexander Frömmgen
Sent: 17 February 2019 12:36
To: Olivier Bonaventure <[e-mail]>; Christoph Paasch <cpaasch=[e-mail]>; Vladimir Olteanu <[e-mail]>
Cc: [e-mail]
Subject: Re: [multipathtcp] MPTCP Schedulers

Hello,

some remarks and questions inline.

> Do you think it would be worthwhile to standardize the MPTCP schedulers? I
> think an informational or best practice RFC would be useful.

What level of scheduler standardization do you consider? While an informal description of the scheduler behavior should be feasible, I have the feeling that a detailed specification of the scheduler behavior is not possible, e.g., i) details of todays scheduler behaviors emerged from the dependencies to the Linux Kernel (round trip time is calculation, packet queues), and ii) intuitive descriptions, such as "redundant“, are very imprecise (prefer old or new packets for heterogenous subflow environments?). [0]

> I agree, but this control could be provided by defining an MPTCP option
> that enables a client to request the utilisation of a specific scheduler
> by a remote server.

> 1. agree on a small list of schedulers that should be supported by MPTCP
> implementations. The literature contains a variety of schedulers, we'd
> need to select some of them

1.1 How to select the concrete schedulers? Given that there is a variety of proposed schedulers, as of today, the Linux implementation contains only three of them. Does this imply that there was no need for further schedulers outside of academia so far?
1.2 How should we deal with the concrete parameters of these schedulers and scheduler Evolution?

> If we can define a small list of identifiers for 1, then we can use the
> same technique as the one described in recent work by Hoang Tran Viet

Sounds great. Can you elaborate a bit the concrete usecase? Why is the eBPF flexibility required?

> B. an API that enables an application to interact with the MPTCP stack

It might worth to start with the high level  "goals" and the target audience of such an API.. For application developers, for example, the choice of the concrete scheduler might be inappropriate. The Apple API [2], for example, is on a much higher abstraction level than explicitly selecting the scheduler.

A high level API to specify the preferences [3], e.g., the required throughput, might enable scheduler innovations to optimize for these preferences and speed up the MPTCP adoption by simplifying the application developers life.

Obviously, the high level API might be implemented on top of a lower level API. In this case, the goal for the lower level API should be to enable the implementation of the high level API on top.

Best,

Alexander

[0] http://progmp.net/froemmgen-middleware2017.pdf
[1] http://tuprints.ulb.tu-darmstadt.de/7709/13/Dissertation_Froemmgen.pdf Section 2.2<http://tuprints.ulb.tu-darmstadt.de/7709/13/Dissertation_Froemmgen.pdf%20Section%202.2>
[2] https://developer.apple.com/documentation/foundation/nsurlsessionmultipathservicetype
[3] https://github.com/AlexanderFroemmgen/draft-ietf-mptcp-api-for-preference-awareness/blob/master/output.txt