mptcp: remove duplication between select_size and current_mss

The idea behind the first part of mptcp_select_size and mptcp_current_mss is
the same except that the former uses mss_cache to compute the mss while the
latter use tcp_current_mss. This patch refactor the code such that it defines
a new function that take a callback function which returns the expected mss
value for a subflow.

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: dynamically adapt mss value

MPTCP currently selects the MSS value as the maximum between the MSS of each
subflows. This works well once all subflows have the same MSS or when a subflow
with a smaller MSS does not participate enough to the connection (e.g. lossy
link, etc.). However, this does not work well once the path have similar
performances and that the MSS slightly differs.

Originaly, MPTCP selected the MSS as the minimum amongst the subflows. But
suffers if the subflow with a small MSS maginally participated to the overall
performances.

This patch take another approach. Instead of selecting the minimum and maximum
values, it dynamically adapts the MSS based on the contribution of all subflows
in the connection performances. This means that a subflow has a small MSS value
and is not participating enough to the performances then the maximum MSS value
will be selected and vice versa.

To understand the problem behind selecting the MSS consider the following
example: If a sublow has a MSS value of 1420 and is smaller than the MSS
selected by MPTCP 1428, it means that when the application will push data the
stack will generate 1428-byte segments. As the subflow uses a smaller MSS the
stack will split the segment in two: a 1420-byte and 8-byte segments. The
latter will introduce a large overhead as for a single data segment 2 slots
will be used in the congestion window therefore reducing by ~2 the potential
throughput of this subflow. Indeed, 1428 will be send while 2840 could have been
sent if mss == 1420 reducing the throughput by 2840 / 1428.

If this subflow is the main (or an important) contributor to the overall
throughput then the performances of MPTCP will be bad. Better performances would
be achieved by selecting 1420 as the MSS value.

The dynamic adaptation of this patch is as follows. For each subflow, the
algorithm computes the potential throughput achieved by selecting its MSS. This
is done by taking into account the lost space in the cwnd. The algorithm is the
following:

 \forall sub MAX(\sum_{\forall sub} ratio * \frac{mss * cwnd_sub}{rtt_sub})

Where ratio is computed as follows:
 \frac{mss}{\ceil{mss / mss_sub} * mss_sub}

ratio gives the reduction factor of the theoretical throughput a subflow can
achieve if MPTCP uses a specific MSS value.

Here are some results achieved with and without this path in a virtual
environment (not made for performances measurement but for functionality
testing). The lab is composed of a client with 2 path to a server (and a router
in the middle). The client downloads 10 times a 50MB file from the server. We
vary the MTU value of one interface on the client (default is 1500 bytes).

* 1500 + 1500:
 - WITHOUT algo:
   Transfer rate:          23747.62 [Kbytes/sec] received
 - WITH algo:
   Transfer rate:          23710.46 [Kbytes/sec] received

* 1490 + 1500
 - WITHOUT algo:
   Transfer rate:          15132.76 [Kbytes/sec] received
 - WITH algo:
   Transfer rate:          23923.66 [Kbytes/sec] received

* 600 + 1500
 - WITHOUT algo:
   Transfer rate:          10033.34 [Kbytes/sec] received
 - WITH algo:
   Transfer rate:          10559.37 [Kbytes/sec] received

* 1490 (no loss) + 1500 (10 % losses :-D)
 - WITHOUT algo:
   Transfer rate:          15101.86 [Kbytes/sec] received
 - WITH algo:
   Transfer rate:          23027.58 [Kbytes/sec] received

Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>