Subject: Re: [multipathtcp] MPTCP Schedulers

From: Zhen Cao <[email-masked]>
Date: Sun, 24 Mar 2019 04:38:58 +0800

Hi Olivier,

> 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.
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.

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.

-Zhen

---

From: Olivier Bonaventure <[email-masked]>
Date: Sun, 24 Mar 2019 17:41:39 +0000

Zhen,
> 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.

> 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.

> 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