Subject: [multipathtcp] Offload MPTCP Proxy (was RE: potential MPTCP proxy charter item)

From: <[email-masked]>
Date: Mon, 7 Nov 2016 15:03:49 +0000

Hi Olivier,

I'm not sure it is that clear we need to systematically include MP_CAPABLE option in the SYN to the ultimate server. I see some value there...but also some side effects. I'm reiterating what I already said in this thread: 

(+) I see "a big benefit" for some operators to offload the MTPCP proxies if the server is MPTCP-capable.
(-) I don’t see "a big benefit" for the client from a QoE perspective, because they already have the MPTCP experience with the network assistance (network aggregation, path resiliency). 
(-) I don’t see "a big benefit" for the client if the MPTCP-capable server decides to use a given path to place data, while that path is subject to a data volume quota. This means that the client will be mono-path quickly if an MPTCP-capable server adopts some traffic distribution schemes.
 
That said, I have no problem to leave this as a configurable parameter. A configuration knob can be supported to instruct the MCP about the behavior to follow. Also, a white list of servers can be provided to the MCP. 

This is exactly the kind of technical considerations for which we need a formal WG document so that we can record the WG decision.

Cheers,
Med

> -----Message d'origine-----
> De : Olivier Bonaventure [mailto:[email-masked]]
> Envoyé : dimanche 6 novembre 2016 22:12
> À : Mirja Kühlewind; BOUCADAIR Mohamed IMT/OLN; Alan Ford
> Cc : [email-masked]
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> 
> It's clear that the MCP should send the MP_CAPABLE option in the SYN
> towards the destination server and fallback to TCP is this fails. Since
> there are some middleboxes that continue to silently drop the MP_CAPABLE
> option, the MCP should be able to maintain a list of destination servers
> where it had to fallback to regular TCP (e.g. after n retransmissions of
> the SYN with MP_CAPABLE as suggested in RFC6824) and no attempt to use
> MPTCP for these destinations. This cache should be reset on a regular
> basis to probe again the destination servers.

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 07 Nov 2016 08:06:28 -0800

Hello,

> (+) I see "a big benefit" for some operators to offload the MTPCP proxies if the server is MPTCP-capable.

I think it is not only for "offloading" but also just to allow for native
MPTCP. When there is a choice between native MPTCP and proxied MPTCP, the
former should always be preferred. I guess we all agree on that.

> (-) I don’t see "a big benefit" for the client from a QoE perspective, because they already have the MPTCP experience with the network assistance (network aggregation, path resiliency). 

When MPTCP goes end-to-end, the routing is optimal because the TCP-subflows
don't have to go through a detour to reach the proxy. The path through the
proxy is always less or equally as good as the direct path.

>From a QoE perspective I see a benefit in that the native server has more
info on the traffic-characteristics it is sending to the client. So it can
optimize based on this. This info (coming from the server-side) is not
available to the proxy.

> (-) I don’t see "a big benefit" for the client if the MPTCP-capable server decides to use a given path to place data, while that path is subject to a data volume quota. This means that the client w…

This shows that we need signalling on an MPTCP-connection so that the client
can tell the server "don't send on this subflow now". We actually already have
this with the MP_PRIO-option, but something more sophisticated might be needed.

While a proxy might have access to the data-quota and can schedule traffic
based on this, data-quota is not the only variable that makes one want to
avoid cellular. If the device is a mobile device, battery-constraints come
into play as well.

Christoph

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

---

From: <[email-masked]>
Date: Tue, 8 Nov 2016 07:08:14 +0000

Hi Christoph, 

Please see inline.

Cheers,
Med

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : lundi 7 novembre 2016 17:06
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]; Mirja Kühlewind; Alan Ford;
> [email-masked]
> Objet : Re: [multipathtcp] Offload MPTCP Proxy (was RE: potential MPTCP
> proxy charter item)
> 
> Hello,
> 
> > I'm not sure it is that clear we need to systematically include
> MP_CAPABLE option in the SYN to the ultimate server. I see some value
> there...but also some side effects. I'm reiterating what I already said in
> this thread:
> >

[Med] I hear you Christoph, but I think we need to elaborate a little bit further to understand what are the incentives for an MCP to be removed from the path. Optimizing the use of MCP resources has a clear benefit for an operator because this is about OPEX/CAPEX.

> 
> > (-) I don’t see "a big benefit" for the client from a QoE perspective,
> because they already have the MPTCP experience with the network assistance
> (network aggregation, path resiliency).
> 
> don't have to go through a detour to reach the proxy. 

[Med] You are making an invalid assumption here about forwarding. This is deployment-specific. An MCP proxy can also be on-path. BTW, path stretch is a requirement for deciding the location of an MCP. This is clearly mentioned the deployment I-D.

The path through the
> proxy is always less or equally as good as the direct path.

[Med] You are right. My comment was not about the basic delay transfer, but about the "MPTCP experience": network aggregation, path resiliency.  Of course a proxy may fail, but means to protect carrier grade functions are widely in use in operators networks.

> optimize based on this. This info (coming from the server-side) is not

[Med] I see your point, but there are cases (mainly in the cellular world) that may require some knowledge of the radio cells to react quickly to congestions. FWIW, some experiments were conducted to define an API that can be exposed to a content provider to help for direct delivery without involving a proxy. The server has not to be aggressive to the network. Having information from the network to the server, and vice versa would be ideal.  

> 
> > (-) I don’t see "a big benefit" for the client if the MPTCP-capable
> server decides to use a given path to place data, while that path is
> subject to a data volume quota. This means that the client will be mono-
> path quickly if an MPTCP-capable server adopts some traffic distribution
> schemes.
> 

[Med] Agree. Having an option would help but it still this is tricky because an MPTCP client may not have access to "subscription" information. It may use the interface technology as a hint, but still this a hint. Other complications may arise to acquire such information.

> avoid cellular. If the device is a mobile device, battery-constraints come

[Med] Agree, too. 

> 
> 
> Christoph
> 
> 
> >
> > That said, I have no problem to leave this as a configurable parameter.
> A configuration knob can be supported to instruct the MCP about the
> behavior to follow. Also, a white list of servers can be provided to the
> MCP.
> >
> > This is exactly the kind of technical considerations for which we need a
> formal WG document so that we can record the WG decision.
> >
> > Cheers,
> > Med
> >