Re: [multipathtcp] Fw: New Version Notification for draft-hoang-mptcp-sub-rate-limit-00.txt

[Olivier Bonaventure <[e-mail]>]

Med,

> Thank you for igniting this work.
> 
> FWIW, we used to have this requirement in 
> draft-nam-mptcp-deployment-considerations (with cellular networks in mind):
> 
>     “For cases where some access networks are subject to a volume quota,
> 
>     it is desirable to support a signal to indicate to a remote peer how
> 
>     it must place data into available subflows”.
> 
> The rate-limit option as currently defined may not be adequate. I would 
> like an option which allows to tell a remote peer, for example:
> 
> ·to use a given subflow only where there is a need to grab more 
> resources (that is, don’t use this subflow if data can be placed on 
> other subflows).

This would be a variation of the backup bit, with a different semantics. 
There are different possible semantics, the current one says:
- don't use the backup subflow unless there is an active one
Other semantics could be:
- don't use the backup subflow as long as the delay on the active one is 
below <250msec (this is roughly what Apple does with Wifi assist)
- don't use the backup subflow as long as the throughput of the active 
one is above 1 Mbps

> ·“here is my suggested inbound traffic distribution ratio among 
> established subflows”.

As a percentage between the different subflows of an existing connection 
? The main difficulty of such an approach is that the number of subflows 
changes over time and client and servers might have a different view on 
the number of subflows that are active. There are many corner cases that 
make this difficult to implement in general.

I think that a rate limit (typically on the cellular interface) covers 
many of these use cases

> ·“here is the maximum data that can be placed in a given subflow”.

In bytes ? We could imagine an option that indicates that a given 
connection can receive up to x MBytes and after that it will be released.


Olivier