Re: [multipathtcp] MPTCP Schedulers

[Olivier Bonaventure <[e-mail]>]

Hello,
>>
>> I'm trying to tie up any loose ends in the SOCKS 6 draft. There is some
>> functionality which lets you change the MPTCP scheduler used by the proxy.
>> The available schedulers are basically the ones available in the Linux
>> kernel implementation.
>> (https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-05#page-20)
>>
>> Do you think it would be worthwhile to standardize the MPTCP schedulers? I
>> think an informational or best practice RFC would be useful.
> 
> In general, I think that would be good. The tricky part around MPTCP is that
> the client has no direct control on the server's scheduling behavior.
> The backup-bit provides some amount of control but it's not fine-grained enough.


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.

For this, we would need to :

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

2. agree on a way to exchange the information related to the requested 
scheduler


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

https://arxiv.org/abs/1901.01863

> 
> Standardizing the schedulers or providing a more explicit "API/messaging"
> from the client to the server about the client's policies would be very
> useful.

There are two parts of the API:
A. an API that enables clients to interact with servers, likely based on 
MPTCP options
B. an API that enables an application to interact with the MPTCP stack


A. should be easy. For B., the socket API draft could be a starting 
point for such a discussion, but other APIs could be possible as well.


> That way, clients can connect to "any" MPTCP-server and make sure that the
> server's behavior is respecting the client's policies about data-usage on
> the different subflows.

Olivier