Subject: [multipathtcp] MPTCP transparent proxy

From: David Pradas <[email-masked]>
Date: Thu, 26 Oct 2017 10:19:59 +0200

Dear All,

We contact you regarding the MPTCP implementation (v0.92) and some 
problems we have encountered in a specific use case (transparent 
sockets). We will try to summarise the context of our study, as well as 
the problem and the solutions we propose to solve it.

The objective of the study has been to work on a MPTCP-PEP proxy, where 
the proxy (PEPsalimplementation) splits the TCP connection and, with 
MPTCP, aggregates two link (satellite and terrestrial). We have also 
focused on other scenarios (e.g. PEPsal only on the satellite link), but 
we prefer to discuss only the one presented in the figure below:

While trying to put together our implementation of PEPsal (transparent 
proxy) in a MPTCPcompliant kernel, we had to face a problem with the 
MPTCP implementation due to the transparent socketsusedin PEPsal. After 
carefully reading the MPTCP code, we discovered that when opening new 
subflows (using the fullmesh algorithm), first it is checked if the IP 
address of the main subflow corresponds to any of the network interfaces 
on the machine. This presents a problem when working with transparent 
sockets, since these sockets can be bound to external IP addresses, not 
present on the machine. In this case, the MPTCP implementation falls 
back to a classical TCP connection, which is not the behaviour wetarget.

We assume such behaviour of  MPTCP implementation was a deliberate 
choice (e.g. for security concerns). Is it actually the main driver ? 
Could such compatibility with transparent proxying be acceptable for 
subsequent MPTCP versions ?
We have proceeded to such code modification, and we are happy to share 
it with you, for review and possible integration in the main MPTCP code. 
You may decide for instance if this feature shall be implemented under 
all circumstances, or restricted to a certain mode only (e.g. activated 
through a control option, sysctl command, ... ).

Secondly,we have carried out some performances tests with applications 
such as HTTP (measuring the page load time) or file transfer over TCP, 
and we have observed that MPTCP outperforms (or equals) the case where 
only one access is used (terrestrial or satellite), specially under 
congestion conditions. That being said, we expect to further work on 
this issue, mainly assessing (1) the performance of MPTCP schedulers 
with such large asymmetry, (2) the performance of the different coupled 
congestion control in our use-case and (3) consider the relevance of the 
second sub-flow opening (mainly for short flows). Do not hesitate to let 
us know if you have any interest in collaborating in this future work.

We attached herein the modification we used, which allows MPTCP to work 
when using transparent sockets.

We would be glad to discuss with you about this subject.

Best Regards,

David PRADAS
Joaquin MUGUERZA

--------------------//_

_//
diff --git a/net/mptcp/mptcp_fullmesh.c b/net/mptcp/mptcp_fullmesh.c
index 1e5b753..665560a 100644
--- a/net/mptcp/mptcp_fullmesh.c
+++ b/net/mptcp/mptcp_fullmesh.c
@@ -629,6 +629,38 @@ static void update_addr_bitfields(struct sock 
*meta_sk,
         }
  }

+static int mptcp_find_address_transp(const struct mptcp_loc_addr 
*mptcp_local,
+                             sa_family_t family, const union inet_addr 
*addr,
+                             int if_idx)
+{
+       int i;
+       u8 loc_bits;
+       bool found = false;
+
+       if (family == AF_INET)
+               loc_bits = mptcp_local->loc4_bits;
+       else
+               loc_bits = mptcp_local->loc6_bits;
+
+       mptcp_for_each_bit_set(loc_bits, i) {
+               if (family == AF_INET &&
+                   (!if_idx || mptcp_local->locaddr4[i].if_idx == 
if_idx)) {
+                       found = true;
+                       break;
+               }
+               if (family == AF_INET6 &&
+                   (!if_idx || mptcp_local->locaddr6[i].if_idx == 
if_idx)) {
+                       found = true;
+                       break;
+               }
+       }
+
+       if (!found)
+               return -1;
+
+       return i;
+}
+
  static int mptcp_find_address(const struct mptcp_loc_addr *mptcp_local,
                               sa_family_t family, const union inet_addr 
*addr,
                               int if_idx)
@@ -1271,9 +1303,18 @@ static void full_mesh_new_session(const struct 
sock *meta_sk)
         rcu_read_lock();
         mptcp_local = rcu_dereference(fm_ns->local);

-       index = mptcp_find_address(mptcp_local, family, &saddr, if_idx);
-       if (index < 0)
+       if(inet_sk(meta_sk)->transparent) {
+               mptcp_debug("Meta socket is transparent");
+               index = mptcp_find_address_transp(mptcp_local, family, 
&saddr, if_idx);
+       }
+       else {
+               mptcp_debug("Meta socket is NOT transparent");
+               index = mptcp_find_address(mptcp_local, family, &saddr, 
if_idx);
+       }
+       if (index < 0) {
+               mptcp_debug("Falling back");
                 goto fallback;
+       }

         if (family == AF_INET)
                 master_tp->mptcp->low_prio = 
mptcp_local->locaddr4[index].low_prio;

--------------------//
////////

---

From: <[email-masked]>
Date: Thu, 26 Oct 2017 08:59:56 +0000

Dear David, all,

Thank you for sharing this information. You may want to direct this message to the maintainers of the MPTCP implementation you mentioned.

I have some architectural questions: Is there any reason why you decided to use the transparent proxy mode? Did you considered to use the explicit mode? How do you ensure that the proxy will be on-path whatever the link you use to place the first subflow?

Thank you.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de David Pradas
Envoyé : jeudi 26 octobre 2017 10:20
À : [email-masked]
Cc : Joaquin Muguerza; [email-masked]; Kuhn Nicolas; Emmanuel Dubois; SALLANTIN Renaud; Riadh Dhaou; FASSON Julien
Objet : [multipathtcp] MPTCP transparent proxy

Dear All,

We contact you regarding the MPTCP implementation (v0.92) and some problems we have encountered in a specific use case (transparent sockets). We will try to summarise the context of our study, as well as the problem and the solutions we propose to solve it.

The objective of the study has been to work on a MPTCP-PEP proxy, where the proxy (PEPsal implementation) splits the TCP connection and, with MPTCP, aggregates two link (satellite and terrestrial). We have also focused on other scenarios (e.g. PEPsal only on the satellite link), but we prefer to discuss only the one presented in the figure below:

While trying to put together our implementation of PEPsal (transparent proxy) in a MPTCP compliant kernel, we had to face a problem with the MPTCP implementation due to the transparent sockets used in PEPsal. After carefully reading the MPTCP code, we discovered that when opening new subflows (using the fullmesh algorithm), first it is checked if the IP address of the main subflow corresponds to any of the network interfaces on the machine. This presents a problem when working with transparent sockets, since these sockets can be bound to external IP addresses, not present on the machine. In this case, the MPTCP implementation falls back to a classical TCP connection, which is not the behaviour we target.

We assume such behaviour of  MPTCP implementation was a deliberate choice (e.g. for security concerns). Is it actually the main driver ? Could such compatibility with transparent proxying be acceptable for subsequent MPTCP versions ?
We have proceeded to such code modification, and we are happy to share it with you, for review and possible integration in the main MPTCP code. You may decide for instance if this feature shall be implemented under all circumstances, or restricted to a certain mode only (e.g. activated through a control option, sysctl command, ... ).

Secondly, we have carried out some performances tests with applications such as HTTP (measuring the page load time) or file transfer over TCP, and we have observed that MPTCP outperforms (or equals) the case where only one access is used (terrestrial or satellite), specially under congestion conditions. That being said, we expect to further work on this issue, mainly assessing (1) the performance of MPTCP schedulers with such large asymmetry, (2) the performance of the different coupled congestion control in our use-case and (3) consider the relevance of the second sub-flow opening (mainly for short flows). Do not hesitate to let us know if you have any interest in collaborating in this future work.

We attached herein the modification we used, which allows MPTCP to work when using transparent sockets.

Best Regards,

David PRADAS
Joaquin MUGUERZA

--------------------

@@ -629,6 +629,38 @@ static void update_addr_bitfields(struct sock *meta_sk,
        }
 }

+static int mptcp_find_address_transp(const struct mptcp_loc_addr *mptcp_local,
+                             sa_family_t family, const union inet_addr *addr,
+                             int if_idx)
+{
+       int i;
+       u8 loc_bits;
+       bool found = false;
+
+       if (family == AF_INET)
+               loc_bits = mptcp_local->loc4_bits;
+       else
+               loc_bits = mptcp_local->loc6_bits;
+
+       mptcp_for_each_bit_set(loc_bits, i) {
+               if (family == AF_INET &&
+                   (!if_idx || mptcp_local->locaddr4[i].if_idx == if_idx)) {
+                       found = true;
+                       break;
+               }
+               if (family == AF_INET6 &&
+                   (!if_idx || mptcp_local->locaddr6[i].if_idx == if_idx)) {
+                       found = true;
+                       break;
+               }
+       }
+
+       if (!found)
+               return -1;
+
+       return i;
+}
+
 static int mptcp_find_address(const struct mptcp_loc_addr *mptcp_local,
                              sa_family_t family, const union inet_addr *addr,
                              int if_idx)
@@ -1271,9 +1303,18 @@ static void full_mesh_new_session(const struct sock *meta_sk)
        rcu_read_lock();
        mptcp_local = rcu_dereference(fm_ns->local);

-       index = mptcp_find_address(mptcp_local, family, &saddr, if_idx);
-       if (index < 0)
+       if(inet_sk(meta_sk)->transparent) {
+               mptcp_debug("Meta socket is transparent");
+               index = mptcp_find_address_transp(mptcp_local, family, &saddr, if_idx);
+       }
+       else {
+               mptcp_debug("Meta socket is NOT transparent");
+               index = mptcp_find_address(mptcp_local, family, &saddr, if_idx);
+       }
+       if (index < 0) {
+               mptcp_debug("Falling back");
                goto fallback;
+       }

        if (family == AF_INET)
                master_tp->mptcp->low_prio = mptcp_local->locaddr4[index].low_prio;

--------------------

---

From: Christoph Paasch <[email-masked]>
Date: Thu, 26 Oct 2017 11:28:25 -0700

+ mptcp-dev
And moving MPTCP IETF-mailing-list to BCC

Hello,

On 26/10/17 - 10:19:59, David Pradas wrote:
> Dear All,
> 
> We contact you regarding the MPTCP implementation (v0.92) and some problems
> we have encountered in a specific use case (transparent sockets). We will
> try to summarise the context of our study, as well as the problem and the
> solutions we propose to solve it.
> 
> The objective of the study has been to work on a MPTCP-PEP proxy, where the
> proxy (PEPsalimplementation) splits the TCP connection and, with MPTCP,
> aggregates two link (satellite and terrestrial). We have also focused on
> other scenarios (e.g. PEPsal only on the satellite link), but we prefer to
> discuss only the one presented in the figure below:
> 
> proxy) in a MPTCPcompliant kernel, we had to face a problem with the MPTCP
> implementation due to the transparent socketsusedin PEPsal. After carefully
> reading the MPTCP code, we discovered that when opening new subflows (using
> the fullmesh algorithm), first it is checked if the IP address of the main
> subflow corresponds to any of the network interfaces on the machine. This
> presents a problem when working with transparent sockets, since these
> sockets can be bound to external IP addresses, not present on the machine.
> In this case, the MPTCP implementation falls back to a classical TCP
> connection, which is not the behaviour wetarget.

thanks for your detailed explanation.

These transparent sockets are they on the passive opener-side (meaning in
your picture on the right side) ?

> We assume such behaviour of  MPTCP implementation was a deliberate choice
> (e.g. for security concerns). Is it actually the main driver ? Could such
> compatibility with transparent proxying be acceptable for subsequent MPTCP
> versions ?

No, it was not a deliberate choice. We didn't consider the case of
transparent sockets.

So, we definitely should fix this.

But, I'm not sure whether your patch takes care of all the potential issues.
It is looking for an index in the table and matches solely on the if_idx. Which,
will be 0 if the socket is not using SO_BINDTODEV. That means,
mptcp_find_address_transp will match on any address. The address it matches
on will be removed from the set of eligible addresses that are being
advertised through ADD_ADDR.

Instead of taking the if_idx from SO_BINDTODEV, in the transparent case we
probably should take the if_idx form the incoming interface.

You have any thoughts on that?

Christoph

> We have proceeded to such code modification, and we are happy to share it
> with you, for review and possible integration in the main MPTCP code. You
> may decide for instance if this feature shall be implemented under all
> circumstances, or restricted to a certain mode only (e.g. activated through
> a control option, sysctl command, ... ).
> 
> Secondly,we have carried out some performances tests with applications such
> as HTTP (measuring the page load time) or file transfer over TCP, and we
> have observed that MPTCP outperforms (or equals) the case where only one
> access is used (terrestrial or satellite), specially under congestion
> conditions. That being said, we expect to further work on this issue, mainly
> assessing (1) the performance of MPTCP schedulers with such large asymmetry,
> (2) the performance of the different coupled congestion control in our
> use-case and (3) consider the relevance of the second sub-flow opening
> (mainly for short flows). Do not hesitate to let us know if you have any
> interest in collaborating in this future work.
> 

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Fri, 27 Oct 2017 12:00:55 +0000

Hi David,

Thank you for clarifying. Much appreciated!

Please see inline.

Cheers,
Med

De : David Pradas [mailto:[email-masked]]
Envoyé : vendredi 27 octobre 2017 11:20
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Cc : Joaquin Muguerza; [email-masked]; Kuhn Nicolas; Emmanuel Dubois; SALLANTIN Renaud; Riadh Dhaou; FASSON Julien
Objet : Re: [multipathtcp] MPTCP transparent proxy

Hi Med,

Thank you for your reply. Yes, indeed, we also sent the email to the maintainers of the MPTCP implementation for further discussion regarding the modification. But we wanted to share the context of the study with the IETF mailing list since we thought it would be interesting to have your feedback.

Regarding your questions:
-  Is there any reason why you decided to use the transparent proxy mode?
Your question is very relevant! It was a functional requirement, we wanted to evaluated the system performance without NAT translation.

[Med] Please note that even in the transparent mode, a ** translation (NAT, if you will) ** is required for subsequent subflows: The proxy will need to translate the internal IP address/port to the one used to place the first subflow. Further, the transparent mode will require that the traffic should be inspected to detect the MPTCP one. This inspection function may have some implications on the system performance.

- Did you considered to use the explicit mode?
We did not consider this mode, because we though that, even giving the address list, the behaviour of the implementation will be the same: i.e. fallback to TCP if the address is not present in the machine (to be confirmed!).

[Med] The behavior for subsequent subflows establishment would be the same, but there are other advantages that are worth to be considered:

-    The proxy is not required to be embedded on an on-path router

-    Only the eligible traffic will be directed to the proxy; no need for traffic inspection or hooks to invoke the proxy function

-    You can easily distinguish MPTCP proxied traffic vs. MPTCP flows that are natively initiated by internal hosts.

- How do you ensure that the proxy will be on-path whatever the link you use to place the first subflow?
In fact, we always force the fist subflow to go through the terrestrial link (and the second one through the satellite link). Knowing that both link are aggregated by our proxy MPTCP-PEP.

[Med] OK, thanks.

Kind regards,

David

Le 26/10/2017 à 10:59, [email-masked]<mailto:[email-masked]> a écrit :
Dear David, all,

Thank you.

Cheers,
Med

De : multipathtcp [mailto:[email-masked]] De la part de David Pradas
Envoyé : jeudi 26 octobre 2017 10:20
À : [email-masked]<mailto:[email-masked]>
Cc : Joaquin Muguerza; [email-masked]<mailto:[email-masked]>; Kuhn Nicolas; Emmanuel Dubois; SALLANTIN Renaud; Riadh Dhaou; FASSON Julien
Objet : [multipathtcp] MPTCP transparent proxy

Dear All,

Best Regards,

David PRADAS
Joaquin MUGUERZA

--------------------

        if (family == AF_INET)

--------------------

--
David PRADAS
Responsable Technique de Projets
(Ph.D. in Telecommunications)
Viveris Technologies
+33(0)561003088
[email-masked]<mailto:[email-masked]>

---

From: David Pradas <[email-masked]>
Date: Fri, 27 Oct 2017 11:19:49 +0200

Hi Med,

Thank you for your reply. Yes, indeed, we also sent the email to the 
maintainers of the MPTCP implementation for further discussion regarding 
the modification. But we wanted to share the context of the study with 
the IETF mailing list since we thought it would be interesting to have 
your feedback.

Regarding your questions:
- Is there any reason why you decided to use the transparent proxy mode?
Your question is very relevant! It was a functional requirement, we 
wanted to evaluated the system performance without NAT translation.

- Did you considered to use the explicit mode?
We did not consider this mode, because we though that, even giving the 
address list, the behaviour of the implementation will be the same: i.e. 
fallback to TCP if the address is not present in the machine (to be 
confirmed!).

- How do you ensure that the proxy will be on-path whatever the link you 
use to place the first subflow?
In fact, we always force the fist subflow to go through the terrestrial 
link (and the second one through the satellite link). Knowing that both 
link are aggregated by our proxy MPTCP-PEP.

Kind regards,

David

Le 26/10/2017 à 10:59, [email-masked] a écrit :
>
> Dear David, all,
>
> Thank you for sharing this information. You may want to direct this 
> message to the maintainers of the MPTCP implementation you mentioned.
>
> I have some architectural questions: Is there any reason why you 
> decided to use the transparent proxy mode? Did you considered to use 
> the explicit mode? How do you ensure that the proxy will be on-path 
> whatever the link you use to place the first subflow?
>
> Thank you.
>
> Cheers,
>
> Med
>
> *De :*multipathtcp [mailto:[email-masked]] *De la part 
> de* David Pradas
> *Envoyé :* jeudi 26 octobre 2017 10:20
> *À :* [email-masked]
> *Cc :* Joaquin Muguerza; [email-masked]; Kuhn 
> Nicolas; Emmanuel Dubois; SALLANTIN Renaud; Riadh Dhaou; FASSON Julien
> *Objet :* [multipathtcp] MPTCP transparent proxy
>
> Dear All,
>
> sockets). We will try to summarise the context of our study, as well 
> as the problem and the solutions we propose to solve it.
>
> The objective of the study has been to work on a MPTCP-PEP proxy, 
> where the proxy (PEPsal implementation) splits the TCP connection and, 
> with MPTCP, aggregates two link (satellite and terrestrial). We have 
> also focused on other scenarios (e.g. PEPsal only on the satellite 
> link), but we prefer to discuss only the one presented in the figure 
> below:
>
> MPTCP implementation due to the transparent socketsusedin PEPsal. 
> After carefully reading the MPTCP code, we discovered that when 
> opening new subflows (using the fullmesh algorithm), first it is 
> checked if the IP address of the main subflow corresponds to any of 
> the network interfaces on the machine. This presents a problem when 
> working with transparent sockets, since these sockets can be bound to 
> external IP addresses, not present on the machine. In this case, the 
> MPTCP implementation falls back to a classical TCP connection, which 
> is not the behaviour wetarget.
>
> it with you, for review and possible integration in the main MPTCP 
> code. You may decide for instance if this feature shall be implemented 
> under all circumstances, or restricted to a certain mode only (e.g. 
> activated through a control option, sysctl command, ... ).
>
> with such large asymmetry, (2) the performance of the different 
> coupled congestion control in our use-case and (3) consider the 
> relevance of the second sub-flow opening (mainly for short flows). Do 
> not hesitate to let us know if you have any interest in collaborating 
> in this future work.
>
> --------------------/_
> _/

-- 
*David PRADAS*
Responsable Technique de Projets
/(Ph.D. in Telecommunications)/
Viveris Technologies
+33(0)561003088
[email-masked] //////

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 29 Oct 2017 18:43:06 -0700

Hi David,

On Thu, Oct 26, 2017 at 1:19 AM, David Pradas <david.pradas@toulouse.
viveris.com> wrote:
>
> Secondly, we have carried out some performances tests with applications
> such as HTTP (measuring the page load time) or file transfer over TCP, and
> we have observed that MPTCP outperforms (or equals) the case where only one
> conditions. That being said, we expect to further work on this issue,
> mainly assessing (1) the performance of MPTCP schedulers with such large
> asymmetry, (2) the performance of the different coupled congestion control
> in our use-case and (3) consider the relevance of the second sub-flow
> opening (mainly for short flows). Do not hesitate to let us know if you
> have any interest in collaborating in this future work.
>
Sounds interesting.
It would be great if you could share more info about your network
configuration (e.g. RTT, bandwidth, loss rate, apps, etc)
--
Yoshi

---

From: David Pradas <[email-masked]>
Date: Mon, 30 Oct 2017 15:01:43 +0100

Hi Med,

Thank you again for your feedback. Please find my comments inline.

Cheers,
David

Le 27/10/2017 à 14:00, [email-masked] a écrit :
> *De :*David Pradas [mailto:[email-masked]]
> *Envoyé :* vendredi 27 octobre 2017 11:20
> *À :* BOUCADAIR Mohamed IMT/OLN; [email-masked]
> *Objet :* Re: [multipathtcp] MPTCP transparent proxy
>
> Hi Med,
>
> maintainers of the MPTCP implementation for further discussion 
> regarding the modification. But we wanted to share the context of the 
> study with the IETF mailing list since we thought it would be 
> interesting to have your feedback.
>
> [Med] Please note that even in the transparent mode, a ** translation 
> (NAT, if you will) ** is required for subsequent subflows: The proxy 
> will need to translate the internal IP address/port to the one used to 
> place the first subflow. Further, the transparent mode will require 
> that the traffic should be inspected to detect the MPTCP one. This 
> inspection function may have some implications on the system performance.
>
[David] Yes, indeed, the second mptcp subflow takes the source address 
of our proxy.
Regarding the detection of MPTCP for the transparent mode, yes, this 
inspection might have an impact on the performances (CPU charge, RAM), 
even if does not seem to be the case of our platform --> But, indeed, it 
would be necessary to consider this impact on real systems, with many 
more flows to inspect.
> address list, the behaviour of the implementation will be the same: 
> i.e. fallback to TCP if the address is not present in the machine (to 
> be confirmed!).
>
> [Med] The behavior for subsequent subflows establishment would be the 
> same, but there are other advantages that are worth to be considered:
>
> -The proxy is not required to be embedded on an on-path router
>
> -Only the eligible traffic will be directed to the proxy; no need for 
> traffic inspection or hooks to invoke the proxy function
>
> -You can easily distinguish MPTCP proxied traffic vs. MPTCP flows that 
> are natively initiated by internal hosts.
>
[David] Thanks for this information! we were not aware of all these 
advantages. They are closely related to our discussion on your first 
question.
> In fact, we always force the fist subflow to go through the 
> terrestrial link (and the second one through the satellite link). 
> Knowing that both link are aggregated by our proxy MPTCP-PEP.
>
> [Med] OK, thanks.
>
>
> Kind regards,
>
> David
>
>
> Le 26/10/2017 à 10:59, [email-masked] 
> <mailto:[email-masked]> a écrit :
>
>     Dear David, all,
>
>     Thank you for sharing this information. You may want to direct
>     this message to the maintainers of the MPTCP implementation you
>     mentioned.
>
>     decided to use the transparent proxy mode? Did you considered to
>     use the explicit mode? How do you ensure that the proxy will be
>     on-path whatever the link you use to place the first subflow?
>
>     Thank you.
>
>     Cheers,
>
>     Med
>
>     *De :*multipathtcp [mailto:[email-masked]] *De la
>     part de* David Pradas
>     *À :* [email-masked] <mailto:[email-masked]>
>     *Cc :* Joaquin Muguerza; [email-masked]
>     <mailto:[email-masked]>; Kuhn Nicolas;
>     Emmanuel Dubois; SALLANTIN Renaud; Riadh Dhaou; FASSON Julien
>     sockets). We will try to summarise the context of our study, as
>     well as the problem and the solutions we propose to solve it.
>
>     where the proxy (PEPsal implementation) splits the TCP connection
>     and, with MPTCP, aggregates two link (satellite and terrestrial).
>     We have also focused on other scenarios (e.g. PEPsal only on the
>     satellite link), but we prefer to discuss only the one presented
>     in the figure below:
>
>     While trying to put together our implementation of PEPsal
>     (transparent proxy) in a MPTCPcompliant kernel, we had to face a
>     problem with the MPTCP implementation due to the transparent
>     socketsusedin PEPsal. After carefully reading the MPTCP code, we
>     discovered that when opening new subflows (using the fullmesh
>     algorithm), first it is checked if the IP address of the main
>     subflow corresponds to any of the network interfaces on the
>     machine. This presents a problem when working with transparent
>     sockets, since these sockets can be bound to external IP
>     addresses, not present on the machine. In this case, the MPTCP
>     implementation falls back to a classical TCP connection, which is
>     not the behaviour wetarget.
>
>     choice (e.g. for security concerns). Is it actually the main
>     driver ? Could such compatibility with transparent proxying be
>     acceptable for subsequent MPTCP versions ?
>     We have proceeded to such code modification, and we are happy to
>     share it with you, for review and possible integration in the main
>     MPTCP code. You may decide for instance if this feature shall be
>     implemented under all circumstances, or restricted to a certain
>     mode only (e.g. activated through a control option, sysctl
>     command, ... ).
>
>     Secondly,we have carried out some performances tests with
>     applications such as HTTP (measuring the page load time) or file
>     transfer over TCP, and we have observed that MPTCP outperforms (or
>     equals) the case where only one access is used (terrestrial or
>     satellite), specially under congestion conditions. That being
>     said, we expect to further work on this issue, mainly assessing
>     (1) the performance of MPTCP schedulers with such large asymmetry,
>     (2) the performance of the different coupled congestion control in
>     our use-case and (3) consider the relevance of the second sub-flow
>     opening (mainly for short flows). Do not hesitate to let us know
>     if you have any interest in collaborating in this future work.
>
> /(Ph.D. in Telecommunications)
> Viveris Technologies
> +33(0)561003088
> [email-masked] 
> <mailto:[email-masked]>_ /
>