Re: [multipathtcp] MPTCP Schedulers

[Olivier Bonaventure <[e-mail]>]

Zhen,
> 
>> Yes. In the hybrid access networks use case, the schedulers are
>> optimised to first use the DSL network and then overlfow over the LTE
>> network when the DSL is full.
> 
> We also have a similar case where the server would like to saturate
> WLAN and then overflow to LTE, where another scheduler will be needed.
> 
> But  we at least have two design choices here:
> 1) first one, as you said, the fine-grained remote control of the
> schedulers used on the peer.

This is a possibility, my fear is that it will be difficult for the IETF 
to clearly specify a reference scheduler. Maybe we can think about 
simple models to represent packets schedulers and then instantiate them.

You also need to take into account the path manager, i.e. who creates 
subflows and when. Most deployments today assume that only clients 
create subflows, mainly because of NATs, but in pure IPv6, we might be 
able to have server triggered subflows in some cases.

> 2) extension of the spare space before the Backup bit in
> MP_JOIN/MP_PRIO.  That's, keep the current Backup bit as it is( use
> the backup flow only in the event failure).  And in the meantime use
> the spare bits as the ‘Saturate and Overflow(S&O)’ priority bit; The
> server who receives sub flows marked with S&O, will first saturate the
> prioritized subflow and then overflow to the others.

We probably need more than a single bit to represent the importance of a 
flow. Note that this importance can change over time and thus should be 
exchanged by using an MPTCP option. The viewpoint of the server is not 
necessarily the same as the one of the client.

> I am in favor of the second one if the cost based prioritizing is only
> case we want to solve, and the priority can be expressed as binary.
> This does not need new options space for MPTCP anyway.

I'd suggest to briefly list all the requirements that operators have in 
controlling MPTCP schedulers. There are many deployments for very 
different use cases and we should leverage this


Olivier